什么是熱點問題？在我們生活中，定義是：比較受廣大群眾關注或者歡迎的新聞或者信息或指某時期引人注目的地方或問題。

這里我們要講的是技術的熱點問題，SLB的熱點問題，Redis的熱點問題，Mysql的熱點問題，分布式數據庫集群的熱點問題等，這類技術熱點問題并不是所謂的引人注目的問題而是服務請求過多，流量集中的問題。

SLB

定義：服務器負載均衡（Server Load Balancing），實現多個服務器之間的負載均衡。

主流軟件負載均衡有：1：LVS，2：Nginx，3：HAProxy

1 LVS

（1）工作在網絡4層，通過VRRP協議(僅作代理之用)，具體的流量是由linux內核來處理，因此沒有流量的產生。

（2）抗負載能力強，性能高，能達到F5的60%，對內存和CPU資源消耗比較低

（3）穩定，可靠性高，自身有完美的熱備方案(Keepalived+lvs)

（4）支持8種負載均衡算法：rr（輪詢）、wrr（帶權輪詢）、lc（最小連接）、wlc（帶權最小連接）、 lblc（基于局部性的最少連接調度算法）、lblcr（復雜的基于局部性最少的連接算法）、dh（目標地址散列調度算法 ）、sh（源地址散列調度算法 ）

（5）工作模式有4種：

• nat 地址轉換
• dr 直接路由
• tun 隧道
• full-nat ?

2 Nginx

（1）工作在網絡7層，可以針對http應用做一些分流的策略，比如針對域名，目錄結構

（2）Nginx僅能支持http、https和Email協議，這樣就在適用范圍較小。

（3）對后端服務器的健康檢查，只支持通過端口來檢測，不支持通過url來檢測

（4）可以承擔較高的負載壓力且穩定，nginx是為解決c10k問題而誕生的

（5）Nginx能做Web服務器即Cache功能。?

3 HAProxy

（1）支持兩種代理模式：TCP（四層）和HTTP（七層），支持虛擬主機

（2）支持url檢測后端的服務器出問題的檢測會有很好的幫助。

（3）支持負載均衡算法：Round-robin（輪循）、Weight-round-robin（帶權輪循）、source（原地址保持）、RI（請求URL）、rdp-cookie（根據cookie）

（4）支持負載均衡策略：動態加權輪循(Dynamic Round Robin)，加權源地址哈希(Weighted Source Hash)，加權URL哈希和加權參數哈希(Weighted Parameter Hash)

（5）不能做Web服務器即Cache

現在基本所有的公司的業務最前端都是一個負載均衡服務器承載流量，然后分發到各個后端服務器，參照下圖，這樣的架構應該是大多數公司的架構。從請求主要分三個層次。用戶->負載均衡，負載均衡->微服務，微服務->后端服務。

關于負載均衡這一塊的熱點問題會出現在哪呢？從上面的分析看其實主要是在于散列調度算法，不管是源地址散列算法還是目標地址散列算法，可能會造成一個局域網的很多用戶同時請求同一服務而造成這個負載均衡服務器量很大，而造成負載均衡服務器出問題，這就是所說的熱點問題。在使用散列調度算法就容易遇到熱點問題，因為散列容易造成請求不平均，請求量大可能觸發到同一個負載均衡服務器。如果使用輪詢，負載請求會平均，不容易觸發熱點問題。當然啦，負載均衡實際基本不會出現問題，因為要是負載均衡出問題，要么業務量幾百萬倍幾千萬倍增長，那確實說明這個量很大很大。

?Redis的架構

關于Redis的部署架構主要有單機模式，主從模式，哨兵模式，redis cluser模式。其實嚴格意義上來說部署只有三種，哨兵模式其實基于對主從模式的穩定性優化，切主節點能實現自動化。

1 單機模式?

優點：1、部署簡單。2、數據一致性高

缺點：1、可靠性無法保證。2、處理能力有限

2 主從模式（如下圖）

優點：1、可靠性得到一定保障，當節點出問題，可由其他節點來提供。2、提升了讀能力，分散主節點的讀壓力

