前言

最近用了几个月的时间，一直在对EQueue做性能优化。到现在总算告一段落了，现在把一些优化的结果分享给大家。EQueue是一个分布式的消息队列，设计思路基本和阿里的RocketMQ一致，只是是用纯C#写的，这点大家应该都知道了。

之前EQueue 1.*版本，消息持久化是使用SQLServer的，之前也想做性能测试，但发现效果不理想。所以放弃了测试，转为专心对消息持久化这块进行优化。之前的持久化设计是通过Sql Bulk Copy的方式异步批量持久化消息。但是当数据库服务器和Broker本身部署在不同的服务器上时，持久化消息也会走网卡，消耗带宽，影响消息的发送和消费的TPS。而如果数据库服务器部署在Broker同一台服务器上，则因为SQLServer本身也会消耗CPU以及内存，也会影响Broker的消息发送和消费的TPS。所以，经过考虑后，最终决定狠下心来，采用终极方案来持久化消息，就是通过本地顺序写文件的方式来持久化消息。支持异步刷盘和同步刷盘两种方式。采用文件存储后，EQueue可以轻易的支持大量消息的堆积，你的硬盘有多大，就能堆积多少量的消息。

到现在为止，经过不断的测试，功能上我认为已经比较稳定了，性能也基本满足我的要求。另外，EQueue单纯的消息持久化模块（MessageStore）以及TCP通信层的性能是非常高的。MessageStore我设计时，尽量独立一些，因为我发现写文件和读文件的设计是通用的，以后可以被复用到其他项目，所以我设计时，确保持久化模块的通用性；而TCP通信层，也是也是一样，通用和高效。目前我自己写的通信层（在ECommon类库中）可以轻松把网卡压满。

关于EQueue 2.0文件持久化版本的具体设计，我下一篇文章会具体介绍，本文主要是想分享一下EQueue 2.0的性能测试结果。为大家在使用到线上环境前做架构选型给出性能方面的参考。

测试目的

测试单个EQueue Broker服务器的发送消息、消费消息的性能。

硬件环境

全部采用UCloud云主机进行测试。一台Broker，4台Client机器。Broker的配置为8核16G内存，120G的SSD硬盘，Client的配置为4核8G内存，普通硬盘。所有服务器操作系统均为Windows Server 2012。具体如下图所示：

测试场景1

1台生产者、1台消费者、1台Broker，异步刷盘，每隔100ms刷一次盘。

消息大小（字节）  发送TPS  消费TPS  发送网络吞吐量  消费网络吞吐量 Broker磁盘写入吞吐量  Broker CPU Broker内存 Producer CPU Producer内存 Consumer CPU Consumer内存

 128  56400  56400  10MB  13MB  13MB  35%  35%  30%  12%  30%  13%

 512  41000  41000  22MB  25MB  25MB  32%  35%  30%  13%  30%  13%

 1024  29000  29000  30MB  34MB  34MB  32%  35%  27%  12%  25%  13%

 2048  20000  20000  41MB  43MB  43MB  30%  35%  27%  12%  25%  13%

测试场景2

2台生产者、2台消费者、1台Broker，异步刷盘，每隔100ms刷一次盘。

消息大小（字节）  发送总TPS  消费总TPS  发送总网络吞吐量  消费总网络吞吐量 Broker磁盘写入吞吐量  Broker CPU Broker内存 Producer CPU Producer内存 Consumer CPU Consumer内存

 128  50000  50000  8.6MB  11MB  11MB  46%  35%  19%  13%  19%  13%

 512  40000  40000  21MB  24MB  24MB  48%  35%  19%  13%  19%  13%

 1024  31200  31200  32MB  35MB  35MB  47%  35%  19%  13%  19%  13%

 2048  23000  23000  48MB  51MB  51MB  45%  35%  19%  13%  19%  13%

结束语 一些说明 测试结论

从上面的测试结果可知：