?

Java生鮮電商平臺-緩存架構(gòu)實(shí)戰(zhàn)

?

說明：在Java生鮮電商中，緩存起到了非常重要的作用，目前整個(gè)項(xiàng)目中才用的是redis做分布式緩存.

緩存集群

緩存集群存在的問題

1.熱key
緩存集群中的某個(gè)key瞬間被數(shù)萬甚至十萬的并發(fā)請求打爆。

2.大value
某個(gè)key對應(yīng)的value可能有GB級的大小，導(dǎo)致查詢value的時(shí)候?qū)е戮W(wǎng)絡(luò)相關(guān)的故障問題。

緩存集群作用

在緩存里放一些平時(shí)不怎么變動的數(shù)據(jù)，然后用戶在查詢大量的平時(shí)不怎么變動的數(shù)據(jù)的時(shí)候，可以直接從緩存里走了。緩存集群的并發(fā)能力是很強(qiáng)的，而且讀緩存的性能是很高的。

緩存實(shí)踐案例

• 假設(shè)系統(tǒng)每秒有2萬請求，但是其中90%都是讀請求，假如每秒1.8萬請求都是在讀一些不太變化的數(shù)據(jù)。那此時(shí)你把這些數(shù)據(jù)都放在數(shù)據(jù)庫里，然后每秒發(fā)送2萬請求到數(shù)據(jù)庫上讀寫數(shù)據(jù)，感受一下這樣合適？
• 如果要用數(shù)據(jù)庫承載每秒2萬請求的話，那很可能就得搞分庫分表 + 讀寫分離。
• 那得分3個(gè)主庫，承載每秒2000的寫入請求，然后每個(gè)主庫掛3個(gè)從庫，一共9個(gè)從庫承載每秒1.8萬的讀請求。
• 這樣的話，就需要一共是12臺高配置的數(shù)據(jù)庫服務(wù)器，這是很耗費(fèi)錢的，成本非常高，很不合適。
• 因此，可以把平時(shí)不太變化的數(shù)據(jù)放在緩存集群里，緩存集群可以采用2主2從，主節(jié)點(diǎn)用來寫入緩存，從節(jié)點(diǎn)用來讀緩存。
• 以緩存集群的性能，2個(gè)從節(jié)點(diǎn)完全可以用來承載每秒1.8萬的大量讀請求，然后3個(gè)數(shù)據(jù)庫主庫就是承載每秒2000的寫請求和少量其他讀請求就OK了（數(shù)據(jù)一致性問題）。
• 這樣一來，耗費(fèi)的機(jī)器瞬間變成了4臺緩存機(jī)器 + 3臺數(shù)據(jù)庫機(jī)器 = 7臺機(jī)器，是不是比之前的12臺機(jī)器減少了很大的資源開銷？
• 緩存其實(shí)在系統(tǒng)架構(gòu)里是非常重要的組成部分。很多時(shí)候，對于那些很少變化但是大量高并發(fā)讀的數(shù)據(jù)，通過緩存集群來抗高并發(fā)讀，是非常合適的。

熱點(diǎn)緩存

• 所謂熱點(diǎn)緩存問題就是突然因?yàn)槟脑?#xff0c;出現(xiàn)大量的用戶訪問同一條緩存數(shù)據(jù)。碰巧這些key都存在于一臺緩存機(jī)器上。
• 假設(shè)每秒突然奔過來20萬請求到這臺機(jī)器上，那臺被20萬請求指向的緩存機(jī)器就會過度操勞而宕機(jī)的。
• 讀請求發(fā)現(xiàn)讀不到數(shù)據(jù)，會從數(shù)據(jù)庫里提取原始數(shù)據(jù)，然后放入剩余的其他緩存機(jī)器里去。但是接踵而來的每秒20萬請求，會再次壓垮其他的緩存機(jī)器。
• 以此類推，最終導(dǎo)致緩存集群全盤崩潰，引發(fā)系統(tǒng)整體宕機(jī)。

基于流式計(jì)算技術(shù)的緩存熱點(diǎn)自動發(fā)現(xiàn)

