2019獨角獸企業重金招聘Python工程師標準>>>

系統設計的一般原則

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備份

?

轉載于:https://my.oschina.net/u/3100849/blog/988546

總結

以上是生活随笔為你收集整理的读书笔记：交易型系统设计的一般原则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。