比较新的消息队列 server， NATS 和 disque 的对比。
仅插入
disque
| Amount并发 | 100 | 500 | 1000 | 2000 | 4000 |
|---|---|---|---|---|---|
| 10w | 3568.814ms | 1910.550ms | 2322.112ms | 2577.898ms | 2780.189ms |
| 100w | 32951.437ms | 19610.882ms | 20488.052ms | 21875.545ms | 26354.094ms |
NATS
| Amount并发 | 100 | 500 | 1000 | 2000 | 4000 |
|---|---|---|---|---|---|
| 10w | 4486.236ms | 4162.363ms | 4330.767ms | 4458.188ms | 4987.342ms |
| 100w | 40481.896ms | 41818.800ms | 41704.926ms | 45198.646ms | 46906.605ms |
双方的插入都在 500 的并发时表现还行，所以后面的测试用这个并发量来插入。
同时插入并读取
测试情况：
插入节点 : Server 节点: 读取节点 = 1: 1: N
disque
10w 级
| 2327.073ms | 11085.363ms |
| 3970.004ms | 8064.683ms/8097.301ms |
| 7637.522ms | 8798.931ms/8804.586ms/8820.094ms/8986.903ms |
100w 级
| 33974.781ms | 128753.262ms |
| 44862.931ms | 90111.012ms/90975.795ms |
| 67741.766ms | 75597.516ms/75983.190ms/76229.671ms/76412.002ms |
NATS
10w 级
| 6292.183ms | 6268.520ms |
| 6172.031ms | 3673.333ms/3673.315ms |
| 6127.849ms | 2332.848ms/2332.729ms/2338.836ms/2339.670ms |
100w 级
| 55505.581ms | 55473.022ms |
| 54234.438ms | 29926.494ms/29926.681ms |
| 52572.856ms | 16027.231ms/16027.502ms/16025.114ms/16015.165ms |
根据数据可以简单看出来， C语言编写的 disque 在纯插入的时候速度确实会快一些。然而到了同时插入并读取的时候， disque 的读取速度就慢了很多，可以看出来 1对多个客户端让 disque 在调度上产生了不小的消耗，而且读取的速度确实也比较慢。
而 NATS 就比较让人惊喜了，大概是因为异步式的架构，让 NATS 可以不关心插入的确认而是更注重调度和转发，所以让 NATS 的队列读取速度非常快，在跑测试的可以明显的感觉到，在 1:1:4 的时候 NATS 的流程分为 ①插入过程 ②clients读取 ③确认，NATS 的这种架构方式让流程②变得非常迅速。
使用这两个消息队列虽然不会内存泄漏，不过 disque 上限是 1779155，按照博主本机的测试数据看插入的快读取的慢随着时间推移总是有塞满的风险。disque 这种情况大概是因为设计的是安全队列的原因，安全队列类似 Linux 信号中的后 32 个用户自定义信号，不会因为当时没收到就丢失。而 NATS 的队列则属于不安全的队列，如果当时没收到也不会保留该消息，所以 NATS 比较起来塞满的风险更低。
测试环境：
macbook pro CPU: 2.7 GHz Intel Core i5 MEM: 8 GB 1867 MHz DDR3
测试代码：
node-gnats/req.js
node-gnats/get.js
thunk-disque/req.js
thunk-disque/get.js
PS:
1) 博主这里只测了 1:1:N，没有测 N:1:M 和 N:L:M。
2) 一些比较高级的特性没有开启测试。
如果这些没关注到的这些地方有反转、文中有问题或者有更好的客户端推荐还请评论告知（或者电邮博主 [email protected]）。
Lellansin's 冰森 