Architecture of the second kill-excerpt from the network

Yesterday the answer is too poor, obviously are some very simple things, I actually answer so bad , let me very frustrated , some conceptual things here do not say, the following two questions, re-comb:

1, the establishment of a consistent hash virtual node mapping relationship with a real node: Now we're using {AAAA ... Aaa,zzzz .... ZZZ} string consisting of a ring, each real server generates n virtual nodes, the virtual node generates rules for, with $i traversal from 0 to N-1, the string "{$i}_{$realServer}" to do MD5, generate a virtual node. If it is {0, 2^32-1} shaping the ring, you can generate n virtual nodes per server, as well as traverse from 0 to N-1, each traversal generates 0 to 2^32-1 a random number, which is the virtual node. 2, seconds to kill the problem: I am not familiar with the second kill business, so here I can only assume business: M users in a point of time to rob N goods, M may be between 0 to tens of millions of, N is 1 to thousands of. To make a system like this, the business will be divided into two stages, the first stage is the start of a time before the start of the second kill, this stage can be called the preparation phase, the user waits for seconds to kill in the preparation phase, the second stage is the start of the second kill to all the users to get the second kill results, this is called the second First of all, there is a page showing the seconds to kill the product, on this page to do a second kill activity began the countdown,in the preparation phase, users will open this second kill page, and may continue to refresh the page. Here are two questions to consider: The first is the display of the second kill page, we know an HTML page is still relatively large, even if the compression, HTTP header and content can be as high as dozens of K, plus other css, JS, pictures and other resources, if there are tens of millions of people involved in a commodity snapped up, General room bandwidth is only 1g~10g, network bandwidth is very likely to become a bottleneck , so this page of static resources should be stored separately, and then put on the CDN node decentralized pressure, because the CDN nodes across the country, can buffer off most of the pressure, but also than the room bandwidth is cheaper ~ The second is the countdown, for performance reasons this is usually called by JS Client local time, it is possible that the client clock and the server clock inconsistency, in addition to the server is also possible clock inconsistencies. Client and server clock inconsistency can take the client timing and server synchronization time, here consider the performance problem, the interface for synchronization time because it does not involve back-end logic, only need to send the current Web server time to the client can be, so fast, as far as my previous test results, A standard Web server 2W+QPS no problem, if 100W people at the same time, 100W QPS also need only 50 web, a hardware LB can be ~, and the Web server farm can easily scale out (Lb+dns polling), This interface can only return a small piece of JSON format data, and can be optimized to reduce unnecessary cookies and other HTTP headers information, so the amount of data is not very large, in general, the network will not become a bottleneck, even if it becomes a bottleneck can also consider multi-machine room dedicated connection, plus intelligent DNS solution; web time synchronization between servers can take the form of a unified time server, such as every 1 minutes for all the Web servers participating in the second-kill activity to synchronize time with the time server.   Preparation Stage is these, the following formally began to kill, two ideas, the first one for the center, the second for the Central. Here is a scenario where 100W people Rob 1 of goods, if the idea of using a central way is obviously not able to engage (I said yesterday the use of the commodity pool is to go to the center of the idea, the evening to think that there is a problem), but this business is likely to be a lot of existence, so we try to use the central idea.   First think of a simple point, 1 products on the centralized commodity server, when a second kill request arrives, we need to lock this product, determine the status of the product, modify the status of the product has been killed in seconds, and then release the lock. This process even if the optimization, and then faster, I will give you a single 100W QPS, if there are 1000W people to kill, 1000W requests from the Web server at the same time, it is not the top, because it can not expand, so we need to think of a way.   I think of the solution is to add a candidate middleware between the Web server and the central commodity server (see the architecture diagram of the attachment), maintaining a candidate queue in the candidate middleware (the sum of the number of queue units in the queue of all candidates needs to be greater than the number of seconds to kill the goods), When the request is forwarded from the Web server, first determine if the queue is full, and if it is not full, queue the request into the queue, all requests after the queue full return the second kill failure. While processing the Web server request, the middleware forwards the request in the queue to the central commodity server (where the producer-consumer model can be used), and the central commodity server returns the result of the previous n successful seconds, returning the end of the second kill. The middleware receives the end of the second kill returned by the commodity server, returns the failure to all requests in the queue, and returns all subsequent requests, which greatly reduces the number of requests from the central commodity server, and even adds a layer of candidate middleware between the candidate middleware and the central commodity server. This form a multi-layered cache architecture, traffic will be reduced after each layer, and finally to the central commodity server traffic control within a certain range.   Finally, there are some single points to consider, where the time server and the back of the central commodity server are single points.    time server is good, you can use a tree-like time server model, all time servers to synchronize the root node time server, and then the Web server settings to synchronize multiple time servers, When one is down, the Web server can also continue to synchronize with another time server, if the root node's time server down, from the lower level of the server to take one out to do root.   Center commodity server can use some synchronous replication techniques, such as the underlying DRBD or mysql-like semi syncHronous. When the luck is too back ~, a commodity server in the second kill the process down, the other can quickly take over. You can also use shared storage, but it is said to be more expensive ha ~.   Write so much, but also spent a figure, exhausted me, it seems the dead of night when the idea of some clear, if there are interview opportunities, please call at midnight, hehe.

The schema of the second kill-excerpt from the network