。

    中间件 kafka RabbitMQ RocketMQ nsq
    有序性
    - 保证partition有序
    - 要被顺序消费的消息，必须都放到一个partition里面
    - partition只能被消费者组里的一个消费者实例消费
    		 Nsq不支持顺序消费

    如果要支持有序的话
    1. 整改nsq，像kafka一样
    1.

    | | | 消息投递 | 而Kafka则支持准确一次 | | | | | | | 采用pull方式拉消息：

    - 优点：消费者可以自己把握节奏
    - 缺点：
    - 延时大
    - 消费者可能经常有空pull，即pull不到消息，造成浪费
    - 解决思路：Kafka采用的是阻塞式pull
    | | | 采用push方式推消息

    - 优点：延时小，几乎可以做到实时
    - 缺点：消费者端不好做流控 很难做批量推送，不知道要推送多少合适
    - 解决思路：参考MQ（3）—— 刨根问底里头讲的nsq的流控策略
    | | | 缺点 | 1. 它的同步收发消息的响应时延比较高，因为当客户端发送一条消息的时候，Kafka 并不会立即发送出去，而是要等一会儿攒一批再发送，在它的 Broker 中，很多地方都会使用这种“先攒一波再一起处理”的设计。当你的业务场景中，每秒钟消息数量没有那么多的时候，Kafka 的时延反而会比较高。所以，Kafka 不太适合在线业务场景。 |
    1. RabbitMQ 对消息堆积的支持并不好，在它的设计理念里面，消息队列是一个管道，大量的消息积压是一种不正常的情况，应当尽量去避免。当大量消息积压的时候，会导致 RabbitMQ 的性能急剧下降。
    1. RabbitMQ 的性能较差，根据官方给出的测试数据综合我们日常使用的经验，依据硬件配置的不同，它大概每秒钟可以处理几万到十几万条消息。其实，这个性能也足够支撑绝大多数的应用场景了，不过，如果你的应用对消息队列的性能要求非常高，那不要选择 RabbitMQ。
    | | | | | 优点 | | |
    1. RocketMQ 的性能比 RabbitMQ 要高一个数量级，每秒钟大概能处理几十万条消息。
    1. RocketMQ 对在线业务的响应时延做了很多的优化，大多数情况下可以做到毫秒级的响应

    | | |

    发布 - 订阅模型
    **
    image.png

    消息的发送方称为发布者（Publisher），消息的接收方称为订阅者（Subscriber），服务端存放消息的容器称为主题（Topic）。发布者将消息发送到主题中，订阅者在接收消息之前需要先“订阅主题”。“订阅”在这里既是一个动作，同时还可以认为是主题在消费时的一个逻辑副本，每份订阅中，订阅者都可以接收到主题的所有消息。

    RabbitMQ 的消息模型
    **
    image.png

    同一份消息如果需要被多个消费者来消费，需要配置 Exchange 将消息发送到多个队列，每个队列中都存放一份完整的消息数据，可以为一个消费者提供消费服务。这也可以变相地实现新发布 - 订阅模型中，“一份消息数据可以被多个订阅者来多次消费”这样的功能。

    RocketMQ

    image.png