怎么保证缓存和数据库的双写一致性

https://blog.youkuaiyun.com/chang384915878/article/details/86756463
http://www.bubuko.com/infodetail-3110648.html

1.Cache Aside Pattern

最经典的缓存+数据库读写模式

• 读的时候，限度缓存，缓存没有在读数据库，然后取出数据放入缓存，同时响应
• 更新时，先更新数据库，再删除缓存

为什么是删除缓存不是更新缓存？
因为可能存入到缓存中的是一个经过复杂运算的数值，在更新数据库时，并不是每次都将这个复杂运算的值取出来，所以使用一个懒加载色思想，先删除缓存，等什么时候需要在什么时候进行加载

在高并发情况下，出现数据库和缓存双写不一致问题？
1.最初的数据库和缓存不一致问题
问题：
先修改数据库,再修改缓存库(修改超时),如果删除缓存失败了,那么会导致数据库中是新数据,缓存中的旧数据,数据出现不一致的问题.
解决：
先删除缓存,再修改数据库,如果缓存删除成功了,修改数据库失败了,那么数据库中依旧是旧数据,缓存中是空的.那么数据不会不一致.
2.问题：
数据发生变更，先删除缓存，然后修改数据库，此时还没修改，一个请求去读缓存，发现缓存空了，去数据库中查询，查询的是旧数据，放到缓存中，从而造成数据不一致
3.为什么上衣流量高并发场景下，缓存会出现这个问题
只有在对一个数据在并发的进行读写的时候，才会出现这个问题。
如果说你的并发量很低的话,特别是读并发很低,每天访问量就1万次,那么很少的情况下,会出现刚才描述的那种不一致的场景
问题是,如果每天的是上亿的流量的话,每秒并发读是几万,每秒只要有数据更新的请求,就可能出现上述的数据库+缓存不一致的情况.
解决：
在更新数据时，根据数据唯一标识，将数据路由之后，发送到另一个jvm内存的队列中
读取数据的时候，如果发现数据不在缓存中，那么重新读取数据 +更新缓存操作，根据唯一表示路由之后，也发送同一个jvm内部的队列中，
一个队列对应一个工作线程，每个工作线程串行拿到对应的操作，然后一条一条的执行。这样的话，一个数据变更的操作，先删除缓存，然后再去更新数据库，但是还没完成更新。此时如果一个读请求过来，读到了空的缓存，那么可以先将缓存更新的请求发送到队列中，此时会在队列中积压，然后同步等待缓存更新完成。

这里有一个优点化,一个队列中,其实多个更新缓存请求串在一起是没意义的,因此可以做过滤,如果发现队列中已经有一个更新缓存的请求了,那么就不用再放个更新请求操作进去了,直接等待前面的更新操作完成即待那个队列对应的工作线程完成了上一个操作的数据库的修改之后,才会去执行下一个操作,也就是缓存更新的操作.,此时会从数据库中读取最新的值,然后写入缓存中
如果请求还在等待时间范围内,不断轮询发现可以取到值了,那么就直接返回,如果请求等待的时间超过了一定时长,那么这一次直接从数据库中读取当前的旧值.

高并发的场景，解决方案应注意：

• 读请求长时阻塞
  由于读请求进行了非常轻度的异步化，所以一定要注意读超时的问题，每个读请求必须在超时时间范围内返回。

该解决方案，最大的风险点在于说，可能数据更新很频繁，导致队列中积压了大量更新操作在里面，然后读请求会发生大量的超时，最后导致大量的请求直接走数据库。务必通过一些模拟真实的测试，看看更新数据的频率是怎样的。

另外一点，因为一个队列中，可能会积压针对多个数据项的更新操作，因此需要根据自己的业务情况进行测试，可能需要部署多个服务，每个服务分摊一些数据的更新操作。如果一个内存队列里居然会挤压 100 个商品的库存修改操作，每隔库存修改操作要耗费 10ms 去完成，那么最后一个商品的读请求，可能等待 10 * 100 = 1000ms = 1s 后，才能得到数据，这个时候就导致读请求的长时阻塞。

一定要做根据实际业务系统的运行情况，去进行一些压力测试，和模拟线上环境，去看看最繁忙的时候，内存队列可能会挤压多少更新操作，可能会导致最后一个更新操作对应的读请求，会 hang 多少时间，如果读请求在 200ms 返回，如果你计算过后，哪怕是最繁忙的时候，积压 10 个更新操作，最多等待 200ms，那还可以的。

如果一个内存队列中可能积压的更新操作特别多，那么你就要加机器，让每个机器上部署的服务实例处理更少的数据，那么每个内存队列中积压的更新操作就会越少。

其实根据之前的项目经验，一般来说，数据的写频率是很低的，因此实际上正常来说，在队列中积压的更新操作应该是很少的。像这种针对读高并发、读缓存架构的项目，一般来说写请求是非常少的，每秒的 QPS 能到几百就不错了。

我们来实际粗略测算一下。

如果一秒有 500 的写操作，如果分成 5 个时间片，每 200ms 就 100 个写操作，放到 20 个内存队列中，每个内存队列，可能就积压 5 个写操作。每个写操作性能测试后，一般是在 20ms 左右就完成，那么针对每个内存队列的数据的读请求，也就最多 hang 一会儿，200ms 以内肯定能返回了。

经过刚才简单的测算，我们知道，单机支撑的写 QPS 在几百是没问题的，如果写 QPS 扩大了 10 倍，那么就扩容机器，扩容 10 倍的机器，每个机器 20 个队列

• 读请求并发量过高
  这里还必须做好压力测试，确保恰巧碰上上述情况的时候，还有一个风险，就是突然间大量读请求会在几十毫秒的延时 hang 在服务上，看服务能不能扛的住，需要多少机器才能扛住最大的极限情况的峰值。

但是因为并不是所有的数据都在同一时间更新，缓存也不会同一时间失效，所以每次可能也就是少数数据的缓存失效了，然后那些数据对应的读请求过来，并发量应该也不会特别大。

• 多服务实例部署的请求路由
  可能这个服务部署了多个实例，那么必须保证说，执行数据更新操作，以及执行缓存更新操作的请求，都通过 Nginx 服务器路由到相同的服务实例上。

比如说，对同一个商品的读写请求，全部路由到同一台机器上。可以自己去做服务间的按照某个请求参数的 hash 路由，也可以用 Nginx 的 hash 路由功能等等。

• 热点商品的路由问题，导致请求倾斜
  万一某个商品的读写请求特别高，全部打到相同的机器的相同的队列里面去了，可能会造成某台机器的压力过大。就是说，因为只有在商品数据更新的时候才会清空缓存，然后才会导致读写并发，所以其实要根据业务系统去看，如果更新频率不是太高的话，这个问题的影响并不是特别大，但是的确可能某些机器的负载会高一些。

https://blog.youkuaiyun.com/qq_32534441/article/details/89681281
1.
（1）更新数据库数据；
（2）缓存因为种种问题删除失败
（3）将需要删除的key发送至消息队列
（4）自己消费消息，获得需要删除的key
（5）继续重试删除操作，直到成功

（1）更新数据库数据
（2）数据库会将操作信息写入binlog日志当中
（3）订阅程序提取出所需要的数据以及key
（4）另起一段非业务代码，获得该信息
（5）尝试删除缓存操作，发现删除失败
（6）将这些信息发送至消息队列
（7）重新从消息队列中获得该数据，重试操作。