当前位置:网站首页>Data consistency of cache

Data consistency of cache

2020-11-09 14:53:50 army

Write cache and write data , Because it's not atomic , So it will cause data inconsistency . Should we write the database first or operate the cache first , Is cache operation update or delete ?
Any design that leaves the business is a rogue . Let's imagine a scene ,A After the service updates the cache , For a long time no one visited ,B The service also updated the cache , that A The updated cache is useless ? What's more , If this cached calculation , It's extremely complicated 、 Time-consuming 、 Resource intensive , A few more database operations , This is a big expense . So we chose to delete , Only when it's used , To compute the cache , When you don't use caching , No calculations , The disadvantage is that the first visit may be slow .
Now there are two situations left :

  1. Write the database first , Delete the cache .
  2. So let's delete the cache , Write the database again .

in addition , We also consider concurrency and failure .

Database first

Concurrent

As shown in the figure below :

  1. service A Update data , hold 100 Change to 99, Then delete the cache .
  2. service B Read cache , At this point, the cache is empty , Read from database 99.
  3. service C Update data , hold 99 Change to 98, Then delete the cache .
  4. service B The assignment cache is 99.

here , The database for 98, But the cache is 99, Data inconsistency .
image.png

fault

As shown in the figure below :

  1. service A Update data , hold 100 Change to 99.
  2. service A Delete cache failed .
  3. service B Read cache , by 100.

At this time, the cache data is inconsistent with the database data
image.png

The cache first

Concurrent

As shown in the figure below :

  1. service A Delete cache .
  2. service B Read cache .
  3. service B Can't read cache , Just read the database , This is the case 100.
  4. service A Update the database .

At this time, the cache data is inconsistent with the database data
image.png

fault

As shown in the figure below :

  1. service A Update cache .
  2. service A Database update failed .
  3. service B Read cache .
  4. service B Read database .

Because the database has not been changed , So the cache data is consistent with the database data .
image.png

Solution

Business

Any design that leaves the business is a rogue . If the business can accept this inconsistency , Then use Cache Aside Pattern. If business doesn't accept , That allows businesses with strong consistency requirements to read the database directly , But this performance will be very poor , So we have the following serial solution .

Serial

stay java in , Multithreading has data security issues , We can use synchronized and cas To solve , The main idea is to change parallel to serial .
Train of thought : Through message queuing
Push all requests into the queue , Because of the requested key Too much , May, in accordance with the hash The way to take the mold , hold key Spread to a limited queue . Such as the 3 A queue ,hash(key)=0, Put it in the first queue .
The deposit is read 、 read 、 Write 、 read 、 read 、 Write , When it comes to execution , The order of deposit is the same , Because of the same key The operation of is serial , So the consistency of the data is guaranteed .
image.png
Train of thought two : Through distributed locks
In the scheme above , If there are too many queues , It's not easy to manage , If there are too few queues , So many key Queuing affects performance , So we can do it with distributed locks . The method here is similar to synchronized and cas, Only when you get the lock , To operate , This can also ensure data consistency .
Of course, either way , The relationship between data consistency and performance is inversely proportional . High data consistency is required , Performance will decline ; The requirement of data consistency is not high , Performance will go up .

版权声明
本文为[army]所创,转载请带上原文链接,感谢