概括：缓存是通过牺牲强一致性来提高性能的。
这个是由CAP理论决定的。缓存系统适用的场景就是非强一致性的场景，它属于CAP中的AP。
强一致性还是弱一致性？
CAP理论，指的是在一个分布式系统中，只能满足其中两项，三者不可兼得。
CAP理论作为分布式系统的基础理论,它描述的是一个分布式系统在以下三个特性中：
- 一致性（Consistency）
- 可用性（Availability）
- 分区容错性（Partition tolerance）
最多满足其中的两个特性。也就是下图所描述的。分布式系统要么满足CA,要么CP，要么AP。无法同时满足CAP。
那么什么是一致性、分区容错性、可用性？
分区容错性：指的分布式系统中的某个节点或者网络分区出现了故障的时候，整个系统仍然能对外提供满足一致性和可用性的服务。也就是说部分故障不影响整体使用。
事实上我们在设计分布式系统是都会考虑到bug,硬件，网络等各种原因造成的故障，所以即使部分节点或者网络出现故障，我们要求整个系统还是要继续使用的
(不继续使用,相当于只有一个分区,那么也就没有后续的一致性和可用性了)
可用性： 一直可以正常的做读写操作。简单而言就是客户端一直可以正常访问并得到系统的正常响应。用户角度来看就是不会出现系统操作失败或者访问超时等问题。
一致性：在分布式系统完成某写操作后任何读操作，都应该获取到该写操作写入的那个最新的值。相当于要求分布式系统中的各节点时时刻刻保持数据的一致性。
所以，如果需要数据库和缓存数据保持强一致，就不适合适用缓存。
所以使用缓存提升性能，就是会有数据更新的延迟。这需要我们在设计时结合业务仔细思考是否适合用缓存。然后缓存一定要设置过期时间，这个时间太短、或者太长都不好：
- 太短的话请求可能会比较多的落到数据库上，这也意味着失去了缓存的优势。
- 太长的话缓存中的脏数据会使系统长时间处于一个延迟的状态，而且系统中长时间没有人访问的数据一直存在内存中不过期，浪费内存。
但是，通过一些方案优化处理，是可以保证弱一致性，最终一致性的。
保证数据库与缓存的一致性的三种方案
缓存延迟双删
有些小伙伴可能会说，不一定要先操作数据库呀，采用缓存延时双删策略就好啦？
那么什么是延时双删呢？
步骤一：
先删除缓存
步骤二：
再更新数据库
步骤 三：
休眠一会儿（比如1秒），再次删除缓存。
为了确保读请求结束，写请求可以删除读请求可能带来的缓存脏数据。
删除缓存重试机制
不管是延时双删还是Cache-Aside的先操作数据库再删除缓存，如果第二步的删除缓存失败呢？
删除失败，就会导致脏数据。
删除失败就多删几次，保证删除缓存成功。这里使用删除重试机制
删除缓存重试机制的大致步骤：
- 写请求更新数据库
- 缓存因为某些原因，删除失败
- 把删除失败的key放到消息队列
- 消费消息队列的消息，获取要删除的key
- 重试删除缓存操作
同步biglog异步删除缓存
重试删除缓存机制可以解决删除失败的问题，但是会造成业务代码入侵。
其实，还可以通过数据库的binlog来异步淘汰key。
以MySQL为例，可以使用阿里的Canal将binlog日志采集发送到MQ队列里面，然后编写一个简单的缓存删除消息订阅binlog日志，根据更新log删除缓存，并且通过ACK机制确认处理这条更新log，保证数据缓存一致性。
同步binlog策略是如何确保消费成功的？
PushConsumer为了保证消息肯定消费成功，只有使用方明确表示消费成功，RocketMQ才会认为消息消费成功。中途断电，抛出异常等都不会认为成功----即都会重新投递。
首先，消费的时候，需要注入一个消息回调，具体样例如下：
consumer.registerMessageListener(new MessageListenerConcurrently() {
@Override
public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) {
System.out.println(Thread.currentThread().getName() + " message " + mgs );
delcache(key);// 执行真正删除
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS
}
});
业务实现消费回调的时候，当且仅当回调函数返回SUCCESS，RocketMQ才会认为这批消息（默认是1条）是消费完成的。
如果这时候消息消费失败，例如数据库异常，余额不足扣款失败等一切业务认为消息需要重试的场景，只要返回ConsumeConcurrentlyStatus.RECONSUME_LATER，RocketMQ就会认为这批消息消费失败了。
为了保证消息是肯定被至少消费成功一次，RocketMQ会把这批消费失败的消息重发回Broker（topic不是原topic而是这个消费的RETRY topic），在延迟的某个时间点（默认是10秒，业务可设置）后，再次投递到这个ConsumerGroup。而如果一直这样重复消费都持续失败到一定次数（默认16次），就会投递到DLQ死信队列。应用可以监控死信队列来做人工干预。
Redis的发布订阅
Redis通过publish和subscribe命令实现订阅和发布的功能。订阅者可以通过subscribe向redis server订阅自己感兴趣的消息类型。redis将信息类型称为通道（channel）。当发布者通过publish命令向redis server发送特定类型的信息时，订阅该消息类型的全部订阅者都会收到此消息。
主从数据库通过binlog异步删除
因为主从DB同步存在延时时间。如果删除缓存之后，数据同步到备库之前已经有请求过来时， 「会从备库中读到脏数据」，如何解决呢？解决方案如下流程图：
缓存与数据的一致性的保障策略总结
综上所述，在分布式系统中，缓存和数据库同时存在时，如果有写操作的时候，「先操作数据库，再操作缓存」。如下：
1.读取缓存中是否有相关数据
2.如果缓存中有相关数据value，则返回
3.如果缓存中没有相关数据，则从数据库读取相关数据放入缓存中key->value，再返回
4.如果有更新数据，则先更新数据库，再删除缓存
5.为了保证第四步删除缓存成功，使用binlog异步删除
6.如果是主从数据库，binglog取自于从库
7.如果是一主多从，每个从库都要采集binlog，然后消费端收到最后一台binlog数据才删除缓存，或者为了简单，收到一次更新log，删除一次缓存