最近阅读了一篇文章,说的是缓存和数据库在双写场景，如何保持数据一致性,其中介绍了三种经典的缓存读写策略

首先这篇文章先介绍了一下关于一致性这个概念

一致性就是数据保持一致，在分布式系统中，可以理解为多个节点中数据的值是一致的。
1. 强一致性:其实通俗来说就是系统写入的是什么,用户读取到的就是什么,但这种实现起来对性能影响较大
2. 弱一致性:数据在一定时间级别之后(可能是秒级别)会达成一致性
3. 最终一致性:是弱一致性的一个特例,只要求数据在一定时间内达到一致,通常使用在对性能要求较高的业务场景,且一般是通过定时(延时)任务定时写入或者说异步写入

接下来就是三种经典的缓存模式

• Cache-Aside Pattern(旁路缓存模式)

  旁路缓存模式是尽可能解决数据一致性的问题,是一般的业务场景最常用的策略
  • Cache-Aside 读过程
    • 读的时候先去读取缓存内的数据,读取成功则直接返回
    • 若未读取成功,则读取数据源中的数据,并更新缓存
  • Cache-Aside 写过程
    • 写入时先写入数据源
    • 然后删除旧的缓存数据

• Read-Through/Write-Through(读写穿透)

  读写穿透主要通过缓存抽象层与缓存交互,且将缓存作为主要存储
  • Read-Through 读过程
    • 与旁路缓存模式读操作基本相同,只不过是由缓存抽象层完成与缓存和数据库的交互
  • Write-Through 写过程
    • 写入时先向缓存写入数据,然后在更新数据源的数据

• Write-Behind(批量异步写入)

  • Write-Behind一般不直接写入数据源,而是通过批量异步的方式更新数据源中的数据,通常适用于频繁写的业务场景,这种模式一般只能保证最终一致性

且写操作缓存时都是采用删除而不是更新缓存,理由如下:

• 如果你写入的缓存值，是经过复杂计算才得到的话。更新缓存频率高的话，就浪费性能啦。
• 在写数据库场景多，读数据场景少的情况下，数据很多时候还没被读取到，又被更新了，这也浪费了性能呢(实际上，写多的场景，用缓存也不是很划算了)

原文章链接 : 美团二面：Redis与MySQL双写一致性如何保证？