Cache penetration
Description: query the database does not exist in the data, in the case of high concurrency, pressure is concentrated in a database
solution:
- 1) A null value Null is also placed in the database, provided a short expiration time.
- 2) bloom filter
Cache avalanche
Description: cache at the same time a large number of key expired, resulting in a request directly to the database.
solution:
- 1) separate cache of time, while avoiding a large number of key expired.
Cache breakdown
Description: The key to a large number of requests is about to expire when the key expires, all requests by caching directly to the database
solution:
- 1) Cache locked, if the key does not exist on the lock, and then query the database, the same as other request, if there is a lock wait, wait in unlocking query data.
Database and cache coherency
Description: Scene One: When updating data, such as updating an inventory of goods, merchandise inventory is currently 100, now updated to 99, first update the database changes to 99, and then delete the cache, delete cache found failed, which means inventory data is 99, and the cache is 100, which leads to inconsistencies in the database and cache.
solution:
- 1) First delete cache, delete cache successfully, and then delete the database data. Failed to delete cache, the database is not deleted.
Description: Scene 2: a modified data has not been submitted to the database, but the cache data has been deleted. This time, if there is a query over the old data has been added to the cache. Prior to this cache expires, the request is old data
solutions: Solutions Online ::: given this is the case, you can use the queue to solve this, create several queues, such as 20, according to the commodity ID do the hash value, then the number of taken queue touch, when a data update request, it is thrown into the first queue to go, after the update when removed from the queue, if the update process is encountered the scenario above, go look there is no data cache, if not, you can go to the queue to see if the same product ID in doing the update, if there is also a request to send a query to the queue to go, then wait for the synchronization cache update complete .
There is an optimal point, if found to queue a query request, and then do not put new query go with a while (true) loop to query cache, loop around a 200MS, if the cache has not been directly database taken old data, it is generally taken to be.