概述

基于三级缓存架构的分布式系统中，如果缓存服务在本地的 Ehcache 中都读取不到数据，此时需要重新到源头的服务中去拉去数据，拉取到数据之后，赶紧先给 Nginx 的请求返回，同时将数据写入 Ehcache 和 Redis中。此时会出现分布式重建缓存的并发冲突问题，导致三级缓存失效。

分布式缓存重建并发冲突问题

缓存重建冲突

分布式缓存重建并发冲突问题的具体原因是由于多个缓存服务实例提供服务，如果发现缓存失效，那么就会去重建，这个时候回出现以下几种情况：

1. 多个缓存实例都去数据库获取一份数据，然后放入缓存中；
2. 新数据被旧数据覆盖：

• 缓存 a 和 b 都拿了一份数据，a 拿到 12:00的数据，b 拿到 12:01 的数据；
• 缓存 b 先写入 redis，缓存 a 后写入。

综上所述，分布式的缓存重建并发冲突问题发生 :服务部署在多台机器上，都需要修改缓存数据，此时就会出现，缓存被覆盖即使用并非最新的原始数据区覆盖缓存中已经是最新数据，此时将会导致缓存数据不是最新数据，从而发生数据不一致的情况。

解决方案

1. 利用 hash 分发

• 相同商品分发到同一个服务中，服务中再用队列去重建
• 但是这就变成了有状态的缓存服务，压力全部集中到同一个服务上

2. 利用 kafka 队列

• 源头信息服务，在发送消息到 kafka topic 的时候，都需要按照 product id 去分区，和上面 hash 方案类似。

3. 基于 zookeeper 分布式锁的解决方案
   分布式锁：多个机器在访问同一个共享资源，需要给这个资源加一把锁，让多个机器串行访问。
   对于分布式锁，有很多种实现方式，比如 redis 也可以实现。
   这里讲解 zk 分布式锁，zk 做分布式协调比较流程，大数据应用里面 hadoop、storm 都是基于 zk 去做分布式协调。

基于 zookeeper 分布式锁的解决方案

1.变更缓存重建以及空缓存请求重建，更新 redis 之前，都需要先获取对应商品 id 的分布式锁。

2. 拿到分布式锁之后，需要根据时间版本去比较一下，如果自己的版本新于 redis 中的版本，那么就更新，否则就不更新。
3. 如果拿不到分布式锁，那么就等待，不断轮询等待，直到自己获取到分布式的锁