异数OS 织梦师-水母（一）--消息队列篇

异数OS 织梦师-水母（一）–消息队列篇

---

本文来自异数OS社区

github： https://github.com/yds086/HereticOS

异数OS社区QQ群： 652455784

异数OS-织梦师（消息中间件）群： 476260389

织梦师-水母 消息队列简介

---

这是一个使用异数OS技术实做的轻量级的消息中间件，和他的名字一样，重在表演，他不是一个功能复杂齐全的消息队列，使用者需要根据自己需求按照水母的原理去制作自己的超级武器，整个框架，协议，测试等代码算下来仅仅1000行，但已经是一个比较完整可用的消息队列了（topic没做，由nameserver去做吧），持久化方便测试使用虚完成，下一阶段会接入织梦师-水桶 RAM网盘存储方案，由于性能足够，单Broker相当于10-100台传统的消息队列，所以也不需要特意去制作集群方案，简单即优美，简单即可用，织梦师-水母作为异数OS的example放在git test目录下

与众不同的特性

---

1.生产者惰性QOS控制，在开启该特性后，生产者线程在队列满载后会被阻塞挂起，在队列可用时恢复并尝试重新入队，此特性在队列压力较大时可大大降低错误重试的网络IO需求，大大增加队列高负载时的可用性

2.低延迟低队列深度可用，织梦师-水母的延迟极低，内网生产者入队仅需10us延迟（82599），队列无压力时到消费者延迟20us，因此只要消费者满足需要，一般队列深度128即可稳定工作（异数OS系产品本身并不需要消息队列做削峰填谷，这是给老旧落后的产品做的）

3.海量生产者特性，每Broker最大可接入1000W链接生产者（阻塞IO线程），因此有望直接在公网接受用户生产者检验，而不需要系统前端加LVS或者Nginx分流出多生产者。

4.高性能的消息队列，dpdk 82599双口 单CPU核环境，128生产者下，非批量消息，最大入队峰值4M每秒，到消费者最大2M峰值，批量则再根据批量规模和带宽来计算放大倍率，1200W链接最大160W消息入队，到消费者最大80W，后面会支持RSS 单Broker多队列聚合，成倍扩充单broker性能。

架构说明

---

织梦师-水母使用阻塞线程模型，因此相比异步IO的架构，结构非常简单轻量稳定可靠，代码和框架是对生产者，消费者模型的高度对应，你看到的框架图就是代码。

测试说明

---

CPU1 作为日志监控核，CPU3作为经纪人Broker,CPU5创建生产者消费者，成绩为10字节10个消息批量模式，批量仅供参考。
日志中参数可自己查阅git中代码做分析参考。

测试成绩

---

异数OS虚拟交换机下，128生产者，128消费者

异数OS虚拟交换机下，600W生产者，128消费者

异数OS DPDK双口交换，128生产者，128消费者

异数OS DPDK双口交换，600W生产者，128消费者

相关产品性能对比

---

以下成绩都是1 Borker下得到的性能,其他产品数据来自网络的大概参考数据。

非批量消息模式

测试特性	异数OS虚拟交换机128生产者	异数OS虚拟交换机600W生产者	异数OS-DPDK 128生产者	异数OS-DPDK 600W生产者	kafka	RocketMQ
仅入队性能	4M	2M	3.3M	160W	12w	12w
入队出队性能	2M	1M	1.6M	80W	6w	6w
仅入队延迟	<1us	<1us	10us	10us	10ms	10ms
入队到出队延迟	<1us	<1us	20us	20us	10ms	10ms

批量消息模式

10字节消息批量入队出队，织梦师-水母测试用批量规模为10个消息批量

测试特性	异数OS虚拟交换机128生产者	异数OS虚拟交换机600W生产者	异数OS-DPDK 128生产者	异数OS-DPDK 600W生产者	kafka	RocketMQ
仅入队性能	40M	20M	33M	1600W	200w	12w（不支持批量）
入队出队性能	20M	10M	16M	800W	100w	6w
仅入队延迟	<1us	<1us	10us	10us	10ms	10ms
入队到出队延迟	<1us	<1us	20us	20us	10ms	10ms

研发吐槽

RSS方案已经可以正常使用，双核ECHO 8M IO的样子，DPDK在异数OS负优化下，在海量链接环境中，终于不丢包，但代价是惨烈的，相对netmap方案，性能损失30%，实践推测这是由于DPDK polling在需要访存延迟较高的情况下，网卡无法利用mbuf进行数据传输，因此你开再多的mbuf都不济于事，而netmap由于使用驱动的硬件中断，因此即便不polling，网卡中断也能完成和netmap ring的数据传输，所以netmap的polling实际上反而更高效，有削峰填谷作用，为了拯救DPDK polling导致的网卡饥饿，异数OS做了更加细粒度的任务调度，并为DPDK网卡驱动做了ns精度级别的任务调度，动态控制DPDK tx发包规模，从而实现了600W（1200W）链接的0丢包。