为什么使用消息队列MQ
从实习到后来的两份工作也写了不少的项目，在最近的一份工作用到了大量的消息队列（客服系统，会有大量的访客咨询消息），让我重新回顾了一下在大数据面前，为什么要用消息队列，怎么用好消息队列
理由
- 解耦
- 异步
- 削峰
解耦
通过一个 MQ，Pub/Sub 发布订阅消息这么一个模型，不同微服务之间通信会更加解耦，A给BCDEF发送消息的时候，就不需要考虑他们是否宕机，如何重发等，只需要将信息发送到队列里，让他们自己去取就好了
异步
假设用户请求需要写表，那么吧任务放进队列里，等待写入，前端可以先返回，可以减少用户的等待时间，或者采用多个机器同时写数据的不同部分，加快数据的处理
削峰
就和平时用电一样，晚上电网的压力肯定会很大，如果直接把大量请求压到服务器，会直接宕机，但如果把请求排成队列，然后服务器从里面顺序取，虽然会增加延迟，但是不会宕机，满负荷运作而已
实际生产环境
咨询系统大致分为：咨询核心，端模块，微信模块，分配模块等等，访客发送的咨询信息（web）可能先经过端模块，在咨询核心模块处理前进入队列，然后，分配模块根据用户的设置，如接入客服还是机器人，按什么权重进行分配，分配给哪一个业务组进行操作，来减轻咨询核心的压力
缺点
1.系统可用性降低（MQ挂了咋整）
2.复杂度提升（消息没有重复消费，不会丢失）
3.一致性问题有待解决
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 单机吞吐量 | 万级，比 RocketMQ、Kafka 低一个数量级 | 同 ActiveMQ | 10 万级，支撑高吞吐 | 10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景 |
| topic 数量对吞吐量的影响 | topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic | topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源 | ||
| 时效性 | ms 级 | 微秒级，这是 RabbitMQ 的一大特点，延迟最低 | ms 级 | 延迟在 ms 级以内 |
| 可用性 | 高，基于主从架构实现高可用 | 同 ActiveMQ | 非常高，分布式架构 | 非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 |
| 消息可靠性 | 有较低的概率丢失数据 | 基本不丢 | 经过参数优化配置，可以做到 0 丢失 | 同 RocketMQ |
| 功能支持 | MQ 领域的功能极其完备 | 基于 erlang 开发，并发能力很强，性能极好，延时很低 | MQ 功能较为完善，还是分布式的，扩展性好 | 功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用 |
所以中小型公司，用 RabbitMQ 是不错的选择
大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择
如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。