nsq源码分析
nsq的源码比较简单，值得一读，特别是golang开发人员，下面重点介绍nsqd，nsqd是nsq的核心，其他的都是辅助工具，看完这篇文章希望你能对消息队列的原理和实现有一定的了解。
nsqd是一个守护进程，负责接收，排队，投递消息给客户端，并不保证消息的严格顺序，nsqd默认监听一个tcp端口 (4150) 和一个http端口 (4151) 以及一个可选的https端口
对订阅了同一个topic的同一个channel的消费者使用负载均衡策略，其实就是多个协程消费同一个channel
只要channel存在，即使没有该channel的消费者，也会将生产者的message缓存到队列（内存队列和磁盘队列）中，当有新的消费者产生后，就开始消费队列中的所有消息
保证队列中的 message 至少会被消费一次（在进程意外退出的时候这点都保证不了），并不能保证成功消费一次，即使 nsqd退出，也会将队列中的消息暂存磁盘上（进程退出的时候会将缓存中的消息存到磁盘上，意外情况如掉电就不行了，缓存中的消息就没有机会存盘而丢失，在实战中一般不会使用缓存队列即内存buffer为0，全部使用磁盘队列）
限定内存占用，能够配置nsqd中每个channel队列在内存中缓存的message数量，一旦channel的buffer写满，就将message写到磁盘中，这点使用golang select的优先级功能，default优先级最低
topic，channel 一旦建立，将会一直存在，要及时在管理台或者用代码清除无效的 topic 和 channel，避免资源的浪费，每个topic和channel都有独立的协程处理自身的消息，默认的buffer和其他的一些信息
nsq消息没有备份，一旦出现进程意外情况退出，可能会出现消息丢失，如没有消费成功的消息，写入文件但没有真正落盘的消息，这种意外情况很难杜绝，像意外退出这种情况kafka，redis等都会遇到这样的问题，最后都会采用一个折中的策略，定时将数据落盘
//原文：https://www.cnblogs.com/hlxs/p/11445103.html 作者：啊汉
type Topic struct { // 64bit atomic vars need to be first for proper alignment on 32bit platforms messageCount uint64 //消息总数量 messageBytes uint64 //消息总长度 sync.RWMutex name string //topic name channelMap map[string]*Channel //保存topic下面的所有channel backend BackendQueue //磁盘队列 memoryMsgChan chan *Message //内存队列 startChan chan int exitChan chan int channelUpdateChan chan int waitGroup util.WaitGroupWrapper exitFlag int32 //退出标记 idFactory *guidFactory //生成msg id的工厂 ephemeral bool //是否临时topic deleteCallback func(*Topic) //删除topic方法指针 deleter sync.Once paused int32 //暂停标记，1暂停， 0正常 pauseChan chan int ctx *context }
Topic创建
nsqd用map[string]*Topic来保存所有topic，producter在发消息的时候回指定topic，nsqd在收到消息后会判断topic是否存在，不存在就会自动创建，每创建一个新的topic就会启动一个协程，用于处理topic相关的消息，如将内存/磁盘中的消息复制给topic中的每个channel、channel数量变化、channel暂停、topic退出
消息结构
// Command represents a command from a client to an NSQ daemon
//原文：https://www.cnblogs.com/hlxs/p/11445103.html 作者：啊汉
type Command struct { Name []byte //命令名称，可选：IDENTIFY、FIN、RDY、REQ、PUB、MPUB、DPUB、NOP、TOUCH、SUB、CLS、AUTH Params [][]byte //不同的命令做不同解析，涉及到topic的，Params[0]为topic name Body []byte //消息内容 } // WriteTo implements the WriterTo interface and // serializes the Command to the supplied Writer. // // It is suggested that the target Writer is buffered // to avoid performing many system calls. func (c *Command) WriteTo(w io.Writer) (int64, error) { var total int64 var buf [4]byte n, err := w.Write(c.Name) //命名名称，nsqd根据这个名称执行相关功能 total += int64(n) if err != nil { return total, err } for _, param := range c.Params { n, err := w.Write(byteSpace) //空格 total += int64(n) if err != nil { return total, err } n, err = w.Write(param) //参数 total += int64(n) if err != nil { return total, err } } n, err = w.Write(byteNewLine) //空行\n total += int64(n) if err != nil { return total, err } //消息内容 if c.Body != nil { bufs := buf[:] binary.BigEndian.PutUint32(bufs, uint32(len(c.Body))) n, err := w.Write(bufs) //消息长度4字节 total += int64(n) if err != nil { return total, err } n, err = w.Write(c.Body) //消息内容 total += int64(n) if err != nil { return total, err } } return total, nil }
nsqd收到这个结构做解析，就能知道命令名称（干什么），topic name，消息内容等，不同的命令，命令参数不一样
func (p *protocolV2) Exec(client *clientV2, params [][]byte) ([]byte, error) { if bytes.Equal(params[0], []byte("IDENTIFY")) { return p.IDENTIFY(client, params) } err := enforceTLSPolicy(client, p, params[0]) if err != nil { return nil, err } switch { case bytes.Equal(params[0], []byte("FIN")): return p.FIN(client, params) case bytes.Equal(params[0], []byte("RDY")): return p.RDY(client, params) case bytes.Equal(params[0], []byte("REQ")): return p.REQ(client, params) case bytes.Equal(params[0], []byte("PUB")): return p.PUB(client, params) case bytes.Equal(params[0], []byte("MPUB")): return p.MPUB(client, params) case bytes.Equal(params[0], []byte("DPUB")): return p.DPUB(client, params) case bytes.Equal(params[0], []byte("NOP")): return p.NOP(client, params) case bytes.Equal(params[0], []byte("TOUCH")): return p.TOUCH(client, params) case bytes.Equal(params[0], []byte("SUB")): return p.SUB(client, params) case bytes.Equal(params[0], []byte("CLS")): return p.CLS(client, params) case bytes.Equal(params[0], []byte("AUTH")): return p.AUTH(client, params) } return nil, protocol.NewFatalClientErr(nil, "E_INVALID", fmt.Sprintf("invalid command %s", params[0])) }
Topic收到消息
nsqd收到上面这个结构，解析之后，就会执行相关功能，我们以PUB命令为例：
1：读到空行处，能拿到命令名称和参数，命令名称=PUB，命令参数为topicName
2：检查topicName是否有效
3：获取消息内容长度，读取4个字节
4：分配对应内容长度空间，读取对应长度字节存入
5：获取topicName信息，没有就创建
6：构造消息结构体nsqd.Message，自动生成消息id
7：将消息提交给对应的topic，Topic.PutMessage
8：将消息写入topic对应的内存消息通道，内存消息通道默认大小为10000，如通道满了则写入磁盘
Topic中的消息分发给channel
在创建topic的时候回启动一个协程处理各种消息，其中就包括消费topic中的消息，topic只是将消息投递到其中的每个channel中，如topic下面有10个channel，则要复制9个nsqd.Message，每个channel一个nsqd.Message，但是消息id和消息内容是一样的，消息内容并不会被复制，topic收到消息将消息分发给channel就完事了，消息怎么发给消费者，由channel负责
type Channel struct { // 64bit atomic vars need to be first for proper alignment on 32bit platforms requeueCount uint64 //重新入队数量 messageCount uint64 //消息数量 timeoutCount uint64 //超时数量，已经消费，但没有反馈结果，会重新加入队列，messageCount不会自增 sync.RWMutex topicName string //topic name name string //channel name ctx *context backend BackendQueue //将消息写入磁盘的队列，维护磁盘消息的读写 memoryMsgChan chan *Message //内存消息队列，通道buffer默认10000 exitFlag int32 //退出标记，1表示退出，0没有退出 exitMutex sync.RWMutex // state tracking clients map[int64]Consumer //连接到这个topic-channel的所有client paused int32 //暂停标记，0不暂停，1暂停，暂停就不会往这个channel中copy消息 ephemeral bool //临时channel标记，临时channel不会存到文件中 deleteCallback func(*Channel) //用于从topic中删除channel deleter sync.Once // Stats tracking e2eProcessingLatencyStream *quantile.Quantile // TODO: these can be DRYd up deferredMessages map[MessageID]*pqueue.Item //延迟消息map，方便查找 deferredPQ pqueue.PriorityQueue //延迟消息队列 deferredMutex sync.Mutex inFlightMessages map[MessageID]*Message //消费中的消息map，方便查找 inFlightPQ inFlightPqueue //消费中的消息队列 inFlightMutex sync.Mutex }
client订阅topic消息
订阅发送的还是Command这个结构，只不过订阅没有消息内容而已，指定topic和channel就行，如果topic和channel不存在都会自动创建，client和server建立的是tcp长连接，server会启动两个协程，一个用于发消息，一个用于接收消息，建立连接后，channel会把client加入它的map[int64]Consumer中，key为clientId，当topic收到消息后，会分发给channel，channel通过发消息的协程发给client
channel将消息推给消费者
channel中的消息存在两个地方：内存通道和磁盘队列，topic将消息分发给channel时，通过go的select将消息分发给内存通道或是磁盘队列，由于select的default分支优先级比case低，所以只要内存通道没满，就会往内存通道中写，否则就写入磁盘，
diskqueue.diskQueue维护着磁盘数据的读写，每个非临时的topic和channel都有这样一个字段。
发消息的协程就会一直读内存通道和磁盘队列中的数据，将消息发给client
nsq消息类型有三种如下：
// frame types const ( FrameTypeResponse int32 = 0 //响应 FrameTypeError int32 = 1 //错误 FrameTypeMessage int32 = 2 //消息 )
消息发送给client之后，也不知道消息到底有没有消费成功，有可能client收到消息之后就崩溃了，所以消息发给client之后，需要client给server发一个FIN消息告诉server，这个消息我消费成功，所以在将消息发送给client之后，消息出了内存队列/磁盘队列，进入了一个新的队列，叫飞行队列，表示这个消息正在运输消费中，为了维护在消费中的消息，nsq使用了两个数据结构：
type inFlightPqueue []*Message inFlightPQ inFlightPqueue //按照超时时间排序的最小堆 inFlightMessages map[MessageID]*Message //保存消息
消息发送给client之后，同时会将消息存入inFlightPQ和inFlightMessages中，inFlightPQ中的消息都设置了超时时间默认是1分钟，如果1分钟后还没有收到client发过来的FIN消息，会将消息重新加入待消费队列，让client重新消费，目的是想保证每个消息至少被消费一次，由于消息可保存在内存中，进程可能随时挂掉并不能保证每个消息都至少被消费一次，如果不用内存队列，完全使用磁盘队列，当进程意外崩掉的时候，消息是否丢失要看磁盘队列的具体实现，完全使用磁盘队列性能差点，安全性更高
inFlightMessages就是为了方便通过消息id查找消息，收到client发送过来的FIN消息时就会将消息从inFlightPQ和inFlightMessages中删除，表示这个消息已经消费成功，数据也就被扔掉了
延迟消息
发延迟消息和发普通消息的区别是producter在生成延迟消息的时候指定了延迟时间，单位毫秒，命令：DPUB
延迟消息存在内存中，并没有存到磁盘中，延迟消息要是存在磁盘中，实现起来还是比较复杂
延迟消息同样使用了一个队列和一个map，结构如下：
type Item struct { Value interface{} //*Message Priority int64 //执行的时间戳，单位毫秒 Index int //队列索引 } type PriorityQueue []*Item deferredPQ pqueue.PriorityQueue deferredMessages map[MessageID]*pqueue.Item deferredPQ和inFlightPQ一样，是按照时间排序的最小堆
那么nsq是怎么判断消息超时，延迟消息的执行时间到了呢？
nsq有一个专门的协程来处理这两种情况，实现也很简单，就是每100毫秒检查一次，看是否有超时的消息，延迟消息是否执行时间是否到了，如果消息超时，则重新将消息加入待消费队列，每次将消息发送给client的时候，重试次数都会加一，即Message.Attempts++
延迟消息执行时间要是到了，就会当做一个普通的消息加入待消费队列，后面的流程都是一样的，默认最大延迟时间为1小时，所有的默认值在进程启动时都是可重新指定的
nsqd启动过程
1：加载启动参数
启动参数定义了结构nsqd.Options，并初始化好了默认值，在进程启动的时候可以指定对应的值，通过反射将这些参数赋给nsqd.Options，通过nsqd.Options就能方便的使用各个参数
2：加载topic和channel并启动
在nsqd启动的时候会加载配置文件nsqd.dat，验证topic和channel名称格式是否有效，然后启动所有topic，该暂停的就暂停，当topic和channel发生变更的时候回将所有信息重新保存到nsqd.dat中，如新增/删除/暂停/启动topic和channel会保存文件
topic和channel保存到文件中的结构
type meta struct { Topics []struct { Name string `json:"name"` Paused bool `json:"paused"` Channels []struct { Name string `json:"name"` Paused bool `json:"paused"` } `json:"channels"` } `json:"topics"` }
3：启动tcp/http/https服务
nsq可以通过tcp和http通过服务，http和https提供的服务是一样，区别在于协议本身，当client通过tcp和server建立连接后，server会启动两个协程，一个用于发消息，一个用于收消息
tcp提供的服务如下：
| 服务命令 | 服务描述 |
| INENTIFY | 认证 |
| FIN | 消费完成 |
| RDY | 指定可同时处理的消息数量 |
| REQ | 消息重新加入队列 |
| PUB | 发布单条消息 |
| MPUB | 发布多条消息 |
| DPUB | 发布单条延迟消息 |
| NOP | 不做任何处理 |
| TOUCH | 重新设置消息处理超时时间 |
| SUB | 订阅，订阅后才能消费消息 |
| CLS | 关闭停止消费 |
| AUTH | 授权 |
client和server建立连接后，client通过命令INENTIFY将认证信息发给服务端，如果server在启动的时候指定了授权地址，server就会告诉client你需要认证，client就会通过命令AUTH将秘钥发给server，server去授权地址进行验证，验证通过后，就可以进行正常的消息发布和订阅了
http和https提供服务如下：
| 服务名称 |
| 发布单条/多条消息 |
| topic新增/删除/情况topic中消息/暂停/启动 |
| channel新增/删除/情况topic中消息/暂停/启动 |
| nsq状态信息 |
| ping |
| 启动参数查询和修改 |
tcp服务能发布和消费消息，http/https则只能发布消息，发布消息最后调的是同一个接口
端口信息
| 协议名称 | 默认端口 |
| tcp | 4150 |
| http | 4151 |
| https | 4152 |
心跳
心跳默认30秒，在认证（INENTIFY）的时候client可以指定心跳时间间隔，server按照心跳给client发消息，消息内容：_heartbeat_，如果发送失败，发送消息的协程就会退出，这样server就不在给client发消息了，server如果从client读消息失败，接收消息的协程就会退出，关闭和client的连接，从channel中将client移除，这样就不在收client发来的消息，server中也就没有client的任何信息了
consumer和producter连着nsqd的同一个端口，为什么consumer能消费消息，而producter却不会呢？
nsq是个基于发布和订阅的消息队列，只有订阅了才能消费消息，consumer和producter虽然连着同一个端口，consumer在建立连接后，会发送SUB命令，告诉server我要订阅，而producter并没有，consumer在发送SUB命令后还会发送RDY命令告诉server能同时处理消息的个数，当rdyCount=0时，server也不会给consumer推消息，所以SUB和RDY这两个命令缺一不可
nsq消息文件的存取
nsq可以将消息存在内存中或是文件中，存在内存的好处就是速度快，确定就是一旦进程退出消息就丢失了，所以在实战中消息都会写到磁盘文件，虽然慢点但不容易丢消息
封装消息存取文件的实现在github.com/nsqio/go-diskqueue/diskqueue.go中
topic收到消息后，可以将消息存在内存中或是文件中，当内存channel写满之后就会写入文件，当我们把channel的buffer设置成0后，所有的消息就会写文件
每个topic都会启动一个协程将其收到的消息复制给其下面的每个channel，channel在将消息推送给consumer，channel收到topic发过来（函数调用）的消息，可将消息存入内存或是文件
消息写入内存，topic下面的channel其实是共享一份数据，因为数据都是自读的，而写入文件却是每个channel都有一组文件并将消息吸入，真正做到了读时复制，每个topic和channel都会实例化一个diskQueue，其结构如下
// diskQueue implements a filesystem backed FIFO queue
//原文：https://www.cnblogs.com/hlxs/p/11445103.html 作者：啊汉
type diskQueue struct { // 64bit atomic vars need to be first for proper alignment on 32bit platforms // run-time state (also persisted to disk) readPos int64 //已经读的位置 writePos int64 //已经写的位置 readFileNum int64 //正在读的文件编号 writeFileNum int64 //正在写的文件编号 depth int64 //没有消费的消息数量 sync.RWMutex // instantiation time metadata name string // topicName 或者 topicName + ":" + channelName dataPath string //存消息文件的目录 maxBytesPerFile int64 // currently this cannot change once created minMsgSize int32 //消息最小值 maxMsgSize int32 //消息最大值 syncEvery int64 // number of writes per fsync syncTimeout time.Duration // duration of time per fsync exitFlag int32 //退出标记 needSync bool //强制将文件缓冲区的数据写入磁盘 // keeps track of the position where we have read // (but not yet sent over readChan) nextReadPos int64 //下次读的位置 nextReadFileNum int64 //下次读的文件编号 readFile *os.File //正在读的文件 writeFile *os.File //正在写的文件 reader *bufio.Reader //读缓冲区，默认4K writeBuf bytes.Buffer //写缓冲区 // exposed via ReadChan() readChan chan []byte //读channel // internal channels writeChan chan []byte //写channel writeResponseChan chan error //写结果通知 emptyChan chan int //删除所有文件channel emptyResponseChan chan error //删除通知channel exitChan chan int //退出channel exitSyncChan chan int //退出命令同步等待channel logf AppLogFunc //写日志 }
文件名命名：目录 + topicName:channelName + .diskqueue.000001.dat
func (d *diskQueue) fileName(fileNum int64) string { return fmt.Sprintf(path.Join(d.dataPath, "%s.diskqueue.%06d.dat"), d.name, fileNum) }
diskQueue在实例化的时候回初始化相关的属性，当文件大小大于指定文件的最大值时，文件编号writeFileNum就会自增1，新来的消息就会写入新的文件
按顺序读写文件，每个消息写文件的格式是：消息长度(4字节) + 消息内容，这样读消息也就很容易了，先读4字节，知道消息的长度，接着读消息内容，下一个消息也是这样读，当下一个消息读的位置大于文件的最大值时说明这个文件读完了，可以从下一个文件开始写了，
写文件是同步的，写完之后直接反馈消息是否写入成功，由于文件系统的缓存原因，系统并不是把消息马上写入磁盘，而是写入了文件的缓冲区，所以需要定时的将文件缓冲区的内容写入磁盘，nsq使用了两个策略将文件缓冲区的内容写入磁盘。两个策略同时进行
1：默认每2500条消息强制将文件缓存内容写入磁盘
2：默认每两秒强制将文件缓存内容写入磁盘
在将消息强制写入磁盘的同时，也会将队列当前状态写入另一个文件，若程序退出，下次启动后就能正常进行文件的读写，写入内容包括：
1：剩余消息数量
2：正在读的文件编号
3：读文件偏移量
4：正在写的文件编号
5：写文件偏移量
磁盘文件的删除，如果一个文件中的消息全部被消费了，那这个文件将被删除
断开重连
断开后如果不能自动重连，那就是死都不知道怎么死的，所以nsq是有断开重连功能的
server短发现断开后，不会自动重连，鬼知道你是不是主动断开，所以server发现断开了，就将client的相关信息完全删除，就像client从没有出现过
client断开后会自动重连，client分consumer和producer
consumer自动重连：consumer作为消费者就是读，所以当读失败的时候，consumer会关闭读写功能，就断开连接，当consumer收到的所有消息处理完成后，就会自动重连，注意写失败并不会自动重连
producer自动重连：producer作为生产者就是写，所以当写失败的时候，producer按照状态来决定是否重连，如果发现状态为非连接状态就连接，收到断开是不会重连的，在写失败的时候才会重连
参考资料
未完。。。
