Three in all , Are mainly based on the resume to ask the project .
1. Describe the logic process of second kill system ?
1） First of all, there are commodity list page and commodity details page in seckill system , When the user clicks on the item that he wants to kill in seconds on the item list page , Will jump to the product details page , There will be a countdown on the product details page , If the second kill time is not reached, or the second kill time is over, or the goods are sold out , The instant kill button is gray , Can't click .
2） If it's the second kill time , The user clicks the button to kill immediately , After the request arrives at the back end, it will first determine whether the user is logged in （ from cookies Read from sessionId, And go redis Passed in sessionId Find user information ）, If you are not logged in , Return to the login page .
If you log in , Then judge whether the seckill path has been generated for this user and this product （redis Is there a record in the uid_gid）, without , A random uuid and MD5 After encryption, it is added to the seckill path as the exclusive seckill path of this user , take uid_gid As key,path As value Put in redis in .
4） The user sends a seckill request to the back end through this seckill path , Back end verification path Is it related to redis Consistency recorded in . If they are consistent, we can judge whether this product is in the market redis Is the inventory of records in >0. Then judge whether the inventory has been reduced for this user （ see redis Has it been recorded in ）, If not, judge redis Is there an order for this user to purchase this product in , If not, the implementation of pre reduction inventory , That is, first redis The inventory of this commodity decreased 1, And record the inventory of this product reduced for this user .
5） Put the second kill message into the message queue , Mainly users id And commodities id, The execution of the consumer thread that has been listening to the message queue sql Inventory reduction ,sql Statement will also determine whether the inventory is greater than zero , And generate order records , Inventory reduction and order generation are in one transaction .
6） Front end use ajax Continuously polling order generation status (result=0 It means in line ), if result =
-1 Description failed , Direct return to seckill failed . Until we found the order id, Put the order in the redis in , And it's displayed on the front end .
2. How to prevent oversold ? What cache update strategy do you use ?
When reading, read the cache first , There is no reread database in the cache , And put it in the cache .
There are two strategies for writing , One is to delete the data in the cache first （ Generally speaking, deleting the data in the cache directly is faster than updating the data ）, Update the database again , This strategy frequently updates the same row of data in the case of high concurrency, which makes it easy for the traffic to go directly to the database , The cache is useless . And when the database has not been updated , There's a new request to read the same row , The old values are put back into the cache . So when we reduce inventory , It's first redis Inventory reduction in advance , Then the consumer asynchronously goes to the database to reduce inventory , There may be inconsistencies between the cache and the data in the database , But there will be no oversold .
The other is to update the database first , Delete cache again , But if the database is updated , The cache hasn't been deleted yet , It also causes the old values in the cache to be read .
3. If redis What about downtime ?
first redis The master-slave architecture can be used + Sentinel mechanism , The data from the slave server is copied from the master server （ There are two steps ： complete / Partial resynchronization , Command propagation ： After the master writes, the slave also writes ）, Let the sentry keep an eye on all the soldiers redis The server , When the master dies , Perform the active / standby switch .
secondly redis There is a persistence mechanism , Snapshot based RDB Ways and means AOF（append-only-file） mode , If it does hang up, you can also restore the data from the disk . When redis When recovering data , Local caching should be used + The current limiting mode protects the database from being crushed by high concurrent traffic .
4. How to ensure the order of consumers' tasks ?
Only one queue was used , yes direct Type , In the queue binding_key And the routing_key Same time , Messages are routed to this queue . Each time a consumer fetches a message from this queue for consumption , It must be in order .
5. If there are too many tasks in the queue , What if a queue can't hold ?
Use multiple queues , According to the commodity id Will be the same id All the products are routed to the same queue .
6. If url Additive parameter , The order of the parameters may be different , What's wrong with this situation url duplicate removal ?
Take out the parameters and sort them before splicing , Put it in again HashMap Medium to heavy .
7. hd Key management of wallet , How to find out whether a key is generated by the master key in the tree ?
There will be a record of the path .
8. If there is no path , How to search , And there's a huge amount of data ?
You can use Bloom filters to record private keys .
9. algorithm ： Implement a lru cache
10. Memory management of operating system , How does a process know how much memory it can use ?
Processes don't need to know which addresses they can use , The process thinks it can use all the virtual memory space , Specific physical memory used , With operating system implementation .
11.ip How to realize error control in packet ?
Pass the check sum
12. ip What should we do if the routing address is looped ?
There is a limit to the number of hops , At most 16 jump .