When it comes to rush purchases, there are two types of opinions. Those who are arrogant always treat the losers as fools, so as to sell some "fake black technology", or there are other types of people who show all kinds of servers that you don't understand at all. Terminal technology, CDN, order lock, Redis cache, etc.
Speaking of internet speed and hand speed is actually talking about luck. If your internet speed is not good and your hand speed is slow, there is a high probability that the next door will not be much better. This is not the root of the problem. The chrysanthemum turned out for a long time and came out of no stock. This is actually a wrong design and not your problem. Everyone is caught in the details, and no one can see it, let alone improve it.
You have to receive chrysanthemums for a long time to give you the conclusion that there is no inventory, but at the same time, you also have the probability of success, and how big the probability is depends on luck.
My method is not to participate in the snap-up. If I have to participate, I would rather avoid the peak and pick up leaks.
The specific method is to only click once in the first 5 minutes of the panic purchase, and let it be fate. If it fails, it will not try again, or only try again two or three times, but it will definitely not be too much. Then do your own thing, and try again two or three times in your spare time. If you fail, don't try again, and continue to do your own thing. Give it a try, and you will have a better chance of success.
Almost all merchants, from 12306 to the small supermarket at the entrance of the community, will not bulk up all the goods at one time, but generally divide them into several batches, and each batch will deliberately leave some "leakage". For example, if there are 1000 pairs of leather shoes, 8 o'clock, the merchant will put 480 pairs, and then put 20 pairs in 5 minutes or 10 minutes or 20 minutes, 280 pairs at 12 o'clock, 20 pairs after 5 minutes or 10 minutes... almost The platforms you have used are almost the same.
Leak detection is not only based on batches and volume, but also because there will always be people who fail to pay, lose power in their mobile phones, disconnect from the Internet, and return goods.
The key is not to click and click repeatedly. When you bring DDoS to the server, you also DDoS yourself. If you toss for ten or twenty minutes until your hands are shaking and you are in a very bad mood, can you still do your normal work for a day? ?
Now let's talk about the back-end design.
Online shopping is just one type of online service. In recent years, related technologies have focused on trees rather than forests. Everyone spends a lot of energy on optimizing a lock, but they forget that what is really important is "let users succeed quickly, or fail quickly!" .
Fast success or fast failure is not a problem at all under uniform traffic. The service is not overloaded. The success rate of P999 is obviously high, but the system load has a certain or elastic or exact threshold. Once overloaded, even if it is only slightly overloaded, the failure rate will greatly increase. , which is reflected in the business indicators, that is, the user experience declines.
The root of this problem is that the online service completely simulates the offline service, which is wrong.
Offline services can smoothly limit traffic naturally, such as shopping mall promotions, the time you spend on the road, traffic jams, parking, waiting for traffic lights, these traffic limitations are natural, but online services are different, any number of requests are allowed to arrive at any time. Any server, the so-called throttling just throws away overloaded requests, but retry will come soon.
The network protocol stack will retry at multiple levels. For example, if the SYN of TCP is lost, a new SYN will come over immediately. TCP does not know that it is overloaded. Retrying packets will aggravate the overload, and eventually the system will effectively process the capacity index. If TCP knows that overload is causing packet loss, source suppression will allow the system to handle more valid requests instead of handling the overload.
Switching nodes and servers lack source suppression for congestion, which is the root cause of online services being easily overloaded and difficult to recover. It takes RTT-level time for congestion to be fed back to the source. Enough to get things out of hand, ranging from massive user failures to server downfalls.
The user's retry behavior exacerbates the overload. While many frontends limit the number of retries the same user can retry for a fixed period of time, ambiguous error messages can trigger users to try their luck again after the limit is lifted, unaware that they have failed completely.
The user waited for a long time only to be told that it failed. This poor experience is not because the server is really "trying to judge". From a global perspective, the server has long known that you failed, but it just didn't tell you, why didn't you tell you, because the server architecture is based on microservice interaction, and each microservice interacts not with your terminal APP, but its Upstream or downstream microservices, that's why I said the root cause is seeing the trees and not the forest.
It's not that the problem is easy to solve, it's just that no one cares. If all the processing logic in the backend is based on user experience, things will be easier. The rush purchase only gives each request one chance. If any part of the server processing fails, you will be out of the game. You will not retry the part, no longer wait, and directly feedback "complete failure" to the user as soon as possible. As for the unsold items caused by one chance for each request, follow-up heavy volume is added, which not only improves the user experience, but also makes the sales smoother and reduces the burst.
Finally, talk about an effective measure to build a tunnel.
Take a look at the diagram below:
If
you have a clear and better route to the server, then tunnel or proxy through that route, it's definitely better than going through the public internet, even with a CDN, you need to know that CDNs are not exclusive to you either. Everything is subject to RTT, bandwidth measurement.
Buying things has become a problem recently, group buying, meat dishes, grabbing beer, many people do this all day long, which has seriously affected their work and life. Anything must be done, life must be flexible, life must be able to accept loss. About snapping, write a little about your own experience.
Wenzhou, Zhejiang, the leather shoes are wet, and it will not get fat when it rains.