消息队列

MQ相关概念

MQ

MQ(message queue)，本质是个队列存放的内容是message ，还是一种跨进程的通信机制，用于上下游传递消息。在互联网架构中，MQ 是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。使用了 MQ 之后，消息发送上游只需要依赖 MQ，不用依赖其他服务

使用消息队列的原因

• 流量消峰

  例如在高并发场景下可以使用消息队列做缓冲，把一些请求分散成一段时间处理

• 应用解耦

  当一个系统出现故障时，该系统要处理的内存会被缓存在消息队列中，其他的系统操作会正常进行，当该系统恢复后再进行处理

• 异步处理

  例如两个进程A和B，A需要调用B，B需要花很长时间进行，但是A需要知道B什么时候可以执行完。当处理这个问题时，使用消息队列时，在B处理完成后会发送一条消息给mq，mq再转发消息给A

消息的分类

• ActiveMQ

  优点：单机吞吐量万级，时效性 ms级，可用性高，基于主从架构实现高可用性，消息可靠性较低的概率丢失数据

  缺点：官方社区现在对 ActiveMQ 5.x 维护越来越少，高吞吐量场景较少使用

• Kafka

  优点：性能卓越，单机写入 TPS 约在百万条/秒，吞吐量高。时效性ms级，可用性非常高，kafka 是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用,消费者采用 Pull 方式获取消息, 消息有序, 通过控制能够保证所有消息被消费且仅被消费一次。有优秀的第三方KafkaWeb 管理界面 Kafka-Manager。在日志领域比较成熟，被多家公司和多个开源项目使用。功能支持： 功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用

  缺点：Kafka 单机超过 64 个队列/分区，Load 会发生明显的飙高现象，队列越多，load 越高，发送消息响应时间变长，使用短轮询方式，实时性取决于轮询间隔时间，消费失败不支持重试。支持消息顺序，但是一台代理宕机后，就会产生消息乱序，社区更新较慢

• RocketMQ

  优点：单机吞吐量十万级,可用性非常高，分布式架构，消息可以做到 0 丢失，MQ 功能较为完善，分布式的，扩展性好，支持 10 亿级别的消息堆积，不会因为堆积导致性能下降

  缺点：支持的客户端语言不多，目前是 java 及 c++，其中 c++不成熟；没有在MQ核心中去实现 JMS 等接口，有些系统要迁移需要修改大量代码

• BMQ

和Pulsar架构类似，存算分离，初期定位是承接高吞吐量的离线业务场景，逐步替换掉对应的Kafka集群