Redis与MySQL双写一致性如何保证
1. 一致性介绍
一致性就是数据保持一致，在分布式系统中，可以理解为多个节点中数据的值是一致的。
- 强一致性：这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大
- 弱一致性：这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态
- 最终一致性：最终一致性是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来，是因为它是弱一致性中非常推崇的一种一致性模型，也是业界在大型分布式系统的数据一致性上比较推崇的模型。
2. 集中式redis缓存的三个经典的缓存模式
3. CAP理论
CAP理论，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
CAP理论作为分布式系统的基础理论,它描述的是一个分布式系统在以下三个特性中：
- 一致性（Consistency）
- 可用性（Availability）
- 分区容错性（Partition tolerance）
最多满足其中的两个特性。也就是下图所描述的。分布式系统要么满足CA,要么CP，要么AP。无法同时满足CAP。
什么是 一致性、可用性和分区容错性
- 分区容错性：指的分布式系统中的某个节点或者网络分区出现了故障的时候，整个系统仍然能对外提供满足一致性和可用性的服务。也就是说部分故障不影响整体使用。
事实上我们在设计分布式系统是都会考虑到bug,硬件，网络等各种原因造成的故障，所以即使部分节点或者网络出现故障，我们要求整个系统还是要继续使用的
(不继续使用,相当于只有一个分区,那么也就没有后续的一致性和可用性了)
- 可用性：一直可以正常的做读写操作。简单而言就是客户端一直可以正常访问并得到系统的正常响应。用户角度来看就是不会出现系统操作失败或者访问超时等问题。
- 一致性：在分布式系统完成某写操作后任何读操作，都应该获取到该写操作写入的那个最新的值。相当于要求分布式系统中的各节点时时刻刻保持数据的一致性。
所以，如果需要数据库和缓存数据保持强一致，就不适合使用缓存。所以使用缓存提升性能，就是会有数据更新的延迟。这需要我们在设计时结合业务仔细思考是否适合用缓存。然后缓存一定要设置过期时间，这个时间太短、或者太长都不好：
- 太短的话请求可能会比较多的落到数据库上，这也意味着失去了缓存的优势。
- 太长的话缓存中的脏数据会使系统长时间处于一个延迟的状态，而且系统中长时间没有人访问的数据一直存在内存中不过期，浪费内存。
但是，通过一些方案优化处理，是可以保证弱一致性，最终一致性的。
4. 3种方案保证数据库与缓存的一致性
4.1 缓存延时双删
延时双删的步骤：
- 先删除缓存
- 再更新数据库
- 休眠一会（比如1秒），再次删除缓存。
假如A，B两个线程A操作写，B操作读，当A删除缓存之后，这个时候B发生cache miss，就会查询数据库然后更新到缓存，这个时候A更新数据库结束之后再次删除缓存即可，防止刚才B读请求带来的缓存脏数据。
这个休眠一会，一般多久呢？都是1秒？这个休眠时间 = B读取业务逻辑数据的耗时 + 几百毫秒。
4.2 删除缓存重试机制
不管是延时双删还是Cache-Aside的先操作数据库再删除缓存，如果第二步的删除缓存失败呢?
因为删除失败会导致脏数据哦~
删除失败就多删除几次呀,保证删除缓存成功呀~ 所以可以引入删除缓存重试机制
删除缓存重试机制的大致步骤：
- 写请求更新数据库
- 缓存因为某些原因，删除失败
- 把删除失败的key放到消息队列
- 消费消息队列的消息，获取要删除的key
- 重试删除缓存操作
4.3 同步biglog异步删除缓存
重试删除缓存机制还可以，就是会造成好多业务代码入侵。
其实，还可以通过数据库的binlog来异步淘汰key。
以mysql为例 可以使用阿里的canal将binlog日志采集发送到MQ队列里面，然后编写一个简单的缓存删除消息者订阅binlog日志，根据更新log删除缓存，并且通过ACK机制确认处理这条更新log，保证数据缓存一致性。
有个问题就是：MySQL主从这种情况，如果发生同步延迟，那么如何保证一致性呢？
解决方案如下：
就是A先删除缓存(不管成功还是失败不影响，因为失败了最终通过binlog会删除的)，在更新DB，因为主从可能存在延迟，所以B在cache miss之后从从库读取旧数据写入缓存(脏数据)或者还有一种情况就是A删除缓存失败并且同步有延迟，那么B读取旧缓存，但是不影响，因为最后主从同步成功之后通过canal将binlog数据写入MQ，消费者可以根据更新的log数据删除缓存，并且通过ACK机制确认处理这条更新log，保证数据缓存一致性。比如更新了uid=2这个用户信息，那么可以读取binlog中uid=2的log，然后删除缓存中key={user:2}这个key。
