One, foreword

When it comes to seckill, people think of high performance, high concurrency, high availability, large flow… . In the e-commerce system, the trading system occupies half of the link. For example, what’s the architecture involved in the fascinating seckill system? What business will be involved?

The mason said to himself: Kill this thing in a second, a whole article can not finish. I will start this article, and the practical series will follow, so stay tuned.

Second, second kill business difficulties

Second kill business difficulties, summed up in two points – concurrent multi – read

  • Concurrent write less

This is different from some scenarios, preferential marketing system, will only be a user read multiple data, but also will be a large flow of read operations. But there are no writes.

Concurrent read: Multiple users concurrently read one data. For example, There is only one stock of Huawei mobile phones. There could be tens of millions of people competing for this inventory data. Does not include a lot of meat machine in the brush. Many users are reading data about an item + the inventory of that item.

Concurrent write less, fewer users concurrently write one data. For example, how to limit the flow when only a few write requests operate on the data layer? Only one person can grab it. How to solve the oversold problem?

For example, 12306 grab tickets, grab red envelopes what, instantaneous flow is greater. That makes it harder to design

Second kill architecture theory

I think of some laws of architecture: Murphy’s Law, Conway’s Law and so on. Any design practice must come from some theory and law.

Some architectural theories of seckill (what I think) :

  • High concurrency principle
  • High availability principle
  • Consistent design

A. High concurrency principle

1. Servitization

It is a commonplace to talk about servitization. There are Spring Cloud, Dubbo and other servitization solutions. Consider service isolation, traffic limiting, timeouts, retries, compensation, and so on

2, caching,

Layer upon layer. Three layers are commonly considered: user layer, application layer and data layer.

User layer: DNS Cache, APP Cache (images, etc.) Application layer: static pages, MQ, Redis and other data layer: NoSQL, MySQL built-in Query Cache

Consider: caching is not a panacea, it is definitely about optimizing various request data, request nodes, request dependencies, etc

3, break up

Long parts must unite, long parts. Various splits:

  • System dimension: by business module. Such as the trading system in the e-commerce system, commodity system and so on
  • Function dimension: by function module. Such as trading system in the order system, refund system
  • Read/write dimension: Based on the read/write ratio. For example, commodity write service and commodity read service in commodity system
  • Module dimension: according to code characteristics. Such as sub – library sub – table, project moudle, code sub – three – layer architecture

Consider: just like MyCat and other sub-library sub-table components, natural support for read and write separation…

File 4. Concurrency

Serial for parallel. Specific practice, specific scenario analysis and optimization.

B. High availability principle

1, the drop

Used for service dependency isolation, fallback degradation, and avalanche prevention. Specific model selection: Hystrix, etc

In addition, can do configuration, switch service degradation. Core functions are guaranteed, secondary functions are optimized for asynchronous or shielding. For example, on Singles’ Day, certain evaluation functions will be turned off.

2, current limiting

Prevent requests from attacking or exceeding the system peak. For details, please refer to the RateLimiter of Guava. Specific methods are also included: malicious traffic accessing the Cache

3, can be rolled back

If the release version fails or the cable is faulty, the system will immediately revert to the last stable version. Thinking: that general operation and maintenance team, there will be a whole set of grayscale release, rollback mechanism.

Iv. Business Design & summary

The following (important) considerations should also be taken into account when a kill business is involved:

  • Power etc.
  • The heavy
  • Data consistency
  • Data static and static separation
  • Request peak clipping
  • The backup

This idea is organized and started. In general directions:

  1. Request as little data as possible, network IO as little as possible. Including request data + return data; Compression; Data service RT as little as possible, data connection times.
  2. The access path should be as short as possible, with fewer nodes and less consumption
  3. Avoid single points of failure and have backups

Write at the end:

For Java architecture design, I sorted out some learning materials and videos for you, save you to go to the Internet to find information, I hope to help you!

How to receive information: Join the fan group963944895.Click to join the group chat, private message administrator can