Disque--Redis作者新开发的消息队列

　　今天Redis的作者Salvatore Sanfilippo(网名Antirez)发表了一篇新博客文章，他详细介绍了自己几个月以来在晚上与周末开发的新项目——Disque。今年1月份Antirez曾经在邮件列表中透露过这个项目，现在看来Disque已经离正式发布不远了。

　　Disque是一个分布式的消息队列。与Redis和mysql有单结点与分布式模式不同，单一Disque结点也是只有一个结点的集群。它是一个AP系统，也就是说具有可用性与分区容错性。此外它能在各种情形下保持高扩展性：无不管是多生产者与多消费者处理多队列，还是所有生产者与消费者都在一个队列。

　　此外，Disque的设计中有一点重大牺牲，就是只尽力提供而不保证消息的排序。

　　Antirez还通过回答Adrian Colyer(AspectJ的作者，曾任SpringSource CTO，后来有人指出，Antirez记错了，这些问题是Jacques Chester提出的)在Hacker News上某次讨论中所提问题的方式，详细地描述了Disque的特性：

1. 　　消息发送可以选择至少一次或者最多一次。
2. 　　消息需要消费者确认。
3. 　　如果没有确认，会一直重发，直至到期。确认信息会广播给拥有消息副本的所有结点，然后消息会被垃圾收集或者删除。
4. 　　队列是持久的。
5. 　　Disque默认只运行在内存里，持久性是通过同步备份实现的。
6. 　　队列为了保证最大吞吐量，不是全局一致的，但会尽力提供排序。
7. 　　在压力大的时候，消息不会丢弃，但会拒绝新的消息。
8. 　　消费者和生产者可以通过命令查看队列中的消息。
9. 　　队列尽力提供FIFO。
10. 　　一组master作为中介，客户端可以与任一结点通信。
11. 　　中介有命名的队列，无需消费者和生产者干预。
12. 　　消息发送是事务性的，保证集群中会有所需数量的副本。
13. 　　消息接收不是事务性的。
14. 　　消费者默认是接收时是阻塞的，但也可以选择查看新消息。
15. 　　生产者在队列满时发新消息可以得到错误信息，也可以让集群异步地复制消息。
16. 　　支持延迟作业，粒度是秒，最久可以长达数年。但需要消耗内存。
17. 　　消费者和生产者可以连接不同的结点。

　　1.Disque开发初衷

　　当初Antirez之所以动念开发Disque，是由于看到很多人用Redis和mysql来处理队列，但是这样做的优势与劣势都很明显：虽然Redis很快、易用而且很多基础设施里已经在用，但是Redis的高可用性或者集群特性的设计完全偏向可变数据结构，这与不可变的消息非常不同，并不是最佳的方案。

　　消息中介重要的功能是保证至少一次或最多一次发送消息，而且保证至少一次更重要。Antirez开始想通过少量修改Redis来实现，但是几天后发现客户端算法太复杂了。Redis目前已经有很多功能，再增加功能并不是什么好主意。何况消息队列的运作方式和Redis很不同。

　　所以，是不是可以新开发一个消息队列呢?

　　目前市场上已经有很多消息队列了，新做一个有价值吗?Antirez想，既然有这么多人用Redis来处理消息队列，已有的方案看上去要么太简单要么太复杂，其中必有机会，所以他动手开发了。

　　2.开发过程

　　这是他第一次没有直接上来就写代码，他花了几个星期思考设计，尝试者从用户角度来理解：什么样的消息队列会让人更爽？主要的使用场景没变：延迟作业。Disque是通用系统，但是主要针对的问题，是发送可能要处理的作业的消息。若有什么违背了这一场景，就会不通过。

　　现在设计有了，Antirez就直接从Redis代码入手。幸运的是Redis的一部分就是编写C分布式系统的一个框架。现在，协议、网络库、客户端处理、结点到结点的消息总线已经有了，不需要重头再写。但是他又不想影响Redis本身，于是采取了一个比较实际的办法：开一个Redis分支，然后将Redis专用的东西全部删掉，只剩一个框架，再开始团的设计。

　　目前为止，他已经完成了80%左右的工作，还剩下AOF硬盘持久性没做，另外还需要对API做一些改善。

　　让我们期待他尽快给出代码吧。

　　Hacker News上Parse.ly的CTO Andrew Montalenti(@pixelmonkey )将Disque和Kafka做了比较，如下所示：

• 　　设计上AP和部分排序都很类似。但Disque会在发送完成后垃圾收集数据，
•     Kafka在SLA/TTL中保持所有消息，允许重新处理。
•     Disque在服务器端处理最多一次，而Kafka是由客户端处理的。

　　Blekko的工程副总Chuck Mcmanis(@ChuckMcM)也给出了自己的经验：

　　开发这样的系统，我的建议是：永远不要依赖时间，总是假设至少一次，而且开发内置的错误检查与更正机制，这样在消息协议里有两个或者多个不变量违反时，能够从消息流中计算出正确结果。