上一篇 “分发层 + 应用层” 双层nginx 架构 之 应用层实现， 主要讲解了实现应用层数据缓存更新，为模板提供数据来源，本篇讲解分布式缓存重建冲突原因及利用zookeeper分布式锁解决缓存重建冲突问题。
-
缓存重建什么意思呢？
比如应用跑了一段时间，缓存（redis cluster）实例中的部分数据由于被LRU等算法或者其他手段清理了，这时候就需要重新到数据源中拉取数据，然后重新设置到缓存中。 -
分布式缓存重建又是什么意思呢？
比如在多个node节点上部署了相同的服务实例，对外提供服务，就会出现多个node分布式的去读取相同的数据，然后写入缓存（redis cluster）中
从缓存重建或分布式缓存重建从而会发现一个新的问题又来了，那就是 —— 分布式 重建缓存的并发冲突问题
分布式 重建缓存的并发冲突问题分析
- 请求流量均匀分布（负载均衡）到所有的缓存服务实例中（前提是缓存服务部署到多个node 上），就会导致相同的商品id会打到不同的缓存服务实例，这样就导致了分布式缓存重建问题发生。（前面 28、27 章节讲解了使用nginx 分发层和应用层对外提供服务，根据 商品id 转发到应用层，应用层获取缓存服务实例数据，更新本地缓存并渲染），如下图所示：
解决思路：部署多个cache service 实例，定义缓存实例请求地址列表，在nginx 应用层 计算 hash( 商品id )，然后对缓存实例地址列表数量取模，取出相应的缓存实例地址，请求到指定的 缓存实例node
- mysql 源数据变更时，向缓存服务实例发送变更消息时，由于缓存服务是监听kafka topic的，所有一个kafka consumer 就会消费topic 中一个partition，那么多个缓存服务就会消费多个kafka partition，这样说来就会发送缓存重建问题了，如下图所示：
解决思路：在源数据服务的 kafka producer 中 ，发送message 加上 商品id即可，kafka 就会按照商品id 的方式进行分区
- 上面讲源数据服务变更引入分区，只能解决单向缓存服务消费（不包含其他请求也请求到缓存服务情况），如果源数据服务变更打到cache service node 1 ，其他请求（nginx等等）请求打到cache service node2 ，那么问题就来了，因为nginx 分发层或者应用层的分发hash 分发策略是自己定义的，安装crc32 取hash 后取模的，你无法确定kafka 的分区策略，这里就无法统一了，这时候在高并发或者一些不确定因素的情况下就会出现两边都更新缓存了，就会出现冲突了。如下图所示：
上图有两条更新线：
a： nginx > cache service node1 > 源数据服务 > redis cluster
b： 源数据服务 > kafka > cache service node3 > 源数据服务 > redis cluster
很明显就可以发现问题了，最终redis cluster 中的最新数据并不是最新的。
基于以上分析，该怎么解决呢，前面两个点按照解决思路做好后，我们就可以单独解决第三点问题，这里可以使用分布式的共享锁，将不同node 实例的访问共享资源串行起来，分布式锁有很多，比如redis 分布式锁、zookeeper 分布式锁，笔者以zokeeper 分布式锁为例
基于zookeeper分布式锁的解决方案
基于问题三中分析图中加入zookeeper，谁先得到zookeeper 锁，谁先更新redis cluster ，同时缓存数据加入当时的时间（版本控制、比较），没有得到锁的等待。
zookeeper分布式锁的解决逻辑思路
- 变更缓存重建或者空缓存请求重建，更新redis之前，先获取对应商品id的分布式锁
- 拿到分布式锁后，做时间版本比较，如果自己的版本新于redis中的版本，那么就更新，否则就不更新
- 如果拿不到分布式锁，那么就等待，不断轮询等待，直到自己获取到分布式的锁
以上就是本章内容，如有不对的地方，请多多指教，谢谢！
为了方便有需要的人，本系列全部软件都在 https://pan.baidu.com/s/1qYsJZfY
下章预告：主要讲解 “ 带你利用zookeeper 分布式锁解决缓存重建冲突”
作者：逐暗者 （转载请注明出处）
