关于MQ的几件小事（一）消息队列的用途、优缺点、技术选型
1.为什么使用消息队列？
（1）解耦：可以在多个系统之间进行解耦，将原本通过网络之间的调用的方式改为使用MQ进行消息的异步通讯，只要该操作不是需要同步的，就可以改为使用MQ进行不同系统之间的联系，这样项目之间不会存在耦合，系统之间不会产生太大的影响，就算一个系统挂了，也只是消息挤压在MQ里面没人进行消费而已，不会对其他的系统产生影响。
（2）异步：加入一个操作设计到好几个步骤，这些步骤之间不需要同步完成，比如客户去创建了一个订单，还要去客户轨迹系统添加一条轨迹、去库存系统更新库存、去客户系统修改客户的状态等等。这样如果这个系统都直接进行调用，那么将会产生大量的时间，这样对于客户是无法接收的；并且像添加客户轨迹这种操作是不需要去同步操作的，如果使用MQ将客户创建订单时，将后面的轨迹、库存、状态等信息的更新全都放到MQ里面然后去异步操作，这样就可加快系统的访问速度，提供更好的客户体验。
（3）削峰：一个系统访问流量有高峰时期，也有低峰时期，比如说，中午整点有一个抢购活动等等。比如系统平时流量并不高，一秒钟只有100多个并发请求，系统处理没有任何压力，一切风平浪静，到了某个抢购活动时间，系统并发访问了剧增，比如达到了每秒5000个并发请求，而我们的系统每秒只能处理2000个请求，那么由于流量太大，我们的系统、数据库可能就会崩溃。这时如果使用MQ进行流量削峰，将用户的大量消息直接放到MQ里面，然后我们的系统去按自己的最大消费能力去消费这些消息，就可以保证系统的稳定，只是可能要跟进业务逻辑，给用户返回特定页面或者稍后通过其他方式通知其结果。
2.消息队列有什么优点和缺点？
优点：1、对结构复杂、设计系统多的操作进行解耦操作，降低系统的操作复杂度、降低系统的维护成本。
2、对一个可以进行异步操作的一些系统操作进行异步，减小操作的响应时间，提供更好的用户体验。
3、可对高流量进行削峰，保证系统的平稳运行。
缺点：1、系统可用性降低。比如在系统中引入MQ，那么万一MQ挂了怎么办呢？一般而言，引入的外部依赖越多，系统越
脆弱，每一个依赖出问题都会导致整个系统的崩溃。
2、系统复杂度提高。需要考虑MQ的各种情况，比如：消息的重复消费、消息丢失、保证消费顺序等等......
3、数据一致性问题。比如A系统已经给客户返回操作成功，这时候操作BC都成功了，操作D却失败了，导致数据不
一致。
3.kafka、activemq、rabbitmq、rocketmq都有什么优点和缺点啊？
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | kafka |
|---|---|---|---|---|
| 单机吞吐量 | 万级，吞吐量比RocketMQ和kafka要低一个数量级 | 万级，吞吐量比RocketMQ和kafka要低一个数量级 | 10万级，RocketMQ也是可以支撑高吞吐的一种MQ | 10万级别，kafka最大优点就是吞吐量大，一般配合大数据类的系统来进行实时数据计算、日志采集等场景。 |
| topic数量对吞吐量的影响 | topic可以达到几百、几千个的级别，吞吐量会有小幅度的下降。这是RocketMQ的一大优势，可在同等数量机器下支撑大量的topic | topic从几十个到几百个的时候，吞吐量会大幅下降。所以在同等机器数量下，kafka尽量保证topic数量不要过多。如果支撑大规模topic需要增加更多的机器 | ||
| 时效性 | ms级 | 微秒级，这是rabbitmq的一大特点，延迟是最低的 | ms级 | 延迟在ms级以内 |
| 可用性 | 高，基于主从架构实现可用性 | 高，基于主从架构实现可用性 | 非常高，分布式架构 | 非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 |
| 消息可靠性 | 有较低的概率丢失数据 | 经过参数优化配置，可以做到0丢失 | 经过参数配置，消息可以做到零丢失 | |
| 功能支持 | MQ领域的功能及其完备 | 基于erlang开发，所以并发性能极强，性能极好，延时低 | MQ功能较为完备，分布式扩展性好 | 功能较为简单，主要支持加单MQ功能 |
| 优势 | 非常成熟，功能强大，在业内大量公司和项目中都有应用 | erlang语言开发，性能极好、延时很低，吞吐量万级、MQ功能完备，管理界面非常好，社区活跃；互联网公司使用较多 | 接口简单易用，阿里出品有保障，吞吐量大，分布式扩展方便、社区比较活跃，支持大规模的topic、支持复杂的业务场景，可以基于源码进行定制开发 | 超高吞吐量，ms级的时延，极高的可用性和可靠性，分布式扩展方便 |
| 劣势 | 偶尔有较低概率丢失消息，社区活跃度不高 | 吞吐量较低，erlang语音开发不容易进行定制开发，集群动态扩展麻烦 | 接口不是按照标准JMS规范走的，有的系统迁移要修改大量的代码，技术有被抛弃的风险 | 有可能进行消息的重复消费 |
| 应用 | 主要用于解耦和异步，较少用在大规模吞吐的场景中 | 都有使用 | 用于大规模吞吐、复杂业务中 | 在大数据的实时计算和日志采集中被大规模使用，是业界的标准 |
综上所述，总结如下：
一般业务系统要引入MQ，最早大家都用ActiveMQ，但现在用的不多了。没有经过大规模吞吐场景的验证，社区也不活跃，不推荐再使用。
后来大家开始用rabbitMQ，但是它是使用erlang语言开发的，如果不精通erlang，对公司而言，几乎处于不可控的状态，单其是开源的，社区活跃度高，拥有比较稳定的支持。
现在越来越多的公司开始使用RocketMQ，但是要小心被抛弃的风险。如果公司有实力自己去维护开发，推荐使用。否则还是选择RabbitMQ。
如果实在大数据的实时计算、日志采集等领域，用kafka是业界标准。
所以，对于中小型公司，技术实力一般的，应该用rabbitmq，对于大公司，基础架构研发能力强大的，推荐使用RocketMQ。
下一篇《如何保证消息队列的高可用》