缺點：1、主節點的寫能力和存儲能力受單機限制。2、主節點宕機，切換從節點需要業務方手動切換，進行人工干預。

3 哨兵模式（如下圖）?

優點：1、基于主從模式，主從可以自動切換。

缺點：1、節點的承載能力有限，寫能力和存儲能力都有限。

4 redis cluser模式（如下圖）

優點：高可用、可擴展性、分布式、支持容錯。redis cluster接受客戶端請求，會首先通過對key進行CRC16校驗并對16384取模（CRC16(key)%16383）計算出key所在的槽，確定槽所在的節點，然后再到對應的節點上進行取數據或者存數據，這樣就實現了數據的訪問更新。

缺點：無

關于redis的三種架構模式，redis的集群架構的熱點問題就明顯了，主從模式，寫請求是很明顯的熱點問題，讀請求在讀節點中輪詢讀取，則不會出現熱點問題，但是如果讀節點是通過散列方式，則也會出現熱點問題。關于redis cluster架構是多主，多從的架構，理論上是能很好的解決熱點問題，寫請求隨機到不同的主從集群不同的主節點中，讀請求會到不同的主從集群的從節點中，這樣就很好的分散了請求，做到這一點其實至少要保證每個主節點都有一個主備。如果只有一個主節點，那其實和主從模式沒有區別了，這樣的話寫的熱點問題和讀的熱點問題就容易出現了，尤其是redis的大key讀取問題，當然不管是哪種模式下都會存在大key讀取的熱點問題，要解決大key熱點問題，redis的值設計是很有講究的，不建議值超過128KB。基礎知識了解之后，關于如何選架構成為解決熱點問題，提升服務穩定性的關鍵點。

Mysql的架構?

關于Mysql的架構（如下圖），其實只有主從模式，在業務中我們處理量大的問題通常使用讀寫分離，mysql是做數據持久化存儲，讀寫分離也是有通過中間件來實現。關于Mysql的讀和寫熱點問題，其實還是比較明顯，不管是讀和寫，量達到一定程度，都會存在的。在我們很大的業務流量下，我們Mysql的前端都會有Redis或者中間件的來擋量。

?Kafka的架構

關于Kafka的架構（如下圖）是一個分布式多分區，多副本，多訂閱者的高可用，高性能，高并發的MQ系統。Kafka寫數據是從Producer生成，需指定Topic，最終是寫入到某一個Partition（某個Leader副本的Partition）。Kafka的消費數據則是從Leader副本的某個Partition讀數據去消費。好了我們來看下寫入和讀取的熱點問題，如果客戶端一直請求同一個topic，同一個partition，等這個量達到集群的承載量就容易出現熱點問題了。所以要避免這樣的問題我們盡量讓partition能夠多一些，讓數據隨機平均到不同的partition上，這樣承載量會更大，熱點問題就不容易出現。再者kafka是號稱百萬qps的（這個涉及到kafka的底層實現，順序io，零拷貝等機制），熱點問題相對來說是很難出現的。關于讀數據這個就基本不會出現熱點問題了，因為消費者是根據partition的個數來確定的，一個partition只能對應一個消費組的一個消費者。當然會存在多個消費者的情況，一般情況不可能達到服務器讀的承載量。

?Clickhouse的架構

clickhouse的架構（如下圖）是Multi-Master多主架構，客戶端訪問任意一個節點都能得到相同的結果。clickhouse是一個大數據存儲數據庫，本身節點就有qps限制。其本身的熱點問題是比較明顯的，寫入不允許高并發，讀取也有高并發限制。我們看下clickhouse這種多主架構的一個請求的執行流程，如下圖，client發起Request1請求發到節點Clickhouse A 這個請求會轉發到Request B,Request C,Request D，等B,C,D節點返回結果之后會給節點A，然后由節點返回總的數據給Client。

總結      ?

1. 關于熱點問題要從讀和寫的方面去考慮，實現讀或者寫的分散就是解決熱點問題的關鍵。

2. 實現產品好的技術架構設計，熱點問題是我們首要考慮的問題，架構的了解對我們解決熱點問題是非常至關重要的。