First, why difficult
The reason is difficult spike system: inventory only one, everyone will read and write data in a set time.
For example, every Tuesday spike millet phone, the phone may be only 10,000, but the instantaneous incoming traffic may be hundreds of tens of millions.
Another example is 12306 grab votes, also similar to the spike, instantaneous flow even more.
Second, common architecture
Traffic to one hundred million level, a common site architecture as:
1) the browser side, top, performs some JS code
2) Site tier, which will access back-end data, the fight html page returned to the browser
3) the service layer, the details of the underlying data to the upstream shield
4) the data layer, the final stock is present here, mysql is a typical
Third, optimization direction
1) The request interceptor in the system as much as possible upstream of : the reason why a conventional spike hanging system, the requests are overwhelmed backend data layer, the data read-write lock serious conflict Complicated slow response, nearly all requests time out, the flow rate is great, single effective flow of success is very small [a train in fact only 2,000 tickets, 200w people to buy, basically no one can buy success, the effective rate request 0]
2) full use of the cache : This is a typical read multi-application scenarios [Xieshao a train in fact only 2,000 tickets, 200w people to buy, at a maximum of 2000 single personal success, others are check inventory, write ratio of only 0.1 %, accounting for 99.9% reading ratio], very suitable for use caching
Fourth, optimization details
4.1) browser layer intercepts requests
After clicking the "Search" button, the card ah, ah slow up the progress bar, as a user, will unconsciously go click "Search" and continue to point, point to continue, little point. . . Useful? No reason to increase the load on the system (a user point five times, 80% of the requests are so many out), how the whole?
a) after the product level, the user clicks the "Search" or "tickets" button is grayed out, ban users who repeatedly submit requests
B) the JS level, to limit the user in x seconds only submit a request
So limiting, 80% of the traffic has stopped
4.2) layer request interceptor site and page caching
Request the browser layer interception, stopped only white users (but this is 99% of the user yo), high-end programmers simply do not eat that, write a for loop, you directly call the backend http request, how the whole ?
a) the same UID, restrict access frequency, do page cache , the request reaches the site of the layer of x seconds, both return the same page
b) a query of the same item, such as mobile phones trips, do page caching , request arriving at the site level in x seconds, both return the same page
So limiting, another 99% of the traffic will be blocked at the site level
4.3) the service layer requests intercepted and data caches
Request to intercept the site level, only to stop ordinary programmers, senior hacker, assuming he controlled 10w broiler (and assuming a ticket does not require real-name authentication), which under the uid restrictions to die, right? How the whole?
a) Big Brother, I was the service layer, I clearly know that only 10,000 millet phone, I clearly know a train ticket only 2000, I thoroughly 10w requests to the database what is it? For a write request, the request queue to do, through a time of limited write requests to the data layer , if a group were successfully put down again, if the queue is not enough inventory write request to return all "sold out"
b) For a read request , it goes without saying it? cache to resist , whether memcached or redis, a stand-alone anti-10w per second should all be no problem
So limiting, very few write requests, and requests very little read cache mis will go through to the data layer, there are 99.9% of the requests are stopped
4.4) the data layer strolling
The data to this layer, almost no requests, but also stand-alone Go On, then again, stock is limited, millet production capacity is limited, through too many requests to the database does not make sense.
