Architect’s road – redis cluster analysis



stayArchitect’s road – redis cluster analysisIt is mentioned that putting forward level questions, making level summaries and suggestions and making level answers are the three difficulties faced by architects.

I’m afraid of meeting every day. The meeting lasted ten minutes and prepared for half a day.



The following is a story about these three difficulties.


Scenario domain division problem

One day a few years ago, at a meeting, completely unrelated team members were reviewing the architecture of our system. Because they don’t understand my system, most of the questions are about the architect’s personal ability.

During the introduction, I mentioned: “according to the characteristics of the system, the following applications are divided according to roles and the situation of existing personnel…”. Then I was interrupted and someone asked, “are applications divided according to fields or personnel?”

For this buried pit problem, options are a and B, and the more reasonable answer is generally C.图片

The translation questioner’s question is actually asking: “aren’t all fields divided by fields? Isn’t the method of personnel division wrong?”

First, let me analyze what will happen according to the questioner’s words: “modules need to be divided according to fields, and modules are hierarchical. Personnel division determines the granularity of independent deployment units, which should be comprehensively considered in actual projects.”

In this way, although the questioner’s question was answered, it was obvious that the questioner had a blind spot in knowledge and needed me to solve his doubts: “how to divide applications?” My answer did not give him a complete answer. He will continue to find some loopholes to refine the questions, such as: “isn’t resource budget considered as a factor of granularity?” If I follow his train of thought every time, there will be no clear structure in the whole answer process.

Therefore, I need to directly answer his essential questions. The following are the answers:

In the system introduced this time, the main basis is to divide modules according to fields, and determine the granularity of independently deployed application modules according to resources and personnel.

However, in other systems, the emphasis will be different according to different system characteristics, module or application division. Let me give a few examples.

Example 1 (pipeline filter mode)

For example, the workflow system adopts the pipeline filter mode from the overall architecture

As shown in the figure above, there are two main roles in this system. One is the manager role, which is responsible for connecting other module organizations to provide services externally as a whole. I remember doing such a project before. The module system of the manager role was called Captain (at that time, everyone was named after Marvel heroes, and captain corresponds to the captain of the United States). Other modules are filters. Whether to deploy each filter independently or mainly depends on manpower and resources. As long as the design is clear, the manpower and resources will be adjusted in the future, or there are better requirements for stability with the development of the business, it may be necessary to isolate according to the availability. Separate deployment of high SLA and low SLA, multi region and multi machine room deployment of high SLA.

Example 2 (three plane separation mode)

For example, three plane separation architecture system, please refer to my previous article for detailsThree plane separation architecture。 Simply put, it is divided into the core process control plane, the sub core component support plane and SLA. Only two 9 management, operation and maintenance planes are required. As shown below:

Therefore, the boundaries of the three planes should be clear when dividing domains. The availability levels of the three planes are different, and the resource allocation is also different. For example, the log storage of the core process control platform takes 90 days, and others may take 30 days; The process control plane may need to log the start and end of each request, while other services only need to log when exceptions occur; The process control plane and component support plane need high availability deployment of four places and eight centers, while the management operation and maintenance platform only needs two machine rooms for disaster recovery. So the core is to separate the three planes to allocate different resources.

Example 3 (asynchronous processing mode)

Some applications are implemented as a whole, but are divided into two parts by middleware. For example, one service is asynchronous processing mode. The so-called asynchronous processing mode is to divide a time-consuming process into two stages. For example, refund operation. When users submit a refund request, they will receive a real-time notice: “your refund request has been received, and the refund will arrive within 1 ~ 2 working days.” After that, the system will throw the refund request into MQ and consume it slowly.

According to the actual resources, the service of this mode can be divided into two independently deployed systems, or combined in one application as both MQ producer and MQ consumer.




If you observe that others always ask questions about details, you can jump out of your mind and find out what his essential problem is.


Recommended reading

Problems to be solved in service design

Consistency visibility differences in distributed storage systems

Code honor and Disgrace View – proud of using style and ashamed of random coding

How do programmers break the game