上一篇 “分發(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)載請注明出處)