有点长，直接看结语好了
集群功能
第二篇笔记只实现 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 后从连接池获取连接。
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，那么要异步刷新拓扑结构。
性能优化
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 调用效率比较低，这个函数将 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
压测数据
单机本机原生单台 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 基础。代码格式也不够美观^_^
最近听了十六岁少年，越阳的故事。十六岁花季，凋落的有些无耐
庆幸他的词都被谱成了歌曲，最喜欢赵雷填曲的《让我偷偷看你》，期待明天他会唱这首歌...
有疑问加站长微信联系（非本文作者）
