高性能架構

上一篇文章初識架構讓我們對架構設計的複雜度考慮有了一定了解，主要有個高可用、高性能、可擴充。但僅僅知道是不夠用的，接下來，将從高性能來進行詳細分享

1. 高性能資料庫

從資料庫分享高性能，主要是兩個方面分别是：

1.1 讀寫分離

讀寫分離的主要原理是将讀和寫分散到不同的節點上

1.1.1 實作方式

資料庫搭建主從模式，一主多從或一主一從。主伺服器負責寫， 從伺服器負責讀。從伺服器通過複制的方式從主伺服器同步資料。

在業務域實作分别有兩種方式：

1. 從代碼層面實作。主要是代碼封裝，通過将讀寫請求分離出，請求不同的資料源
2. 從中間件層實作。如：MysqlProxy等

1.1.2 帶來的問題

讀寫分離将業務讀寫的壓力分開，但是也帶來了一些其他問題，如：

1. 主從複制可能有延時，主從資料間資料不一緻問題
2. 将資料的讀壓力分散開，但是并沒有減少資料庫的寫壓力
3. 為了區分度讀寫操作，需要引入中間件或對代碼進行改造

1.2 分庫分表

通常在資料表有壓力的時候，我們會采取分庫分表的政策，将資料分在不同的資料區域，減少資料存儲壓力。

1.2.1 分庫

業務分庫：按照業務子產品将不同的資料存儲到不同的資料庫伺服器

2.1.1 帶來的d問題

1. 事務問題： 多庫間操作無法在一個事務内完成
2. 成本問題：分庫帶來伺服器數量增加，進而增加成本
3. 資料查詢帶來複雜問題： 多庫不利于 join()操作

1.2.2 分表

分表：單表存儲資料過大時，需要對資料進行分表存儲，放在不同的表中。分表又分為兩種，分别是：垂直分表、水準分表。

垂直分表：把不常用的字段分出去。分表方式如：備注，内容等大字段

水準分表：對單表資料較大的進行分表。分表方式如： ID， 年月

1.2.2.1 分表政策

分表需要把資料配置設定到不同的表中，這就涉及到了表資料的配置設定算法。主要的配置設定算法有：

1. 範圍路由：如根據ID，1999999,10000009999999
2. Hash路由：可以根據某些字段，進化hash計算，如 hash%表數。
3. 配置路由：建立一張表，配置路由鍵與表之間的關系。如log_id，table_num兩列。

1.2.2.2 帶來的問題

1. 資料表聚合操作标的麻煩，如：group by，count等
2. 合适的資料路由政策選擇，防止資料不均勻

1.3 優化政策

通常，我們在資料庫出現瓶頸壓力的時候可能優先考慮的是上述方案，這樣其實是不對的。對于資料庫方面的優化政策主要是：1、從硬體方面優化。2、SQL優化。3、增加緩存。4、分庫分表。這樣優化的如要目的主要是減少代碼的改動量，保證業務的穩定性。

2. 高性能NoSQL

在某些情況下，我們需要根據具體情況選擇合适的NoSQL，具體有如下NoSQL。

2.1 Key-Value形式

key-value形式的NoSQL主要解決關系型資料庫無法存儲資料結構的問題。以Redis為代表。

2.2 文檔資料庫

文檔資料庫主要解決關系型資料庫強Schema問題。以MongoDB為代表。

2.2.1 優點 & 缺點

優點：1、新增字段簡單。 2、對曆史資料不會造成影響。 3、容易存儲複雜結構資料，如JSON。

缺點：1、不支援ACID

2.3 列式資料庫

列式資料庫主要解決大資料場景下I/O問題。以HBase，clickhouse為代表

2.3.1 優點 & 缺點

優點：1、資料讀取量小，如一行是4K, 某列可能隻有4Byte，可以減少I/O。 2、同一列資料高度相似，可以提高壓縮比例，易于存儲。

缺點：1、對多列資料進行修改，查詢多列由于是随機I/O，相對與行順序I/O，性能較差。

2.4 全文搜尋引擎

全文搜尋引擎主要解決關系型資料庫全文搜尋性能問題。以ES為代表。

1 & 2 小結

關于資料庫選擇方式，我們需要以需求為導向。根據合适的業務場景選擇合适的資料庫。主要的考量名額有：資料量、并發量、一緻性要求、讀寫分布、安全、運維等。

3. 高性能緩存架構

在應對一些又計算後得出的資料，或者讀多寫少的場景，一般存儲系統無法應對，我們需要引入緩存。如：Redis，MemCache。接下來主要說一下系統引入緩存架構帶來的問題。

3.1 緩存穿透

