write smart proxy step by step 3 (叢集實現)

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。
趙雷

有點長，直接看結語好了

叢集功能

第二篇筆記只實現 Redis 協議單機轉寄，這次要實現完整叢集功能，涉及以下幾點：

1. 代碼邏輯模組劃分: Server，叢集拓撲，後端串連池，Session管理

2. Pipeline 實現，對每一個請求封裝 Sequence，嚴格保證應答順序(實現有些投機，後文再說)

3. 對後端返回的 ErrorResp 做解析，特殊處理 MOVED 和 ASK 請求並非同步更新叢集拓撲

4. 效能，永遠的話題，通過 Pprof 一步一步去調

模組劃分

Server 層：該層用來解析產生全域配置，初始化其它模組，開啟監聽連接埠，接收外部存取請求。其中 Filter 用來對接收的 Redis 協議資料進行過濾，檢測是否危險禁止或不支援的命令，並粗略檢測命令參數個數，以介面形式實現。

type Proxy struct {

l net.Listener // 監聽 Listener

filter Filter // Redis 有效協議檢測過濾器

pc *ProxyConfig // 全域設定檔

sm *SessMana // Session 管理

cluster *Cluster // 叢集實現

}

type Filter interface {

Inspect(Resp) (string, error)

}

叢集拓撲：隨機挑選 Redis 節點，根據 Cluster Nodes 輸出資訊產生邏輯拓撲結構。預設每10min 定期 Reload 拓撲資訊，每當 reloadChan 接收到資料時，強制 Reload。

e32929a56d00a28934669d8e473f68c5de84abce 10.10.200.11:6479 myself,master - 0 0 0 connected 0-5461

type Topology struct {

conf *ProxyConfig // 全域配置

rw sync.RWMutex // 讀寫鎖

slots []*Slot // Cluster Slot 邏輯拓撲結構

reloadChan chan int // Reload 訊息 channel

}

拓撲最重要功能，根據給定 Key 返回對應後端 Redis 節點資訊。Key 解析出 hash tag 按照 crc16 演算法產生並對16384取餘，Session 拿到 Node ID 後從串連池擷取串連。

GetNodeID

Session 管理：每個用戶端串連封裝成一個 Session，Server 層維護著 Session 管理工作，關閉逾時的串連，預設 30s

type SessMana struct {

l sync.Mutex // Session 鎖

pool map[string]*Session // Session Map

idle time.Duration // 逾時時間長度

}

SessMana 實現簡單，三個方法：添加，刪除以及定期檢查 Idle 串連

func (sm *SessMana) Put(remote string, s *Session) {

}

func (sm *SessMana) Del(remote string, s *Session) {

}

func (sm *SessMana) CheckIdleLoop() {

}

串連池：最開始想自已寫，發現有很多細節想不到，就直接使用 Golang Redis Driver 的串連池

type pool interface {

First() Conn

Get() (Conn, error)

Put(Conn) error

Remove(Conn) error

Len() int

FreeLen() int

Close() error

}

上面是串連池 interface ，看似簡單，具體代碼請看 pool.go，有幾點細節需要仔細思考：

1. 為了實現通用的串連池，調用方需要傳入自訂 Dialer 以及定義 Conn 介面方便擴充。

2. 流控的問題，比如說在正常逾時時間內，開啟串連數不能超過一定次數。這裡採用 ratelimit 實現。想起以前在趕集，蔡導提過搶狗食的問題。

3. 串連池維護的串連有效性，用 LastUsed 逾時，還是使用 Ping 來處理是個問題。內網總是假設穩定，所以 LastUsed 問題不大。

4. 如果使用 LastUsed 逾時檢測，那麼串連池內部活動訊號間隔時間，一定要短於後端 Redis Idle Timeout 逾時時間。

Pipeline

對於不支援 Pipeline 的流程: client -> proxy -> redis - > proxy -> client . 所以有兩層可以支援 Pipeline，第一層從 client -> proxy，這層很簡單，開啟 Channel 接收請求，Proxy 去阻塞式處理請求，然後返回到 client 。

第二層 proxy -> redis - > proxy 不好實現，對於 Redis Cluster 叢集，命令分發到後端不同執行個體。由於網路問題，Redis 服務問題，MOVED跳轉造成的先發後至，結果集亂序肯定發生，並且是常態。所以簡單直觀的解決辦法，對每一個請求封裝，增加64位的 Seq, 這個序號是 Session 層級的。

type wrappedResp struct {

seq  int64 // Session 層級的自增64位ID

resp Resp  // Redis 協議結果

}

第二層開啟 goroutine，每當 Proxy 收到響應，都會檢查 Seq 是否與發送端的序號一致。會出現三種情況：

1. Seq 與發送端序號相等：這是最理想的情況，在 Session 層直接 WriteProtocol 寫到 Client

2. Seq 大於發送端序號: 說明發生了亂序，將該 Seq 結果暫緩衝起來，但是不能無限緩衝，如果序號相隔過多，或是等待時間過長，那麼產生一個 ErrorResp 返回用戶端。當前只判斷序號，沒有採用逾時來解決。

3. Seq 小於發送端序號: 接收的 Seq 小，說明已經被跳過了。直接忽略，並記日誌 debug。

MOVED與ASK

