Hello everyone, I’m Niuniu.

Double eleven is coming again, niuniu a little panic, before a person, do not spend a penny, now have female tickets, not only have to chop hands, also have to help grab a variety of seconds to kill goods.

This year, Niuniu really don’t want to grab seconds to kill, why?

It’s hard. Thousands of people are just staring at what’s on display. Niuniu with more than ten years of single hand speed also rob ah.

Niuniu thought hard, and finally came up with a brilliant idea: tell your girlfriend how the programmer built a second kill system.

Yes, is to drown her in the ocean of knowledge. If she doesn’t want to listen, or doesn’t understand, then she won’t attend singles’ Day this year.

As for the reasons… That is “you don’t listen to me carefully, you must not love me”; If unfortunately she understands, it doesn’t matter, at least let her know how good our programmer brothers are.

So, niuniu found a girlfriend sauce 🐰.

🐮 : Well, do you know that I often do second kill system at work? Today I will tell you how to do seckill, if you understand, this year I will help you steal seckill!

🐰 : but if I don’t understand how to do ah?

🐮 : my baby how possibly listen not to understand, if listen not to understand certainly be I speak not good enough!

🐰 : So… I’ll try

Problems thrown

First of all, what are the considerations of seckill?

The first point, mass request, service to be able to withstand.

When seckill starts, there will be a flood of traffic and millions of people will grab the popular products. This scale of traffic hit down, the service may be hung, the activity is GG, only the harvest of abuse.

How to make the service can fight and resist, is the problem that needs to be considered.

Second, don’t oversold.

Because the second kill is sometimes a loss, the price may be lower than the cost price. And at this time if the quantity than the original plan to sell more, that in the end whether to deliver?

Delivery will exceed the budget loss, if the oversold quantity is too much, maybe the factory will go bankrupt; Failure to deliver goods will lead to complaints, affecting the reputation of the business.

Anyway, it’s hard, can only look for programmers to lose money.

Third, try to avoid selling less.

Selling less will be better than selling more, businesses do not exist on the economic loss. But if the word that is discovered by eagle-eyed consumer, also be unavoidable a trouble. So we want to avoid that as much as possible.

Fourth, make sure to reach users rather than scalpers.

Scalpers may be writing scripts, sending many requests at a time, grabbing them and reselling them. But we do activities, the hope is to reward customers, and then attract users, not to let scalpers make extra money. Therefore, we should try to keep the claws of scalpers at bay.

🐰 : don’t listen, don’t listen, skull pain.

🐮 : No need to chop hands this year

🐰 :?? You go on, I can do it!

🐮 : the problem I said, the following is the focus, to say the solution.

🐰 : I seem to have begun to understand…

Suit the remedy to the case

Hard resistance high concurrency

In the case of high concurrency, MySQL seems to be overwhelmed.

On the one hand, MySQL itself needs to support transaction ACID, the standalone performance is not high.

On the other hand, MySQL is a stand-alone database, which itself cannot be horizontally expanded. If you want to do sub-database sub-table, it takes time and effort.

This is where you can leverage the power of MySQL’s good friend Redis.

Redis can support tens of thousands of writes per second on a single machine, and can be made into a cluster to improve expansion capacity.

We can preload the inventory quota to Redis first, and then deduct it in Redis. The successful deduction will be passed to MySQL through the message queue for real order generation.

Why go through the message queue?

There are two main advantages. One is that this kind of delivery decouples buying from buying. The other is that you can easily limit the frequency, so you don’t overburden MySQL.

Back to Redis, if the number of requests exceeds 6W per second, consider using multiple Redis for streaming. With the expected 100W request volume, we can temporarily schedule 20 Redis instances to support, one 5W/s, leaving some Buffer.

This mode does not need to use Redis Cluster consistent Hash, directly in front of the Nginx, do load balancing can be done.

Refused to oversold

Having solved the problem of high concurrency, let’s look at how to prevent oversold.

Now that we’ve loaded the inventory slots into Redis, we need to count them exactly.

At the heart of our buying scene, there are two steps:

The first step is to judge whether the quota of inventory is sufficient.

The second step, reduce the number of inventory, deduction is successful to grab.

Here is a problem to consider, if the first step to determine the inventory, but because of the concurrent operation, when the actual call, there may be no inventory, which will cause oversold.

So step one and step two are atomic operations.

But Redis does not directly provide this scenario atomization operation.

Don’t panic. If you think about it, Redis has another feature that integrates atomic operations, and that’s it — Lua.

Redis➕Lua, specifically designed to solve atomic problems, invokes multiple Redis commands in Lua scripts, which collectively act as atomic operations.

Try to avoid selling less

What happens when you sell less?

Inventory was reduced, but customer orders were not generated.

How does that happen?

A successful operation in Redis but a failure to send a message to Kafka will consume inventory in Redis for nothing.

As a professional programmer, knowing what a problem is and how it happened solves half the problem. To put it bluntly, we just need to ensure the final consistency of Redis inventory +Kafka consumption.

But the problem of consistency, always the dragon of distributed scenarios, is not easy to deal with.

The first, and simplest, way is to add progressive retry if Kafka delivery fails.

The second, safer option is to record the message on disk and try again slowly.

Third, you may fail before you write to the disk. Consider WAL, but you may end up with WAL like MySQL’s undo log and redo log, which can be quite complicated and unnecessary.

In view of the acceptable problem of selling less extreme scenes, the general choice of the second way can be, after all, it is a small probability of abnormal events, really a problem is the biggest artificial intervention.

To crack down on scalpers

The malign influence of scalpers is often underestimated.

It not only infringes the rights and interests of normal users, but also easily causes a large number of malicious requests because scalpers are good at using scripts, which makes the poor server resources worse.

Generally speaking, in order to crack down on scalpers, the most common way is to limit the purchase, one user can only grab N copies at most, which can greatly protect the rights and interests of normal users.

So in our Lua script, the first step is to query the inventory, the second step is to query the inventory, the third step is to query the inventory, the fourth step is to record the number of purchases by users.

Note that if a Redis cluster is used, the Redis consistent Hash Key must be divided by user; otherwise, user data cannot be queried.

With the purchase limit, we can ensure that the goods will not be occupied too much by scalpers. Then there is still a problem. Scalpers mostly buy the goods by code, and the click speed is much faster than human clicks, which leads to unfair competition.

As the ultimate coder, we hope to go further and achieve fair competition.

How do you solve it? If a user requests an interface too frequently, the user is running a script. You can limit the request only for the user.

It is also common to restrict IP addresses. However, it is easy to kill people by mistake. Users on the same network may use the same egress IP address. If IP addresses are restricted, normal users are affected.

A better solution is to add a captcha. Captchas conform to rule 91, 90% of the time is spent entering captchas, so the impact of scripting clicks is minimal.

Of course, we need to understand that there is no silver bullet, the downside of this approach is that it reduces the user experience. Epilogue 🐮 : In this way, our second kill scene is basically OK!

🐰 : 😣 😣 😣

🐮 : What do you think?

🐰 : Uh-huh! (nodding guiltily) Can we go kill it?

🐮 : Let me check it out?

🐰 : AM I not your baby? 😰 😰 😰

🐮 helplessly sigh: say, you want to rob what thing again this time?

Back to reality

The ideal is beautiful, but the reality is…

Niuniu heart bitter, niuniu dare not say 😭😭😭