Closing Words Authors Often Succeed, Executors Often Reach #

Hello, I am Xu Changlong.

Today is the last month of 2022, and we have reached the final lecture of this course. I am honored to accompany you throughout these months of study. Thank you for your company. Many of the comments from my fellow learners were interesting and inspiring.

Each optimization technique in high-concurrency systems contains many excellent ideas. Extracting these ideas is a laborious process.

Over the past six months, every night I either wrote, edited, or searched for information until midnight. To be honest, writing this column was much more difficult than I had imagined. It required constantly organizing my thoughts, optimizing my expressions, and repeatedly verifying various materials to ensure the accuracy of the knowledge being conveyed.

In practice, when optimizing a system, we often need to consider many factors and go through trial and error multiple times in order to find a suitable solution. There is no universal method that applies to all situations. When solving a problem, there are often multiple options, and each option is further connected to more branches, just like a garden with branching paths.

Therefore, I believe that instead of exhaustively covering various detailed issues, it is more crucial to help you build a comprehensive knowledge system and develop the correct mindset for understanding the system.

When developing a system, our first consideration is usually the number of users. Then we analyze the main actions of the users and determine the type of system and the direction of optimization based on the analysis data and the core frequently called functions (whether the functions have more reads or more writes).

Once the optimization direction is determined, the remaining work is to design and optimize based on the characteristics of different types of systems. This is also the design philosophy of this column: focusing on mainstream optimization solutions and case studies for high-concurrency systems, with practical techniques as supplementary content.

Now, let’s review what we have learned over the past few months and hope it has been helpful for your knowledge accumulation.

• First of all, we started with the most common system in internet services, which is read-heavy and write-light. This kind of system has a simple structure, easy maintenance, and controllable costs. The main challenge in optimization is ensuring data consistency.

To ensure data consistency in caching, we can optimize the data table structure and handle the refreshing mechanism of temporary and long-term caches. In read-heavy and write-light systems, data that can be queried by ID has the best performance. However, it is more difficult to maintain queries and statistical calculations in cache.

According to the development law of read-heavy and write-light systems, decoupling the user login process is a necessary step. Here, our optimization approach is to achieve decentralization through signature authentication. In the later stages of the evolution of read-heavy and write-light systems, multi-data center data synchronization is also an important topic. By studying distributed core knowledge such as the Raft consensus algorithm, we have laid a foundation for advanced learning in the future.

Compared to read-heavy and write-light systems, strong consistency systems not only need to ensure data consistency but also pursue better performance. We chose the typical example of an e-commerce flash sale system for analysis. Flash sale systems are often coupled with multiple systems and are difficult to manage, so it is necessary to split the system in a sensible way. Additionally, we need to gain a deep understanding of locks and flexibly use them to implement inventory contention.

In the optimization and transformation of this type of system, we need to decouple the flash sale service from the intranet and handle the coordination of multiple service transactions. With the recent popularity of microservices, distributed transactions have become a necessary component. Through in-depth research on examples such as 2PC and TCC, we can understand the implementation ideas of most distributed transactions.

As for write-heavy and read-light systems, they are the core support for monitoring systems and log centers.

There are two main challenges in optimization: one is to coordinate multiple servers and provide linear sharding to improve read and write performance; the other is to understand how distributed services cope with write pressure and ensure storage and query for distributed data services. Taking the log center as an example, by understanding the implementation and principles of major data engines, we can gain a deeper understanding of the core ideas behind distributed storage, querying, and scaling.

In addition, I also shared how to implement a distributed tracing system with limited resources. Only by implementing proper monitoring can we better observe and understand our system. These explorations help us understand the practical thinking of some big companies. I recommend you to try these techniques more after class.

Write-heavy and read-heavy systems are the most challenging type of services. They can be considered the ceiling of our industry, requiring higher service response requirements and the ability to handle high availability issues of the system. Because centralized caching is difficult to meet the needs of such services, we often make various attempts to do a good job of data caching. However, whether it is local caching or sharding architecture (such as introducing script engine integration), there are many challenges in implementation, and if you are not careful, you may make mistakes. In order to try our best to avoid the situation of business service cache dealing with high concurrency read and write, we also need to find ways to properly split the architecture and optimize traffic scheduling.