緩存穿透主要是資料的查詢直接落在資料庫上導緻。造成緩存穿透的主要原因有兩點，分别是：

1. 查詢資料不存在。
2. 查詢資料剛好失效，生成緩存時間較長。

解決政策：

1. 緩存空資料
2. 使用布隆過濾器

3.2 緩存雪崩

緩存雪崩主要是緩存失效，引起系統性能急劇下降。造成雪崩的主要原因是：

1. 新緩存生成耗費時間，多線程同時更新緩存，造成DB壓力，進而拖動系統西能。

1. 更新鎖機制：對緩存的更新進行加鎖操作。
2. 背景更新機制： 緩存長久有效，通過背景手動更新或緩存失效，觸發背景更新等。

3.3 緩存熱點

緩存熱點主要是同一時間通路量急劇增大導緻，如微網誌上"爆"點。

1. 多級緩存：通過實時分析，将預熱資料存入本地緩存中，然後才是緩存系統
2. 将熱點資料進行多副本儲存：如key_1, key_2, key..n等，分散查詢。

4. 單機高性能

增加單機高性能，則可以通過增加程序或線程的方式，我們一般通過增加線程的方式。主要的方式有兩種：分别是：

1. IO多路複用， Reactor
2. AIO

5. 高性能負載均衡

通常，負載均衡也是高性能的一塊，一個合适的負載均衡，對系統的提升也非常明顯。從大往小了說，主要分為三類，分别是：DNS負載，硬體負載，軟體負載。接下來将一一介紹。

5.1 DNS負載均衡

DNS負載均衡主要是有DNS廠商提供的一種負載均衡算法，其主要邏輯是：通過解析域名，可以傳回不同的IP位址。如：解析www.jd.com，上海使用者通過DNS解析出來的位址可能是：10.23.12.1; 黑龍江使用者解析出來的是：60.111.23.55；這樣通過不同的IP，通路就近的位址，加速使用者的通路。

5.1.1 優點 & 缺點

DNS負載的優點主要有：1、直接又DNS廠商提供，操作簡單，成本低。2、使用者通路就近區域，加速使用者通路速度。

缺點也比較明細：1、IP緩存時間長，使用者可能更新不及時。

5.2 硬體負載均衡

硬體負載均衡主要是通過硬體層面來進行負載均衡，和交換機，路由器類似。主要代表有F5,A10。

5.2.1 優點 & 缺點

優點：1、性能強勁，可以支援百萬級并發量。 2、支援在網絡各層級進行負載，支援多種負載算法。3、支援安全防火。如：DDOS

缺點：1、價格昂貴，一般公司承受不起。2、可以根據業務配置，但是無法進行擴充和定制

5.3 軟體負載均衡

軟體負載均衡主要是通過軟體來進行負載均衡，主要代表有Nginx（7層）、LVS（4層）等。同硬體想比，軟體則無法支援那麼大的并發量。但也有自己的優點。

5.3.1 優點 & 缺點

優點：1、部署運維簡單，都提供部署方法。2、便宜，多加機器就可以部署。3、靈活，可以在網絡7層或4層進行配置，支援擴充。

缺點：1、沒有硬體負載那麼大并發，如Nginx并發：5W/s。2、不支援網絡安全防護，如DDOS攻擊。

5.4 負載均衡算法分類

講完了負載均衡，那接下來就講解一下負載均衡算法的分類，主要也分為四大類，分别是：任務平分類、負載均衡類、Hash算法、性能最優類。接下來一一分析一下。

5.4.1 任務評分類

任務平分類主要是将任務平均配置設定，實作比較簡單，無狀态，和機器無關。如：輪詢

5.4.2 負載均衡類

這裡的負載均衡不是我們了解的負載均衡，而是通過計算出機器的性能，使用情況，如：CPU，IO，網卡連接配接數等，然後在配置設定任務。對機器性能做出平衡。防止差的機器接收大量的任務。如：權重輪詢，負載最低優先

5.4.3 Hash類

負載均衡根據任務中的某些資訊，進行hash計算，将相同hash值的任務放在同一個伺服器上。這樣可以滿足某些特定業務需求。如：根據機器Ip進行hash計算，或者根據id進行hash計算。

5.4.4 性能最優類

性能最優類和負載均衡類有所不同，性能最優類是站在用戶端的角度來看，誰處理任務快，就把任務多配置設定一些。負載均衡類是站在伺服器端的角度來看。

6 總結

以上是總結的關于高性能架構設計時，我們可以考慮的點。在考慮設計時，我們不必拘泥于選擇其中一點，而是進行搭配使用。為了滿足業務需求，進行最大程度選擇組合，這樣才可以設計出符合業務的高性能架構。

你的每一個點贊，我都當做喜歡