上一篇 “分發(fā)層 + 應(yīng)用層” 雙層nginx 架構(gòu) 之 應(yīng)用層實(shí)現(xiàn)， 主要講解了實(shí)現(xiàn)應(yīng)用層數(shù)據(jù)緩存更新茂蚓，為模板提供數(shù)據(jù)來源，本篇講解分布式緩存重建沖突原因及利用zookeeper分布式鎖解決緩存重建沖突問題剃幌。
-
緩存重建什么意思呢煌贴？
比如應(yīng)用跑了一段時(shí)間，緩存（redis cluster）實(shí)例中的部分?jǐn)?shù)據(jù)由于被LRU等算法或者其他手段清理了锥忿，這時(shí)候就需要重新到數(shù)據(jù)源中拉取數(shù)據(jù)，然后重新設(shè)置到緩存中怠肋。 -
分布式緩存重建又是什么意思呢敬鬓？
比如在多個(gè)node節(jié)點(diǎn)上部署了相同的服務(wù)實(shí)例，對外提供服務(wù)笙各，就會出現(xiàn)多個(gè)node分布式的去讀取相同的數(shù)據(jù)钉答，然后寫入緩存（redis cluster）中
從緩存重建或分布式緩存重建從而會發(fā)現(xiàn)一個(gè)新的問題又來了，那就是 —— 分布式 重建緩存的并發(fā)沖突問題
分布式 重建緩存的并發(fā)沖突問題分析
- 請求流量均勻分布（負(fù)載均衡）到所有的緩存服務(wù)實(shí)例中（前提是緩存服務(wù)部署到多個(gè)node 上）杈抢，就會導(dǎo)致相同的商品id會打到不同的緩存服務(wù)實(shí)例数尿，這樣就導(dǎo)致了分布式緩存重建問題發(fā)生。（前面 28惶楼、27 章節(jié)講解了使用nginx 分發(fā)層和應(yīng)用層對外提供服務(wù)右蹦，根據(jù) 商品id 轉(zhuǎn)發(fā)到應(yīng)用層，應(yīng)用層獲取緩存服務(wù)實(shí)例數(shù)據(jù)歼捐，更新本地緩存并渲染）何陆，如下圖所示：
解決思路：部署多個(gè)cache service 實(shí)例，定義緩存實(shí)例請求地址列表豹储，在nginx 應(yīng)用層 計(jì)算 hash( 商品id )贷盲，然后對緩存實(shí)例地址列表數(shù)量取模，取出相應(yīng)的緩存實(shí)例地址剥扣，請求到指定的 緩存實(shí)例node
- mysql 源數(shù)據(jù)變更時(shí)巩剖，向緩存服務(wù)實(shí)例發(fā)送變更消息時(shí)铝穷，由于緩存服務(wù)是監(jiān)聽kafka topic的，所有一個(gè)kafka consumer 就會消費(fèi)topic 中一個(gè)partition佳魔，那么多個(gè)緩存服務(wù)就會消費(fèi)多個(gè)kafka partition曙聂，這樣說來就會發(fā)送緩存重建問題了，如下圖所示：
解決思路：在源數(shù)據(jù)服務(wù)的 kafka producer 中 吃引，發(fā)送message 加上 商品id即可筹陵，kafka 就會按照商品id 的方式進(jìn)行分區(qū)
- 上面講源數(shù)據(jù)服務(wù)變更引入分區(qū)，只能解決單向緩存服務(wù)消費(fèi)（不包含其他請求也請求到緩存服務(wù)情況）镊尺，如果源數(shù)據(jù)服務(wù)變更打到cache service node 1 朦佩，其他請求（nginx等等）請求打到cache service node2 ，那么問題就來了庐氮，因?yàn)閚ginx 分發(fā)層或者應(yīng)用層的分發(fā)hash 分發(fā)策略是自己定義的语稠，安裝crc32 取hash 后取模的，你無法確定kafka 的分區(qū)策略弄砍，這里就無法統(tǒng)一了仙畦，這時(shí)候在高并發(fā)或者一些不確定因素的情況下就會出現(xiàn)兩邊都更新緩存了，就會出現(xiàn)沖突了音婶。如下圖所示：
上圖有兩條更新線：
a： nginx > cache service node1 > 源數(shù)據(jù)服務(wù) > redis cluster
b： 源數(shù)據(jù)服務(wù) > kafka > cache service node3 > 源數(shù)據(jù)服務(wù) > redis cluster
很明顯就可以發(fā)現(xiàn)問題了慨畸，最終redis cluster 中的最新數(shù)據(jù)并不是最新的。
基于以上分析衣式，該怎么解決呢寸士，前面兩個(gè)點(diǎn)按照解決思路做好后，我們就可以單獨(dú)解決第三點(diǎn)問題碴卧，這里可以使用分布式的共享鎖弱卡，將不同node 實(shí)例的訪問共享資源串行起來，分布式鎖有很多住册，比如redis 分布式鎖婶博、zookeeper 分布式鎖，筆者以zokeeper 分布式鎖為例
基于zookeeper分布式鎖的解決方案
基于問題三中分析圖中加入zookeeper荧飞，誰先得到zookeeper 鎖凡人，誰先更新redis cluster ，同時(shí)緩存數(shù)據(jù)加入當(dāng)時(shí)的時(shí)間（版本控制叹阔、比較）划栓，沒有得到鎖的等待。
zookeeper分布式鎖的解決邏輯思路
- 變更緩存重建或者空緩存請求重建条获，更新redis之前忠荞，先獲取對應(yīng)商品id的分布式鎖
- 拿到分布式鎖后，做時(shí)間版本比較，如果自己的版本新于redis中的版本委煤，那么就更新堂油，否則就不更新
- 如果拿不到分布式鎖，那么就等待碧绞，不斷輪詢等待府框，直到自己獲取到分布式的鎖
以上就是本章內(nèi)容，如有不對的地方讥邻，請多多指教迫靖，謝謝！
為了方便有需要的人兴使，本系列全部軟件都在 https://pan.baidu.com/s/1qYsJZfY
下章預(yù)告：主要講解 “ 帶你利用zookeeper 分布式鎖解決緩存重建沖突”
作者：逐暗者 （轉(zhuǎn)載請注明出處）
