讀書筆記：交易型系統設計的通常原則

系統設計的通常原則

1.高併發原則

1.1無狀態

應用應該被設計成爲無狀態的，這樣應用也比較容易進行水平擴展。實際生產系統一般被設計成爲應用無狀態，配置有狀態，那麼只須要經過配置文件或配置中心指定便可。

1.2拆分

根據實際狀況進行系統拆分，若是系統使用人員較少，併發不高，徹底沒有壓力作一個大而全的系統也無可厚非。

系統維度：按照系統功能/業務拆分，好比商品系統、購物車、結算、訂單系統等等。

功能維度：好比對一個業務系統優惠券進行再拆分，後臺券建立系統、領券系統、用券系統。

讀寫維度：根據讀寫比例特徵進行拆分。好比，商品系統，交易的各個系統都會讀取商品系統數據，讀的量遠遠大於寫的量，能夠拆分紅商品讀系統，商品寫系統；讀系統能夠經過緩存提高性能。寫的量大時能夠考慮分庫分表。

1.3服務化

進程內服務--》單機遠程服務--》集羣手動註冊服務--》自動註冊和發現服務--》服務的分組/隔離/路由--》服務治理如限流黑白名單。

1.4消息隊列

解耦一些不須要同步調用的服務或一對多訂閱模式服務。使用消息隊列能夠起到服務解耦、異步處理、流量削峯和緩衝等做用。要考慮的問題：1訂閱者太多致使單個消息隊列成爲瓶頸，須要對單個消息隊列進行鏡像複製。2消息重複接受問題須要進行一些防重處理。3消息接受失敗問題須要進行告警和處理後續失敗問題。

大流量緩衝：在流量特別高時能夠考慮犧牲掉強制一致性，而保持最終一致性。好比扣減庫存，能夠先在redis中進行扣減，記錄日誌，同時使用異步的方式經過worker同步到DB。同時對隊列中的消息最好加上處理人、正在處理、已處理、處理失敗、失敗次數等字段。

數據校對：在使用了消息異步機制的場景下，可能存在消息丟失，因此按期進行數據校對是頗有必要的。

1.5數據異構

數據異構：訂單的分庫分表通常按照訂單ID進行分，若是要查詢某個用戶的訂單列表則須要聚合多個表的數據後才能返回，這樣就致使訂單表讀性能比較低，此時就須要對訂單表進行異構處理，按照用戶ID異構出一套用戶訂單表，按照用戶ID進行分庫分表。數據的異構通常是經過消息隊列進行操做。

數據閉環：數據異構--》數據聚合--》前段展現。

數據聚合指的是把動不一樣源拿過來的數據聚合到一塊兒存儲，而後到用時直接一次性放回全部使用到的數據。

1.6緩存銀彈

1.瀏覽器緩存：對實時性不是很敏感的數據作瀏覽器緩存，如商品詳情框架、商家評分、評價、廣告詞等。但對價格、庫存等實時性要求比較高的數據，不能使用瀏覽器緩存。

2.APP客戶端緩存：在大促活動前將js/css/img等靜態資源提早下發到客戶機上面，這樣在大促時就不用重新從服務端拉取。還好比對首頁或則地圖等離線緩存。

3.CDN緩存：將一些靜態頁面、圖片等能夠考慮推送到離用戶最近的CDN節點，讓用戶在離他最近的CDN節點找數據。CDN緩存通常有兩種機制：第一種（推送機制）當內容變動主動推送到每一個CDN節點。第二種（拉取機制）當訪問的URL資源在CDN節點沒有時直接從源服務器拉取，並存儲到CDN節點。使用CDN節點須要注意URL中不能有隨機數，否則每次的URL都不同，每次都穿透CDN到源服務器取資源。

4.接入層緩存：若是沒有CDN緩存能夠考慮使用NGINX搭建一層接入緩存。

5.引用層緩存：也就是咱們使用Tomcat時，可使用堆內緩存/堆外緩存，堆內緩存的最大問題就是重啓時會清空緩存，因此能夠考慮使用local redis代替堆外緩存，多個主機須要主從機制同步數據。

6.分佈式緩存:若是緩存數據量比較大就須要使用分佈式緩存，常見的分片規則就是一致性hash。

1.7併發化

當須要的數據是從多個源獲取時，可使用多線程併發從多個源獲取數據，最終聚合數據展現。

2.高可用原則

2.1降級

對於一個高可用服務，很重要的一個設計就是在特殊狀況下服務進行降級使用，以保證業務正常進行。

對於降級的思路有：

1開關集中化管理，把各系統的開關放到配置中心管理，由配置中心主動推送到各個應用使用。

2降級使用的狀況，如正常狀況下應用從本地緩存讀取數據，在本地內存壓力比較大的時候能夠降級使用，設置爲制度redis緩存，甚至不讀緩存直接讀取默認拖底數據。

3.開關前置化處理，如架構爲Nginx->Tomcat時，開關能夠設計在Nginx層，這樣當Nginx進行流量控制以後Tomcat應用受到的就是較少的流量。

4.業務降級使用，好比在電商大促期間爲了保證用戶下單和支付等核心業務正常運行，能夠把其餘系統的降級使用，好比同步調用改爲異步調用或能夠暫時不保證數據實時一致性可是保證數據最終一致性。

2.2限流

限制流量能夠防止流量超出峯值，且也能夠防止惡意流量攻擊等。

限制流量思路：最終目的是限制流量穿透到後端應用層，形成較大壓力。

1惡意請求只訪問到cache，不穿透到後端應用。

2.對於穿透到後端應用的流量進行Nginx的limit模塊限制處理。

3.對於惡意IP可使用nginx deny進行屏蔽處理。

2.3切流量

切流量及在各流量入口作流量分配

DNS：切換機房入口

HttpDNS：在APP場景下，在客戶端就分配好流量入口，繞過運營商LocalDNS，實現更精確流量調度。

LVS/HaProxy：切換故障的接入層Nginx

Nginx：切換故障的應用層。

2.4可回滾

設置發佈版本、數據版本機制，在系統出現故障時及時回滾到最近一個正常版本上。

3業務設計原則

3.1.防止重複提交設計

3.2冪等操做設計

3.3流程可定義

3.4狀態和狀態機

3.5後臺系統操做可反饋

3.6後臺系統審批化

3.7文檔和註釋

3.8備份