本系列主要是为了对redis的网络模型和集群原理进行学习，我会用golang实现一个reactor网络模型，并实现对redis协议的解析。
系列源码已经上传github
https://github.com/HobbyBear/tinyredis/tree/chapter2
在介绍redis网络模型前，我们先来看看redis的一条命令执行涉及到哪些阶段。
从连接读取数据 => 协议解析 => 命令执行 => 将结果返回给客户端
而平时我们说的redis的单线程指的则是 命令执行阶段是单线程的，而redis6.0以后协议解析和返回结果给客户端都可以是多线程去进行处理。
由此衍生出redis6.0的网络模型如下:
主线程通过一个epoll实例负责监听连接和等待数据的到达，并且执行解析好的命令。
举个例子，当主线程执行epoll wait时发现有100个socket可读，并且这100个socket都是已经完成连接建立的socket，然后主线程就会把这100个socket分给子线程去进行读取， 当子线程将这些socket的 字节数据解析成redis命令后，会再把这些命令交再给主线程去执行。主线程执行完以后又将这些命令执行结果交给子线程去进行发送。
整个过程可以看到实际的网络io的读取是交给多个线程去执行了，但是命令的执行还是在一个线程完成的。
再用流程图去表示整个过程将会更加清晰,
可以看见，整个过程中命令执行是在主线程去顺序执行的。而现在我们就是要用golang去实现这样一个模型。
要实现主线程等待子线程池执行的效果，我们可以用golang的sync.WaitGroup 实现主协程等待子协程执行完毕的效果，子协程去进行协议的解析，为此，在前面代码的基础上，我封装了两个队列，一个用于读，一个用于写，主协程在需要读写时就将任务丢给队列执行，并等待队列执行完毕。
type Server struct {
Poll *poll
addr string
listener net.Listener
ConnMap sync.Map
readQueue *ioReadQueue
writeQueue *ioWriteQueue
}
队列的实现则是利用sync.WaitGroup实现的等待效果，
type ioReadQueue struct {
seq atomic.Int32
handle ioReadHandle
conns []chan *Conn
wg sync.WaitGroup
requests []*Request
}
handle则是进行协议解析的方法，conns 存放的则是待解析协议的连接，在队列创建时，会启用conns长度大小的协程对conns里的连接进行读取。
func newIoReadQueue(perChannelLen int, handle ioReadHandle, goNum int) *ioReadQueue {
res := &ioReadQueue{handle: handle, wg: sync.WaitGroup{}, requests: make([]*Request, 0)}
conns := make([]chan *Conn, goNum)
for i := range conns {
conns[i] = make(chan *Conn, perChannelLen)
connlist := conns[i]
go func() {
for conn := range connlist {
....
res.wg.Done()
}
}()
}
res.conns = conns
return res
}
这样便最简单的实现了一个固定大小的协程池，然后继续进行接下来的代码编写。
最终读队列是要对redis协议进行解析，redis的协议是被称作resp协议,由于我的重点并不是放在协议解析上，所以我不打算对resp协议的解析进行具体的讲解。但是我们要做的是对协议层进行抽象，因为当你实现一个网络框架后，你应该让你的框架支持不止一种协议，比如它同时支持http，icmp等等。
源码部分实现了对resp协议和行协议的解析，篇幅有限，所以本文只关注关键逻辑和设计即可
由于网络中传输的都是字节，要转换成特定的协议，必然涉及到字节与协议体的相互转换，所以协议必然有编码和解码的方法。并且对协议的处理也应该有上层应用定义，网络框架只管对数据传输。
这样我便设计出了下面的接口
type ProtocolMsg interface {
Bytes() []byte
}
type Protocol interface {
ReadConn(c *Conn) (ProtocolMsg, error)
OnExecCmd(msg ProtocolMsg) ProtocolMsg
}
ReadConn 用于在连接可读时从连接读取协议数据，这将由应用层自己定义解码操作，OnExecCmd 用于处理解析出的协议消息，OnExecCmd返回结果到时则会由网络框架层进行发送，协议消息编码为字节数据的方式则是ProtocolMsg的Bytes 方法中定义的，ProtocolMsg 会由应用层自己实现。
❗️❗️不过这里还有一点要做修改，ReadConn定义的是解码的操作，直接将网络框架内部的Conn传递给应用层进行读写不够安全，更安全的方式是只传递一个读缓冲区给应用层进行读写。这样的好处还有一个，因为我们的目的是非阻塞的读取连接里的数据，如果连接到达的数据还不能够组成一个完整的协议，那么这个连接已经读取出来的数据应该保存起来，供下次读取时，组成一个完整的协议。
所以，我们要为Conn这个结构定义一个缓冲区了。在通过redis学网络(1)-用go基于epoll实现最简单网络通信框架 里我们定义的Conn结构是
type Conn struct {
s *Server
conn *net.TCPConn
nfd int
}
现在还需要为它加一个缓冲区结构，并且为了复用缓冲区内存，我实现了一个RingBuffer 结构，关于其实现的讲解可以参考我的这篇文章go 实现ringbuffer以及ringbuffer使用场景介绍
目前Conn结构将变为
type Conn struct {
s *Server
conn *net.TCPConn
reader *RingBuffer
nfd int
}
然后协议解码接口我将把缓冲区传进去
type Protocol interface {
ReadConn(c *Conn) (ProtocolMsg, error)
OnExecCmd(msg ProtocolMsg) ProtocolMsg
}
环形缓冲区RingBuffer 的方法我再在这里列举一下
func (r *RingBuffer) Peek(readOffsetBack, n int) ([]byte, error) {
...
}
func (r *RingBuffer) PeekBytes(readOffsetBack int, delim byte) ([]byte, error) { ...
}
func (r *RingBuffer) AddReadPosition(n int) {
...
}
RingBuffer的peek开头的方法不会改变读指针的位置，但是会读取数据，AddReadPosition则是应用层在判断是完整协议后调用的方法，用于更新读指针的位置。
接着再来看服务器的handle方法主要做的改动。我在关键步骤标记了注释
func (s *Server) handler() {
for {
// 等待连接事件到达
events, err := s.Poll.WaitEvents()
if err != nil {
log.Error(err.Error())
continue
}
for _, e := range events {
connInf, ok := s.ConnMap.Load(int(e.FD))
if !ok {
continue
}
conn := connInf.(*Conn)
if IsClosedEvent(e.Type) {
conn.Close()
continue
}
// 连接可读，则放到读队列
if IsReadableEvent(e.Type) {
s.readQueue.Put(conn)
}
}
// 等待读队列任务完成
s.readQueue.Wait()
requests := s.readQueue.requests
replyMsgs := make([]*Request, 0)
// 将读队列解析好的命令进行执行
for _, request := range requests {
replyMsgs = append(replyMsgs, &Request{msg: s.protocol.OnExecCmd(request.msg), conn: request.conn})
}
// 将执行结果放回到写队列执行
for _, replyMsg := range replyMsgs {
s.writeQueue.Put(replyMsg)
}
// 等待些队列执行完毕
s.writeQueue.Wait()
// 由于读队列缓存了中间结果，一次轮询后进行清除
s.readQueue.Clear()
}
}
对于代码的讲解和设计思路，我这里只是列出了关键的点，细节可能还是需要去看下源码是如何实现的。但是最重要的是通过这个小demo，理解epoll的网络编程并且理解了redis的网络模型。