Redis 缓存一致性、热点key方案总结和看法

1，缓存一致性问题：

1.1 cache aside 模式：先改数据库在失效缓存，极端情况下可能出现不一致，完全可以忽略，或者如果失效缓存失败，可以记录下失败日志，事后恢复。

1.2 延时双删：失效缓存 --> 改数据库-->延时一定时间 -->失效缓存，如果高并发场景下，频繁失效缓存，导致2倍的请求落到MySQL里面，性能损失严重。

缓存的语义就是允许短暂的数据不一致。如果业务需要一定要读到最新的数据，则完全可以在写操作的时候，提前对缓存设置一个marker标记，后续的读请求自定判断是监听这个Marker还是读取暂时是旧的缓存。

1.3 先失效缓存再改数据库 简直是搞笑。稍微并发场景下肯定会出现读取到旧的缓存，而且坑爹的是你还不知道哪些缓存是旧的。

2，热点key的缓存一致性问题（高并发场景下缓存一致性问题）：

问题原因：在采用1方案解决缓存一致性问题下，频繁失效缓存，导致请求频繁落到MySQL上，也是一场性能灾难。甚至在并发读的情况下，会出现多次读MySQL然后重复设置缓存的情况。

2.1 内存队列排队请求：多次写，可以排队；多次读只读一次就可以了。问题：有宕机风险；内存超限风险。

2.2 Marker标记：在写操作失效缓存的时候，设置一个唯一的标记Marker:比如：${key}_MARKER_${全局唯一号}，并发读的时候，只允许一个读线程去读MYSQL，其他读操作在这个Marker标记上面等待，直到读线程返回数据,删除Marker

如果在读操作进行的时候又一个写操作失效