关于MQ的几件小事（一）消息队列的用途、优缺点、技术选型

1.为何使用消息队列？

（1）解耦：能够在多个系统之间进行解耦，将本来经过网络之间的调用的方式改成使用MQ进行消息的异步通信，只要该操做不是须要同步的，就能够改成使用MQ进行不一样系统之间的联系，这样项目之间不会存在耦合，系统之间不会产生太大的影响，就算一个系统挂了，也只是消息挤压在MQ里面没人进行消费而已，不会对其余的系统产生影响。

（2）异步：加入一个操做设计到好几个步骤，这些步骤之间不须要同步完成，好比客户去建立了一个订单，还要去客户轨迹系统添加一条轨迹、去库存系统更新库存、去客户系统修改客户的状态等等。这样若是这个系统都直接进行调用，那么将会产生大量的时间，这样对于客户是没法接收的；而且像添加客户轨迹这种操做是不须要去同步操做的，若是使用MQ将客户建立订单时，将后面的轨迹、库存、状态等信息的更新全都放到MQ里面而后去异步操做，这样就可加快系统的访问速度，提供更好的客户体验。

（3）削峰：一个系统访问流量有高峰时期，也有低峰时期，好比说，中午整点有一个抢购活动等等。好比系统平时流量并不高，一秒钟只有100多个并发请求，系统处理没有任何压力，一切风平浪静，到了某个抢购活动时间，系统并发访问了剧增，好比达到了每秒5000个并发请求，而咱们的系统每秒只能处理2000个请求，那么因为流量太大，咱们的系统、数据库可能就会崩溃。这时若是使用MQ进行流量削峰，将用户的大量消息直接放到MQ里面，而后咱们的系统去按本身的最大消费能力去消费这些消息，就能够保证系统的稳定，只是可能要跟进业务逻辑，给用户返回特定页面或者稍后经过其余方式通知其结果。

2.消息队列有什么优势和缺点？

优势：一、对结构复杂、设计系统多的操做进行解耦操做，下降系统的操做复杂度、下降系统的维护成本。    二、对一个能够进行异步操做的一些系统操做进行异步，减少操做的响应时间，提供更好的用户体验。    三、可对高流量进行削峰，保证系统的平稳运行。 缺点：一、系统可用性下降。好比在系统中引入MQ，那么万一MQ挂了怎么办呢？通常而言，引入的外部依赖越多，系统越
    脆弱，每个依赖出问题都会致使整个系统的崩溃。    二、系统复杂度提升。须要考虑MQ的各类状况，好比：消息的重复消费、消息丢失、保证消费顺序等等......    三、数据一致性问题。好比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。

下一篇《如何保证消息队列的高可用》