Spike question:
1. Front:
- A sudden increase in network access bandwidth
- Users may submit duplicate
2. Rear:
Commodity oversold: database optimistic locking (CAS no lock), Redis distributed lock, MQ Asynchronous modified form of inventory (users need to wait)
Stand-alone pressure: a separate service in the form of a deployment + docker. You can achieve rapid expansion
User operating frequency blocks: Gateway limiting
Users cheating:
Database Access pressure: sub-table and warehouses, using MQ asynchronously modify inventory. Similar: waiting for rush tickets rush tickets 30s before we know the results.
Front-end optimization program:
For example: If the bandwidth is equal to 1m 128kb / s to load a page 640kb. It requires 640kb / 128kb = 5s. If the spike does not come out when page load is finished.
This will involve a question of bandwidth entrance, server production environment to buy bandwidth.
Optimization: static and dynamic separation
