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

什么是分布式缓存重建并发冲突问题？

很简单，多个缓存服务实例提供服务，发现缓存失效，那么就会去重建，这个时候回出现以下几种情况：

1. 多个缓存实例都去数据库获取一份数据，然后放入缓存中

2. 新数据被旧数据覆盖

   缓存 a 和 b 都拿了一份数据，a 拿到 12:00:01 的数据，b 拿到 12:00:05 的数据

   缓存 b 先写入 redis，缓存 a 后写入。

以上问题有多重解决方案，如：

1. 利用 hash 分发

   相同商品分发到同一个服务中，服务中再用队列去重建

   但是这就变成了有状态的缓存服务，压力全部集中到同一个服务上

2. 利用 kafka 队列

   源头信息服务，在发送消息到 kafka topic 的时候，都需要按照 product id 去分区

   和上面 hash 方案类似

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

分布式锁：多个机器在访问同一个共享资源，需要给这个资源加一把锁，让多个机器串行访问

对于分布式锁，有很多种实现方式，比如 redis 也可以实现。

这里讲解 zk 分布式锁，zk 做分布式协调比较流程，大数据应用里面 hadoop、storm 都是基于 zk 去做分布式协调

zk 分布式锁的解决并发冲突的方案

1. 变更缓存重建以及空缓存请求重建，更新 redis 之前，都需要先获取对应商品 id 的分布式锁
2. 拿到分布式锁之后，需要根据时间版本去比较一下，如果自己的版本新于 redis 中的版本，那么就更新，否则就不更新
3. 如果拿不到分布式锁，那么就等待，不断轮询等待，直到自己获取到分布式的锁