In addition to the above four categories of systems, we also discussed object storage, cost estimation of log centers, how to cleverly use gateways, how to implement load testing, and other issues in the “Intranet Construction” section. I believe that these can help you broaden your horizons, expand your thinking, and most importantly, enable you to cope with the impact of business traffic growth calmly. Here, I would like to thank the classmates again for their comments. Many of the contents have also inspired me, especially when writing the “Intranet Construction” part, I have made many optimizations based on the questions in the comments.

Perhaps the systems you are dealing with don’t have such high traffic at the moment, but I still believe that high concurrency is the future direction. This is related to the development patterns of most Internet companies: many businesses in the early stages will deal with performance issues through algorithms and hardware, but after the traffic increases, the maintenance cost of hardware will be high; even for many large Internet companies, their systems need continuous optimization and improvement to match the growing business needs.

Most business systems are optimized to be read-heavy and write-light. Such architectural designs mainly rely on caches and distributed queues to handle common user traffic pressures, which are relatively cost-saving.

For strongly consistent transaction systems, the method is to narrow down the granularity of services and data that require strong consistency, continuously split and isolate systems, and disperse the traffic to ultimately control costs.

If it is optimization of basic services, then we can only use isolation, algorithms, queues, dynamic allocation of basic server resources, and reducing storage cycles to handle traffic pressure and reduce our costs. After the business matures, we will gradually optimize some useless business processes and functions to save investment in basic services.

As for the core business with both read and write operations, in the early stages, we can only invest a large amount of hardware resources and use CDNs for traffic scheduling. However, when the traffic decreases or the market matures, we will still try to transform some services to have more reads and fewer writes.

In the column, in order to present you with a clear knowledge structure, I divided the systems into four categories based on their data characteristics. However, actual systems may be more complex, so you may be confused when distinguishing system types: which type does this service or system belong to?

In fact, when you encounter this situation, you need to think: whether these different types of services need to be separated and deployed separately? If a system uses multiple running modes in a mixed manner, the complexity of combinations will increase exponentially over time, gradually pushing the system towards losing control.

The ideal state is to design business systems to be simpler and modules more vertical. If there really is a mixed situation, either choose one type as the main optimization direction, or completely separate the system. Different types of systems have different optimization directions, corresponding supporting facilities, server investment ratios at each level, and basic support requirements. Mixing them together not only wastes hardware resources but also is difficult to maintain.

Speaking of this, let’s think again about what is the core value of optimization? Is it to make the service run faster? Or to make the features more user-friendly? Or to make our design simpler and unified? I think all these answers are correct, but in addition to that, there is a more fundamental value: cost savings.

You will find that various optimizations and new technologies are trying to reduce costs, regardless of whether the solution is splitting, decoupling, or integrating. Monitoring and standardizing processes follow the same principle. Although they may not directly save costs, they can detect system risks early and indirectly reduce the cost of problem-solving and potential losses.

Therefore, I believe that high concurrency optimization will play a greater role in the future, and cost savings are the core competitiveness of high concurrency optimization.

The study of this course comes to an end, and it is time to say goodbye. This course can be seen as an index for studying high concurrency systems. If you can read and dig deep, constantly think and practice, you will have more opportunities in the future.

If you encounter any problems, please continue to leave me comments in the comment section.

The industry has been developing rapidly, with various technologies constantly being updated. What awaits us is a vast ocean of knowledge. Let’s strive forward together.

The optimization of high concurrency systems cannot be accomplished in one go, just like personal growth and improvement. Persistence leads to success, and perseverance leads to achievement. I hope that both you and I can overcome obstacles in our future careers and achieve unprecedented success. Goodbye!

Finally, I have prepared a graduation questionnaire for you. I hope you can spend two to three minutes to fill it out. I am very much looking forward to hearing your feedback on this course.