读书笔记:交易型系统设计的一般原则
2019獨(dú)角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>
系統(tǒng)設(shè)計(jì)的一般原則
1.高并發(fā)原則
1.1無狀態(tài)
應(yīng)用應(yīng)該被設(shè)計(jì)成為無狀態(tài)的,這樣應(yīng)用也比較容易進(jìn)行水平擴(kuò)展。實(shí)際生產(chǎn)系統(tǒng)通常被設(shè)計(jì)成為應(yīng)用無狀態(tài),配置有狀態(tài),那么只需要通過配置文件或配置中心指定即可。
1.2拆分
根據(jù)實(shí)際情況進(jìn)行系統(tǒng)拆分,如果系統(tǒng)使用人員較少,并發(fā)不高,完全沒有壓力做一個(gè)大而全的系統(tǒng)也無可厚非。
系統(tǒng)維度:按照系統(tǒng)功能/業(yè)務(wù)拆分,比如商品系統(tǒng)、購物車、結(jié)算、訂單系統(tǒng)等等。
功能維度:比如對一個(gè)業(yè)務(wù)系統(tǒng)優(yōu)惠券進(jìn)行再拆分,后臺(tái)券創(chuàng)建系統(tǒng)、領(lǐng)券系統(tǒng)、用券系統(tǒng)。
讀寫維度:根據(jù)讀寫比例特征進(jìn)行拆分。比如,商品系統(tǒng),交易的各個(gè)系統(tǒng)都會(huì)讀取商品系統(tǒng)數(shù)據(jù),讀的量遠(yuǎn)遠(yuǎn)大于寫的量,可以拆分成商品讀系統(tǒng),商品寫系統(tǒng);讀系統(tǒng)可以通過緩存提升性能。寫的量大時(shí)可以考慮分庫分表。
1.3服務(wù)化
進(jìn)程內(nèi)服務(wù)--》單機(jī)遠(yuǎn)程服務(wù)--》集群手動(dòng)注冊服務(wù)--》自動(dòng)注冊和發(fā)現(xiàn)服務(wù)--》服務(wù)的分組/隔離/路由--》服務(wù)治理如限流黑白名單。
1.4消息隊(duì)列
解耦一些不需要同步調(diào)用的服務(wù)或一對多訂閱模式服務(wù)。使用消息隊(duì)列可以起到服務(wù)解耦、異步處理、流量削峰和緩沖等作用。要考慮的問題:1訂閱者太多導(dǎo)致單個(gè)消息隊(duì)列成為瓶頸,需要對單個(gè)消息隊(duì)列進(jìn)行鏡像復(fù)制。2消息重復(fù)接受問題需要進(jìn)行一些防重處理。3消息接受失敗問題需要進(jìn)行告警和處理后續(xù)失敗問題。
大流量緩沖:在流量特別高時(shí)可以考慮犧牲掉強(qiáng)制一致性,而保持最終一致性。比如扣減庫存,可以先在redis中進(jìn)行扣減,記錄日志,同時(shí)使用異步的方式通過worker同步到DB。同時(shí)對隊(duì)列中的消息最好加上處理人、正在處理、已處理、處理失敗、失敗次數(shù)等字段。
數(shù)據(jù)校對:在使用了消息異步機(jī)制的場景下,可能存在消息丟失,所以定期進(jìn)行數(shù)據(jù)校對是很有必要的。
1.5數(shù)據(jù)異構(gòu)
數(shù)據(jù)異構(gòu):訂單的分庫分表一般按照訂單ID進(jìn)行分,如果要查詢某個(gè)用戶的訂單列表則需要聚合多個(gè)表的數(shù)據(jù)后才能返回,這樣就導(dǎo)致訂單表讀性能比較低,此時(shí)就需要對訂單表進(jìn)行異構(gòu)處理,按照用戶ID異構(gòu)出一套用戶訂單表,按照用戶ID進(jìn)行分庫分表。數(shù)據(jù)的異構(gòu)一般是通過消息隊(duì)列進(jìn)行操作。
數(shù)據(jù)閉環(huán):數(shù)據(jù)異構(gòu)--》數(shù)據(jù)聚合--》前段展示。
數(shù)據(jù)聚合指的是把動(dòng)不同源拿過來的數(shù)據(jù)聚合到一起存儲(chǔ),然后到用時(shí)直接一次性放回所有使用到的數(shù)據(jù)。
1.6緩存銀彈
1.瀏覽器緩存:對實(shí)時(shí)性不是很敏感的數(shù)據(jù)做瀏覽器緩存,如商品詳情框架、商家評分、評價(jià)、廣告詞等。但對價(jià)格、庫存等實(shí)時(shí)性要求比較高的數(shù)據(jù),不能使用瀏覽器緩存。
2.APP客戶端緩存:在大促活動(dòng)前將js/css/img等靜態(tài)資源提前下發(fā)到客戶機(jī)上面,這樣在大促時(shí)就不用從新從服務(wù)端拉取。還比如對首頁或則地圖等離線緩存。
3.CDN緩存:將一些靜態(tài)頁面、圖片等可以考慮推送到離用戶最近的CDN節(jié)點(diǎn),讓用戶在離他最近的CDN節(jié)點(diǎn)找數(shù)據(jù)。CDN緩存一般有兩種機(jī)制:第一種(推送機(jī)制)當(dāng)內(nèi)容變更主動(dòng)推送到每個(gè)CDN節(jié)點(diǎn)。第二種(拉取機(jī)制)當(dāng)訪問的URL資源在CDN節(jié)點(diǎn)沒有時(shí)直接從源服務(wù)器拉取,并存儲(chǔ)到CDN節(jié)點(diǎn)。使用CDN節(jié)點(diǎn)需要注意URL中不能有隨機(jī)數(shù),不然每次的URL都不一樣,每次都穿透CDN到源服務(wù)器取資源。
4.接入層緩存:如果沒有CDN緩存可以考慮使用NGINX搭建一層接入緩存。
5.引用層緩存:也就是我們使用Tomcat時(shí),可以使用堆內(nèi)緩存/堆外緩存,堆內(nèi)緩存的最大問題就是重啟時(shí)會(huì)清空緩存,所以可以考慮使用local redis代替堆外緩存,多個(gè)主機(jī)需要主從機(jī)制同步數(shù)據(jù)。
6.分布式緩存:如果緩存數(shù)據(jù)量比較大就需要使用分布式緩存,常見的分片規(guī)則就是一致性hash。
1.7并發(fā)化
當(dāng)需要的數(shù)據(jù)是從多個(gè)源獲取時(shí),可以使用多線程并發(fā)從多個(gè)源獲取數(shù)據(jù),最終聚合數(shù)據(jù)展示。
2.高可用原則
2.1降級
對于一個(gè)高可用服務(wù),很重要的一個(gè)設(shè)計(jì)就是在特殊情況下服務(wù)進(jìn)行降級使用,以保證業(yè)務(wù)正常進(jìn)行。
對于降級的思路有:
1開關(guān)集中化管理,把各系統(tǒng)的開關(guān)放到配置中心管理,由配置中心主動(dòng)推送到各個(gè)應(yīng)用使用。
2降級使用的情況,如正常情況下應(yīng)用從本地緩存讀取數(shù)據(jù),在本地內(nèi)存壓力比較大的時(shí)候可以降級使用,設(shè)置為制度redis緩存,甚至不讀緩存直接讀取默認(rèn)拖底數(shù)據(jù)。
3.開關(guān)前置化處理,如架構(gòu)為Nginx->Tomcat時(shí),開關(guān)可以設(shè)計(jì)在Nginx層,這樣當(dāng)Nginx進(jìn)行流量控制之后Tomcat應(yīng)用受到的就是較少的流量。
4.業(yè)務(wù)降級使用,比如在電商大促期間為了保證用戶下單和支付等核心業(yè)務(wù)正常運(yùn)行,可以把其他系統(tǒng)的降級使用,比如同步調(diào)用改成異步調(diào)用或可以暫時(shí)不保證數(shù)據(jù)實(shí)時(shí)一致性但是保證數(shù)據(jù)最終一致性。
2.2限流
限制流量可以防止流量超出峰值,且也可以防止惡意流量攻擊等。
限制流量思路:最終目的是限制流量穿透到后端應(yīng)用層,造成較大壓力。
1惡意請求只訪問到cache,不穿透到后端應(yīng)用。
2.對于穿透到后端應(yīng)用的流量進(jìn)行Nginx的limit模塊限制處理。
3.對于惡意IP可以使用nginx deny進(jìn)行屏蔽處理。
2.3切流量
切流量及在各流量入口做流量分配
DNS:切換機(jī)房入口
HttpDNS:在APP場景下,在客戶端就分配好流量入口,繞過運(yùn)營商LocalDNS,實(shí)現(xiàn)更精確流量調(diào)度。
LVS/HaProxy:切換故障的接入層Nginx
Nginx:切換故障的應(yīng)用層。
2.4可回滾
設(shè)置發(fā)布版本、數(shù)據(jù)版本機(jī)制,在系統(tǒng)出現(xiàn)故障時(shí)及時(shí)回滾到最近一個(gè)正常版本上。
3業(yè)務(wù)設(shè)計(jì)原則
3.1.防止重復(fù)提交設(shè)計(jì)
3.2冪等操作設(shè)計(jì)
3.3流程可定義
3.4狀態(tài)和狀態(tài)機(jī)
3.5后臺(tái)系統(tǒng)操作可反饋
3.6后臺(tái)系統(tǒng)審批化
3.7文檔和注釋
3.8備份
?
轉(zhuǎn)載于:https://my.oschina.net/u/3100849/blog/988546
總結(jié)
以上是生活随笔為你收集整理的读书笔记:交易型系统设计的一般原则的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: SpringBoot笔记——1
- 下一篇: 戴尔发布面向制造、生命科学和研究的高性能