• 其實(shí)這里關(guān)鍵的一點(diǎn)，就是對于這種熱點(diǎn)緩存，你的系統(tǒng)需要能夠在熱點(diǎn)緩存突然發(fā)生的時(shí)候，直接發(fā)現(xiàn)他，然后瞬間立馬實(shí)現(xiàn)毫秒級的自動負(fù)載均衡。
• 一般出現(xiàn)緩存熱點(diǎn)的時(shí)候，每秒并發(fā)肯定是很高的，可能每秒都幾十萬甚至上百萬的請求量過來，這都是有可能的。
• 所以，此時(shí)完全可以基于大數(shù)據(jù)領(lǐng)域的流式計(jì)算技術(shù)來進(jìn)行實(shí)時(shí)數(shù)據(jù)訪問次數(shù)的統(tǒng)計(jì)，比如storm、spark streaming、flink。
• 一旦在實(shí)時(shí)數(shù)據(jù)訪問次數(shù)統(tǒng)計(jì)的過程中，比如發(fā)現(xiàn)一秒之內(nèi)，某條數(shù)據(jù)突然訪問次數(shù)超過了1000，就直接立馬把這條數(shù)據(jù)判定為是熱點(diǎn)數(shù)據(jù)，可以將這個(gè)發(fā)現(xiàn)出來的熱點(diǎn)數(shù)據(jù)寫入比如zookeeper中（監(jiān)聽事件）。
• 流式計(jì)算系統(tǒng)在進(jìn)行數(shù)據(jù)訪問次數(shù)統(tǒng)計(jì)的時(shí)候，會不會也存在說單臺機(jī)器被請求每秒幾十萬次的問題呢？否！！！
• 流式計(jì)算技術(shù)，尤其是storm這種系統(tǒng)，他可以做到同一條數(shù)據(jù)的請求過來，先分散在很多機(jī)器里進(jìn)行本地計(jì)算，最后再匯總局部計(jì)算結(jié)果到一臺機(jī)器進(jìn)行全局匯總。
• 所以幾十萬請求可以先分散在比如100臺機(jī)器上，每臺機(jī)器統(tǒng)計(jì)了這條數(shù)據(jù)的幾千次請求。
• 然后100條局部計(jì)算好的結(jié)果匯總到一臺機(jī)器做全局計(jì)算即可，所以基于流式計(jì)算技術(shù)來進(jìn)行統(tǒng)計(jì)是不會有熱點(diǎn)問題的。

熱點(diǎn)緩存自動加載為JVM本地緩存

• 我們自己的系統(tǒng)可以對zookeeper指定的熱點(diǎn)緩存對應(yīng)的znode進(jìn)行監(jiān)聽，如果有變化立馬就可以感知到了。
• 此時(shí)系統(tǒng)層就可以立馬把相關(guān)的緩存數(shù)據(jù)從數(shù)據(jù)庫加載出來，然后直接放在自己系統(tǒng)內(nèi)部的本地緩存里即可。
• 這個(gè)本地緩存，用ehcache、hashmap，其實(shí)都可以，一切看自己的業(yè)務(wù)需求。我們這里主要說的就是將緩存集群里的集中式緩存，直接變成每個(gè)系統(tǒng)自己本地實(shí)現(xiàn)緩存即可，每個(gè)系統(tǒng)本地是無法緩存過多數(shù)據(jù)的。
• 因?yàn)橐话氵@種普通系統(tǒng)單實(shí)例部署機(jī)器可能就一個(gè)4核8G的機(jī)器，留給本地緩存的空間是很少的，所以用來放這種熱點(diǎn)數(shù)據(jù)的本地緩存是最合適的，剛剛好。
• 假設(shè)系統(tǒng)層集群部署了100臺機(jī)器，此時(shí)你100臺機(jī)器瞬間在本地都會有一份熱點(diǎn)緩存的副本。
• 然后接下來對熱點(diǎn)緩存的讀操作，直接系統(tǒng)本地緩存讀出來就給返回了，不用再走緩存集群了。
• 這樣的話，變成100臺機(jī)器每臺機(jī)器承載數(shù)千請求，那么那數(shù)千請求就直接從機(jī)器本地緩存返回?cái)?shù)據(jù)了，這是沒有問題的。

限流熔斷保護(hù)

• 在每個(gè)系統(tǒng)內(nèi)部，還應(yīng)該專門加一個(gè)對熱點(diǎn)數(shù)據(jù)訪問的限流熔斷保護(hù)措施。
• 每個(gè)系統(tǒng)實(shí)例內(nèi)部，都可以加一個(gè)熔斷保護(hù)機(jī)制，假設(shè)緩存集群最多每秒承載4萬讀請求，那么你一共有100個(gè)系統(tǒng)實(shí)例。
• 應(yīng)該提前限制好，每個(gè)系統(tǒng)實(shí)例每秒最多請求緩存集群讀操作不超過400次，一超過就可以熔斷掉，不讓請求緩存集群，直接返回一個(gè)空白信息，然后用戶稍后會自行再次重新刷新頁面之類的。

• 通過系統(tǒng)層自己直接加限流熔斷保護(hù)措施，可以很好的保護(hù)后面的緩存集群、數(shù)據(jù)庫集群之類的不要被打死。

  
  

轉(zhuǎn)載于:https://www.cnblogs.com/jurendage/p/11269241.html

總結(jié)

以上是生活随笔為你收集整理的Java生鲜电商平台-缓存架构实战的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。