後端 Client -> Proxy，檢測是否為 ErrorResp，不是走正常邏輯即可。否則進一步判斷，錯誤碼前輟是否為 MOVED或ASK，再執行 Redirect 邏輯執行請求。如果為 MOVED，那麼要非同步重新整理拓撲結構。

效能最佳化

開啟 Pprof 查看效能，參考 官方文檔 和 yjf部落格

import _ "net/http/pprof"

go func() {

log.Warning(http.ListenAndServe(":6061", nil))

}()

go tool pprof -pdf ./archer http://localhost:6061/debug/pprof/profile -output=/tmp/report.pdf

或是進入內部執行命令查看

go tool pprof ./archer http://localhost:6061/debug/pprof/profile

Int 轉 []byte

pprof util.Itob

在Pprof 圖中看到 util.Itob 調用效率比較低，這個函數將 Int 轉換成 []byte，用於 Resp.Encoding 時產生長度，第一版實現如下:

func Itob(i int) []byte {

return []byte(strconv.Itoa(i))

}

第二版 Iu32tob

func Iu32tob(i int) []byte {

return strconv.AppendUint(nil, uint64(i), 10)

}

第三版本 Iu32tob2

func Iu32tob2(i int) []byte {

buf := make([]byte, 10) // 大量小對象的建立是個問題，同樣需要對象池

idx := len(buf) - 1

for i >= 10 {

buf[idx] = byte('0' + i%10)

i = i / 10

idx--

}

buf[idx] = byte('0' + i)

return buf[idx:]

}

做 Benchmark 結果如下，將 Itob 替換成第三版本的 Iu32tob2

localhost:util dzr$ go test -v -bench=".*"

testing: warning: no tests to run

PASS

Benchmark_Itob-4        10000000              116 ns/op

Benchmark_Iu32tob-4    20000000                98.4 ns/op

Benchmark_Iu32tob2-4    20000000                80.2 ns/op

ok      github.com/dongzerun/archer/util        5.101s

再次開啟 Pprof 查看 ReadProtocol 和 WriteProtocol 的 syscall 量最大，並且 Resp.Encode() 會有大量的 bytes.Buffer 對象產生，應該將做成對象池。那麼 Resp 的Encode 方法要改：

Resp.Encode() []byte

變成

Resp.Encode(w *bufio.Writer) error

Pprof

壓測資料

單機本機原生單台 Redis 

PING_INLINE: 139664.81 requests per second

PING_BULK: 144092.22 requests per second

SET: 146412.89 requests per second

GET: 145921.48 requests per second

INCR: 142166.62 requests per second

LPUSH: 144634.08 requests per second

LPOP: 141302.81 requests per second

SADD: 139567.34 requests per second

SPOP: 142714.42 requests per second

LPUSH (needed to benchmark LRANGE): 144655.00 requests per second

LRANGE_100 (first 100 elements): 65355.21 requests per second

LRANGE_300 (first 300 elements): 26616.98 requests per second

LRANGE_500 (first 450 elements): 18669.26 requests per second

LRANGE_600 (first 600 elements): 14510.21 requests per second

MSET (10 keys): 121995.86 requests per second

單機 Proxy 後端 Redis Cluster 3個 Master節點，未使用對象池

PING_INLINE: 100361.30 requests per second

PING_BULK: 96918.01 requests per second

SET: 92131.93 requests per second

GET: 90612.54 requests per second

INCR: 91852.66 requests per second

LPUSH: 84645.34 requests per second

LPOP: 87092.84 requests per second

SADD: 88300.22 requests per second

SPOP: 90851.27 requests per second

LPUSH (needed to benchmark LRANGE): 88448.61 requests per second

LRANGE_100 (first 100 elements): 25277.42 requests per second

LRANGE_300 (first 300 elements): 10484.71 requests per second

LRANGE_500 (first 450 elements): 7604.97 requests per second

LRANGE_600 (first 600 elements): 5883.36 requests per second

MSET (10 keys): 17710.71 requests per second

單機 Proxy 後端 Redis Cluster 3個 Master節點，sync.Pool開啟bytes.Buffer對象池

PING_INLINE: 109829.77 requests per second

PING_BULK: 102743.25 requests per second

SET: 91290.85 requests per second

GET: 92790.20 requests per second

INCR: 93466.68 requests per second

LPUSH: 90604.34 requests per second

LPOP: 90277.16 requests per second

SADD: 85682.46 requests per second

SPOP: 91432.75 requests per second

LPUSH (needed to benchmark LRANGE): 89726.33 requests per second

LRANGE_100 (first 100 elements): 25667.35 requests per second

LRANGE_300 (first 300 elements): 10589.07 requests per second

LRANGE_500 (first 450 elements): 7683.91 requests per second

LRANGE_600 (first 600 elements): 5826.89 requests per second

MSET (10 keys): 17955.90 requests per second

相比未使用對象池是好一些。。。

結語

效能資料不是很理想，再找找 Pprof 還有哪些可以最佳化的，很多 SysCall Runtime 不是很懂，再鞏固下 Go 基礎。代碼格式也不夠美觀^_^

最近聽了十六歲少年，越陽的故事。十六歲花季，凋落的有些無耐

慶幸他的詞都被譜成了歌曲，最喜歡趙雷填曲的《讓我偷偷看你》，期待明天他會唱這首歌...