"Seckill" means a huge challenge for programmers.
- How to make the system face million-level request traffic without failure?
- How to ensure consistent writing of data under high concurrency?
- How to deal with concurrent access that is hundreds or even thousands of times the usual amount without stacking servers?
- How to optimize the server end for high-flow read and write requests respectively?
You will find the answer in this note.
This note hopes to give you a thorough understanding of the key technical points of the seckill system. I hope that after you finish the study, you can quickly build a high-availability seckill system that meets your business scenarios. What's more, we hope to use the typical representative of "Seckill" in the high-concurrency Internet scene to show you how to build a system architecture with large-traffic concurrent reading and writing, high performance, and high availability.
Each node has a navigation bookmark page on the left, which is very convenient to read. Since there are many contents, here is a part of the screenshot. Code friends
who need it , please support it three times (it can help more people see it) !)
What are the key points in the design of seckill system architecture?
- high performance
- consistency
- high availability
5 Architectural Principles You Should Pay Attention to When Designing a Seckill System
- Architectural principles: "4 to 1 not to"
- Data should be as little as possible
- Keep the number of requests to a minimum
- keep the path as short as possible
- rely as little as possible
- don't have a single point
- Different Architecture Cases in Different Scenarios
How can we separate dynamic and static? What options are available?
- What is dynamic data
- How to do the transformation of dynamic and static separation
- Several architectural schemes for dynamic and static separation
- Solution 1: Deployment on a single physical machine
- Solution 2: Unified Cache layer
- Solution 3: Go to CDN
Twenty-eight principles: deal with the system's "hot data" in a targeted manner
- Why focus on hot spots
- What is a "hot spot"
- Discover hot data
- Handle hot data
What should be done about traffic peak clipping?
- why clipping
- queue
- answer questions
- Hierarchical filtering
What are the factors that affect performance? And how to improve the performance of the system?
- Factors Affecting Performance
- How to spot bottlenecks
- How to optimize the system
- reduce coding
- reduce serialization
- Java extreme optimization
- concurrent read optimization
The core logic of the "reduction of inventory" design of the seckill system
- What are the ways to reduce inventory
- Possible problems with inventory reduction
- How to reduce inventory in a large flash sale?
- The ultimate optimization of flash sales and inventory reduction
How to design a bottom-up plan?
- Where should high-availability construction start?
- downgrade
- Limiting
- denial of service
General catalog display
This note has a total of eight nodes (from shallow to deep), divided into three major modules.
High performance: seckill involves a large number of concurrent reads and writes, so it is very important to support high concurrent access. This note will focus on four aspects: dynamic and static separation of design data, discovery and isolation of hotspots, peak shaving and hierarchical filtering of requests, and extreme optimization of the server.
Consistency: The implementation of inventory reduction in seckill is also critical. It is conceivable that a limited number of goods are requested many times at the same time to reduce the inventory at the same time. The inventory reduction is divided into "photographic inventory reduction", "payment inventory reduction" and withholding. The accuracy of the data must be ensured in the process, and the difficulty can be imagined. Therefore, a node will be used to specifically explain how to design a flash sale and inventory reduction plan.
High availability: Although many extreme optimization ideas have been introduced, there are always some situations that we cannot consider in reality. Therefore, to ensure the high availability and correctness of the system, we must also design a PlanB to cover the bottom line, so that in the worst case Still be able to deal with it calmly when it happens. At the end of the notes, it will take you to think about which links can be used to design a bottom-up plan.
The space is limited, and it is impossible to display each module in detail (these points are collected in this "High Concurrency Spike Architecture Booklet")
Due to too much content, only part of the content is intercepted here. Friends who need this " High Concurrency Spike Architecture Booklet ", please like, share and support it (it can help more people see it!)!