Rocket MQ 系列一 - 入门

什么是消息队列

        消息队列（Message Queue）,从广义上讲是一种消息队列服务中间件，提供一套完整的信息生产、传递、消费的软件系统，如图所示：

        消息队列锁涵盖的功能远不止与队列，其本质是两个进程传递信息的一种方法。两个进程可以分布在同一台机器上，也可以分布在不同的机器上。

        众所周知，进程通信可以通过RPC（Remote Procedure Call，远程过程调用）进行，那么我们为什么要用消息队列来传递服务呢？

        下面我们以春节订火车票为例进行说明。

        春节准备买车票回家过年，我们会打开12306进行如下操作：

        1）输入车票信息，发送订票请求，输入起点，终点，发车时间等等

        2）单机预定按钮，12306APP开始转圈，与此同时全国可能会有几亿人在进行相同的操作。

        3）3s后，应用告诉你订票失败

        4）你修改车次信息，重新发送订票请求，有过了3s，订票成功。

        下面我们以一张流程图来更直观的体现以上操作：

         12306在处理上面请求逻辑时，会遇到以下挑战：

        （1）今天这个车次只售出4000张票，而实际有30万人发送了订票请求，如果逐一请求处理，那么90%以上的人都将要耗时3s来等待，怎么办？

        （2）下游有20个系统需要在订票成功后进行通知，如果逐一调，用这些系统的接口进行通知，而其中一个通知任务执行失败，那么已经通知成功的任务会怎么样？

        （3）12306APP架构会不断调整，当数据结构发生变化时，下游20个系统都随着一起变化吗？

        以上只是随机列举了一些常见问题，如何才能优雅地处理呢？

        答案是：消息队列！

为什么需要消息队列

削峰填谷

        业务系统在超高并发场景中，由于后端服务来不及同步处理过多，过快的请求，可能导致请求堵塞，严重时可能由于高负荷拖垮Web服务器。

        我们都希望流量像直线一样一直比较平稳，这样我们的系统也会更加稳定，但是实际的流量会随着时间不短变化，像12306这样的APP流量大的难以想象，而一年中不同的时间段，其流量也不同，为了能支持最高峰流量，我们通常才去短平快的方式--直接扩容服务器，增加服务端的吞吐量。

        优点是显而易见的，短时间内吞吐量增加了好几倍，甚至数十倍。缺点也十分明显，流量低峰期服务器相对较闲。

        如何平衡平时的空闲与节假日的超高峰呢？我们想到消息对列（Apache RocketMQ,Apache Kafka），也是目前业界比较常用的手段。利用消息队列扭转处理订票请求，告知用户30min内会告诉他订票结果。优缺点明显：性能提升了，但是我们作为业务开发人员，还要维护一个消息队列服务，人手完全不够。消息中间件呼之欲出。

程序间解耦

        不同的业务端在联合开发功能时，常常由于排期不同、人员调配不方便等原因导致项目延期。其实，根本原因是业务耦合过度。

        加入消息队列后，不同的业务端之间开发，联调，上线彼此完全不依赖，也就是说系统解耦了。

异步处理

        处理订票请求是一个漫长的过程，需要检查预定的车次是否有预定数量的票，下单扣库存，更新缓存等一系列操作。这些耗时的操作，我们可以通过使用消息队列的方式，把提交请求成功的消息告诉用户。然后异步处理这些耗时的操作，保证30min内能把处理的结果通过短信推送给用户，否则系统处理多久，用户就会等多久。

数据的最终一致性

        我们通过银行转账的案例来进行说明：

        如果通信失败，如何保证转账成功呢，常用的手段就是消息队列。消息系统的优点：

        （1）免去了用户A多次重试的复杂逻辑

        （2）免去了用户B处理多次重试请求的压力

        （3）即时用户B的服务不可用，业务也不受影响

常见的消息队列

消息队列名字	Apache ActiveMQ	Apache Kafka	Apache RocketMQ	Apache Pulsar
产生时间	2007	2012	2017	2018
贡献公司	Apache	LinkedIn	alibaba	yahoo
当时流行MQ	JMS	ActiveMQ	Kafka, ActiveMQ	RocketMQ, Kafka
特性	(1) 支持协议众多:AMQP,STOMP,MQTT,JMS (2) 消息是持久化的JDBC	（1）超高写入速率 （2）end-to-end 耗时毫秒级	（1）亿万级消息支持 （2）万级TOPIC数量支持 （3）end-to-end耗时毫秒级	（1）存储计算分离 （2）支持SQL数据查询
管理后台	自带	独立部署	独立部署	无
多语言客户端	支持	支持	Java C++ Python Go c#	Java C++ Python Go
数据流支持	不支持	支持	支持	支持
消息丢失	理论上不会丢失	理论上不会丢失	理论上不会丢失	理论上不会丢失
文档完备性	好	极好	极好	社区不断完善中
商业公司实践	国内部分企业	LinkedIn	alibaba	yahoo,tencet,zhilian
容错	无重试机制	无重试机制	支持重试，死信消息	支持重试，死信消息
顺序消息	支持	支持	支持	支持
定时消息	不支持	不支持	支持	支持
事务消息	不支持	支持	支持	支持
消息轨迹	不支持	不支持	支持	自己简单实现
消息查询	数据库查询	不支持	支持	支持SQL
重放消息	不清楚	暂停重放	实时重放	支持
宕机	自动切换	自动选主	手动重启	自动切换