为什么会诞生RocketMq这个产品： 在阿里使用消息平台的产品过程中，随着业务的快速发展，需要增加对队列和topic的使用，ActiveMQ的IO能力很快达到了瓶颈，虽然尝试了节流、熔断或降级的方案来降低IO的影响，但是收效甚微。为此使用KAFKA进行替换，但是在低延迟和高可靠性方面有所欠缺，为此提出了新的消息平台产品---RocketMQ来处理爆炸性的消息事件，同时支持传统的 消费/订阅场景 以提升产品的适用性。
首先介绍下mq的发展历程： mq的发展经历过多轮版本迭代，尤其到了大数据时代有了明显的变更。 以传统的以broker作为核心的mq---rabbitMq为例进行说明。mq_client将消息发给mq_server后，server会将对应的msg存储在broker中，通过exchange将msg投递给不同的queue，consumer通过订阅queue完成对msg的消费，完成了整个消息平台的事件闭环。其中broker可以根据不同的规则对msg进行过滤，当broker挂了后还可以通过备broker进行queue的继续写入。
这个架构在平时使用中非常方便，producer负责生产消息，consumer负责消费，通用逻辑在broker中实现，但是随着业务的发展，有些问题的出现不可避免 1.此类mq只能保证单broker+单consumer+不自动写入dead_msg_q的消息顺序 2.一个msg要被多个人消费需要建立多个queue，需要对消息进行复制存储，消耗更大，吞吐也受影响 3.不支持msg在queue中的重放
而在大数据场景下，当前服务是无法满足业务的，为此出现了以kafka为首的日志式消息平台。其中也有broker的概念，但是其中已经没有exchange的概念，不需要投递，主要是为了做日志的添加和存储（传统mq一般选用某种db将消息进行存储）。而每个consumer通过维护读取同一日志文件的offset来进行msg读取， 并且日志内容也不会在offset进行更新后立刻删除，可以进行消息的重放。其中offset维护在topic中，存储在zk中（在后期zk被剥离后存储在对应的meta信息中），这样在partition中任意单个consumer就实现了顺序消费。
传统MQ只负责转发和被消费前临时存储，而Kafka进行了对应的数据长久存储，解决了数据高可用的问题，实现了类似于文件系统的功能。
