RocketMQ 5，linux驱动开发入门与实战第二版pdf

RocketMQ 从设计之初就立足于在线交易链路，因此主要应用在大型在线系统的异步化处理。

历经十年发展，目前的大规模落地场景有：电商物流的交易系统、在线教育课程系统、大型游戏信令系统、以及银行交易系统，这些都大量使用了 RocketMQ 来做异步解耦和削峰填谷；同时在非在线业务的场景里，大量车联网、电商网站基于 RocketMQ 实现 IoT 边缘数据以及 C 端用户行为数据采集传输和集成。

开源至今，RocketMQ 的核心架构大约经历了四个重要的演进阶段：

第一代 RocketMQ 其实是采用了推模式，数据存储采用关系型数据库。在这种模式下消息具有很低的延迟特性，并且很容易支持分布式事务。在阿里淘宝这种高频交易场景中，具有非常广泛的应用。

第二代 RocketMQ 在服务于交易场景基础上开始探索自研存储引擎，这个版本采用了拉模式和自研的专有消息存储，在日志处理方面能够媲美 Kafka 的吞吐性能。

在前两代初步打磨了自研的存储引擎后， RocketMQ 3.0 的重构前瞻性地去除了 ZooKeeper 等组件的外部依赖，并支持了单机海量 Topic。而刚好在前不久，我们也报道过消息系统 Kafka 去除 ZooKeeper 依赖。

第四代 RocketMQ 在高可靠低延迟方面重点优化，构建了全新的低延迟存储引擎、新增了 Raft 多副本存储能力、提供了丰富的消息特性。

RocketMQ 架构演进的思考

目前社区开发者对 RocketMQ 的诉求来自于三个方面：首先，RocketMQ 如何更方便地与云原生生态整合是开发者最为关心的问题；其次，在流计算场景里，社区对 RocketMQ 的吞吐能力提出了更高的要求，企业客户也一直希望就近处理流转在 RocketMQ 系统中的如支付、交易等高价值的业务数据；还有一类则是在企业集成过程中，希望 RocketMQ 能提供更多 connector 帮助用户构建企业数据流转中心。

伴随如今企业全面上云以及云原生的兴起，新一代基础架构必须朝着云原生化演进，RocketMQ 在 5.0 里面提供了可分可合的存储计算分离架构以顺应这一趋势。

通过可分可合的存储计算分离架构，用户可以同一进程启动存储和计算的功能，也可以将两者分开部署。分开部署后的计算节点可以做到“无状态”，一个接入点可代理所有流量，在云上结合新硬件内核旁路技术，可以降低分离部署带来的性能及延迟问题。而选择“存储计算