趁着年轻

Redis stream支持多个消费者在同一个group里面消费，并且一条消息只会发送给一个消费者，不会被同组内的多个consumer获取。但有些特殊情况也不得不注意。

阅读全文...

上面的文章整体介绍了stream 实现方式，以及xadd生产端的流程，接下来继续写一下后面消费端的过程。
redis stream的消费方法有几种， XREAD、XREADGROUP， 还有xrange/xrevrange， 后者比较简单，主要就是准备参数然后调用streamReplyWithRange 来根据范围读取消息内容。
阅读全文...

kafka在日志处理领域由于其一系列的工具，其他相关服务，基本上算得上是王者，但是缺点也很明显： 难以维护，性能低，需要大量机器，部署复杂，参数众多。
前阵子Redis 5.0 Beta版本发布 ， 随之而来的重大特性“Introduction to Redis Streams”， 似乎跟kafka在功能上有很多类似的地方，但也有不少不一样的点。
阅读全文...

这里记录一下消息的消费者订阅流程，配合上面文章写的消息发送流程。不过这里暂时没讲lookupd的过程，后面在详细介绍。

1. 消费者使用TCP协议，发送SUB topic channel 命令订阅到某个channel上，记录其client.Channel = channel，通知c.SubEventChan；
2. 消费者启动后台协程protocolV2.messagePump订阅c.SubEventChan 并得知channel有订阅消息；
3. 开始订阅管道subChannel.memoryMsgChan/backend， 每个客户端都可以订阅到channel的内存或者磁盘队列里面;
4. 待生产者调用第四步后，其中一个client会得到消息：msg := <-memoryMsgChan;
5. 客户端记录StartInFlightTimeout的发送中消息队列，进行超时处理；
6. SendMessage 将消息+msgid发送给消费者；
7. 消费者收到msgid后，发送FIN+msgid通知服务器成功投递消息，可以清空消息了；

阅读全文...

本文从消息发送者的PUB到最后消息被SUB接收，整个流程串起来讲一下nsqd是怎么接收消息的，这部分先写发送流程。

1. 生产者PUB topic消息；
2. topic.PutMessage 到 topic.memoryMsgChan；
3. 每topic消息有后台协程topic.messagePump进行Topic.memoryMsgChan监听；
4. topic.messagePump 遍历每个channel调用channel.PutMessage发送消息到channel.memoryMsgChan ;

阅读全文...

写一下Channel的实现，比topic相对简单一些，但channel是最接近消费者端的，有他特有的东西，包括投递，确认等；
nsqd的channel的作用在于能对指定的队列topic，进行多份投递，或者说消费，一份队列可以给多个消费者重复消费，有点类似于kafka的consumer_group，每个consumer_group拥有独立的position， 不同group之间可以消费同一份内容的多个副本。
这里稍微做个对比，kafka的已经消费国的消息是可以继续保留的，而nsq则如果消费完了，就会删除掉，也就是没有position可以供回溯，或者重复消费，只要客户端发发送FIN后，消息就会销毁，也不会保留在磁盘上面，这点比kafka简单多了，当然，轻量级消息队列也不太需要这么复杂的功能。

阅读全文...

这回记录一下nsqd的topic是怎么实现的。先以官网一张著名的动图开始， 下面这图介绍了发送一条消息到一个topic上的流程：

阅读全文...