Github

0 導(dǎo)讀

我們這個教程，基于hystrix，如何來構(gòu)建高可用的分布式系統(tǒng)的架構(gòu)，項(xiàng)目實(shí)戰(zhàn)

模擬真實(shí)業(yè)務(wù)的這么一個小型的項(xiàng)目，來全程貫穿，用這個項(xiàng)目中的業(yè)務(wù)場景去一個一個的講解hystrix高可用的每個技術(shù)

純講hystrix，脫離實(shí)際的業(yè)務(wù)背景，聽起來有點(diǎn)枯燥，大家學(xué)完了hystrix以后，可能沒法完全感受到技術(shù)是如何融入我們的項(xiàng)目中的

大背景：電商網(wǎng)站，首頁，商品詳情頁，搜索結(jié)果頁，廣告頁，促銷活動，購物車，訂單系統(tǒng)，庫存系統(tǒng)，物流系統(tǒng)

小背景：商品詳情頁，如何用最快的結(jié)果將商品數(shù)據(jù)填充到一個頁面中，然后將頁面顯示出來

分布式系統(tǒng)：商品詳情頁，緩存服務(wù)，+底層源數(shù)據(jù)服務(wù)，商品信息服務(wù)，店鋪信息服務(wù)，廣告信息服務(wù)，推薦信息服務(wù)，綜合起來組成一個分布式的系統(tǒng)

1 電商網(wǎng)站的商品詳情頁系統(tǒng)架構(gòu)

1.1 小型電商網(wǎng)站的商品詳情頁系統(tǒng)架構(gòu)(非重點(diǎn))

1.2 大型電商網(wǎng)站的商品詳情頁系統(tǒng)架構(gòu)

大型電商網(wǎng)站商品詳情頁的系統(tǒng)設(shè)計(jì)中，當(dāng)商品數(shù)據(jù)發(fā)生變更時，會將變更消息壓入消息隊(duì)列中。

緩存服務(wù)從消息隊(duì)列中消費(fèi)這條消息時，感知到有數(shù)據(jù)發(fā)生變更，便通過調(diào)用數(shù)據(jù)服務(wù)接口，獲取變更后的數(shù)據(jù)，然后將整合好的數(shù)據(jù)推送至 redis 中。

Nginx 本地緩存的數(shù)據(jù)是有一定的時間期限的，比如說 10 分鐘，當(dāng)數(shù)據(jù)過期之后，它就會從 redis 獲取到最新的緩存數(shù)據(jù)，并且緩存到自己本地。

用戶瀏覽網(wǎng)頁時，動態(tài)將 Nginx 本地?cái)?shù)據(jù)渲染到本地 html 模板并返回給用戶。

雖然沒有直接返回 html 頁面那么快，但是因?yàn)閿?shù)據(jù)在本地緩存，所以也很快，其實(shí)耗費(fèi)的也就是動態(tài)渲染一個 html 頁面的性能。如果 html 模板發(fā)生了變更，不需要將所有的頁面重新靜態(tài)化，也不需要發(fā)送請求，沒有網(wǎng)絡(luò)請求的開銷，直接將數(shù)據(jù)渲染進(jìn)最新的 html 頁面模板后響應(yīng)即可。

在這種架構(gòu)下，我們需要保證系統(tǒng)的高可用性。

如果系統(tǒng)訪問量很高，Nginx 本地緩存過期失效了，redis 中的緩存也被 LRU 算法給清理掉了，那么會有較高的訪問量，從緩存服務(wù)調(diào)用商品服務(wù)。但如果此時商品服務(wù)的接口發(fā)生故障，調(diào)用出現(xiàn)了延時，緩存服務(wù)全部的線程都被這個調(diào)用商品服務(wù)接口給耗盡了，每個線程去調(diào)用商品服務(wù)接口的時候，都會卡住很長時間，后面大量的請求過來都會卡在那兒，此時緩存服務(wù)沒有足夠的線程去調(diào)用其它一些服務(wù)的接口，從而導(dǎo)致整個大量的商品詳情頁無法正常顯示。

