数据库和缓存一致性方案

Cache Aside Pattern

1. redis存储缓存，mysql存储数据。缓存进行有效期设置。但是更新mysql，不会更新缓存。这样导致缓存和数据库的一致性问题比较长
2. mysql更新后，进行更新redis缓存。查询的时候先查询redis缓存，如果没有缓存，只查询数据库进行更新缓存；缓存和数据库不一致性的时间短 Cache Aside Pattern
3. mysql更新后，通过mq消息消费，异步进行redis更新；这样可以减少连接过多的问题；但是无法解决时序性问题，同样的键值被两个服务更新后。但是无法保证进入消息系统的顺序是准确的
4. 监听binlog，时序性问题得到解决；也进行了异步控制

 

Write Through   (erp系统编辑商品名称之类的，需要同步写入缓存，erp系统的写入速度无要求)

1. 在数据更新时，同时写入缓存Cache和后端存储
2. 缺点 写入速度较慢

write-around

1. 我就直接写后端数据，这样让缓存自动失效之后，再刷新一遍
2. 优点简单，不会丢失数据
3. 缺点缓存和数据库会有不一致的情况

Write-Behind  Write back  

1. Write-Behind 在数据更新时，只写入缓存。优点是数据写入速度快，适用于繁重的写工作负载。与 Read-Through 配合使用，可以很好地用于混合工作负载，最近更新和访问的数据总是在缓存中可用
2. 操作就是只更新缓存，只有当缓存被替换时才进行持久化
3. 数据容易丢失

Read-Through

1. 应用程序无需管理数据源和缓存，只需要将数据源的同步委托给缓存提供程序 Cache Provider 即可。所有数据交互都是通过抽象缓存层完成的。
2. 对于应用模块编码比较简单，缺点是需要额外的服务cache privider