這其實(shí)就是一個商品接口服務(wù)故障導(dǎo)致緩存服務(wù)資源耗盡的現(xiàn)象。

1.3 頁面模板

舉個例子

將數(shù)據(jù)動態(tài)填充/渲染到一個html模板中，是什么意思呢？

上面這個就可以認(rèn)為是一個頁面模板，里面的很多內(nèi)容是不確定的，#{name}，#{price}，#{description}，這都是一些模板腳本，不確定里面的值是什么？

將數(shù)據(jù)填充/渲染到html模板中，是什么意思呢？

上面這個就是一份填充好數(shù)據(jù)的一個html頁面

2 緩存服務(wù)

緩存服務(wù)，訂閱一個MQ的消息變更，如果有消息變更的話，那么就會發(fā)送一個網(wǎng)絡(luò)請求，調(diào)用一個底層的對應(yīng)的源數(shù)據(jù)服務(wù)的接口，去獲取變更后的數(shù)據(jù)

將獲取到的變更后的數(shù)據(jù)填充到分布式的redis緩存中去

高可用這一塊兒，最可能出現(xiàn)說可用性不高的情況，是什么呢？

就是說，在接收到消息之后，可能在調(diào)用各種底層依賴服務(wù)的接口時，會遇到各種不穩(wěn)定的情況

比如底層服務(wù)的接口調(diào)用超時，200ms，2s都沒有返回; 底層服務(wù)的接口調(diào)用失敗，比如說卡了500ms之后，返回一個報錯

在分布式系統(tǒng)中，對于這種大量的底層依賴服務(wù)的調(diào)用，就可能會出現(xiàn)各種可用性的問題，一旦沒有處理好的話

可能就會導(dǎo)致緩存服務(wù)自己本身會掛掉，或者故障掉，就會導(dǎo)致什么呢？

不可以對外提供服務(wù)，嚴(yán)重情況下，甚至?xí)?dǎo)致說整個商品詳情頁顯示不出來

緩存服務(wù)接收到變更消息后，去調(diào)用各個底層依賴服務(wù)時的高可用架構(gòu)的實(shí)現(xiàn)

我們剛才講解的整套大型電商網(wǎng)站的商品詳情頁的緩存架構(gòu)，完整的那個流程，《億級流量電商詳情頁系統(tǒng)的大型高并發(fā)與高可用緩存架構(gòu)實(shí)戰(zhàn)》

3 框架結(jié)構(gòu)

圍繞著緩存服務(wù)去拉取各種底層的源數(shù)據(jù)服務(wù)的數(shù)據(jù)，調(diào)用其接口時，可能出現(xiàn)的系統(tǒng)不可用的問題

從簡

spring boot，微服務(wù)的非常快速，非常好用的技術(shù)框架，脫胎于spring，具體的東西就不講解，直接帶著大家上手搭建一個spring boot的框架

2個服務(wù)，緩存服務(wù)，商品服務(wù)，緩存服務(wù)依賴于商品服務(wù)

模擬各種商品服務(wù)可能接口調(diào)用時出現(xiàn)的各種問題，導(dǎo)致系統(tǒng)不可用的場景，然后用hystrix完整的各種技術(shù)點(diǎn)全部貫穿在里面

解決了一大堆設(shè)計(jì)業(yè)務(wù)背景下的系統(tǒng)不可用問題，hystrix整個技術(shù)體系，知識體系，也就講解完了

消息隊(duì)列，redis，咱們都不搞了

spring boot + http client + hystrix

參考

• 《Java工程師面試突擊第1季-中華石杉老師》

總結(jié)

以上是生活随笔為你收集整理的html访问java接口出现缓存_高可用架构设计(3) -电商商品详情页缓存背景及框架说明...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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