共计 3205 个字符，预计需要花费 9 分钟才能阅读完成。
什么是 MQ
音讯总线 (Message Queue)，是一种 跨过程 、 异步 的通信机制，用于上下游传递音讯。由音讯零碎来确保音讯的牢靠传递。
MQ 是干什么用的？
利用 解耦 、 异步 、 流量削锋、数据散发、错峰流控、日志收集等等 …
解耦 举例：看这么个场景。A 零碎发送数据到 BCD 三个零碎，通过接口调用发送。如果 E 零碎也要这个数据呢？那如果 C 零碎当初不须要了呢？A 零碎负责人简直解体 ……，所以通过公布订阅模式，谁须要谁订阅即可。
异步 举例：A 零碎接管一个申请，须要在本人本地写库，还须要在 BCD 三个零碎写库，本人本地写库要 3ms，BCD 三个零碎别离写库要 300ms、450ms、200ms。最终申请总延时是 3 + 300 + 450 + 200 = 953ms，靠近 1s，用户感觉搞个什么货色，慢死了慢死了。用户通过浏览器发动申请，期待个 1s，这简直是不可承受的。如果应用异步，A 零碎解决完本人的逻辑，间接返回给用户；而后发消息让 BCD 写库；用户收到申请只有 3ms，体验晦涩美滋滋。
流量削峰 举例：每天 0:00 到 12:00，A 零碎惊涛骇浪，每秒并发申请数量就 50 个。后果每次一到 12:00 ~ 13:00，每秒并发申请数量忽然会暴增到 5k+ 条。然而零碎是间接基于 MySQL 的，大量的申请涌入 MySQL，每秒钟对 MySQL 执行约 5k 条 SQL。个别的 MySQL，扛到每秒 2k 个申请就差不多了，如果每秒申请到 5k 的话，可能就间接把 MySQL 给打死了，导致系统解体，用户也就没法再应用零碎了。这时能够通过 MQ，把音讯挤压在队列中，至多能够保证系统失常可用；而后依照零碎失常处理速度写入数据，也不会失落数据。
MQ 的潜在毛病
- 零碎可用性升高
零碎引入的内部依赖越多，越容易挂掉。原本你就是 A 零碎调用 BCD 三个零碎的接口就好了，人 ABCD 四个零碎好好的，没啥问题，你偏加个 MQ 进来，万一 MQ 挂了咋整，MQ 一挂，整套零碎解体的，你不就完了？如何保障音讯队列的高可用 - 零碎复杂度进步
硬生生加个 MQ 进来，你怎么保障音讯没有反复生产？怎么解决音讯失落的状况？怎么保障消息传递的程序性？头大头大，问题一大堆，苦楚不已。 - 一致性问题
A 零碎解决完了间接返回胜利了，人都认为你这个申请就胜利了；然而问题是，要是 BCD 三个零碎那里，BD 两个零碎写库胜利了，后果 C 零碎写库失败了，咋整？你这数据就不统一了。
主流产品
RabbitMQ，Kafka，ActiveMQ，RocketMQ 等等
综上，各种比照之后，有如下倡议：
个别的业务零碎要引入 MQ，最早大家都用 ActiveMQ，然而当初的确大家用的不多了，没通过大规模吞吐量场景的验证，社区也不是很沉闷；
起初大家开始用 RabbitMQ，然而的确 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它，对公司而言，简直处于不可控的状态，然而的确人家是开源的，比较稳定的反对，活跃度也高；
不过当初的确越来越多的公司，会去用 RocketMQ，的确很不错（阿里出品），对本人公司技术实力有相对自信的，举荐用 RocketMQ。
所以中小型公司，技术实力较为个别，技术挑战不是特地高，用 RabbitMQ 是不错的抉择；大型公司，基础架构研发实力较强，用 RocketMQ 是很好的抉择。
如果是大数据畛域的实时计算、日志采集等场景，用 Kafka 是业内规范的，相对没问题，社区活跃度很高，何况简直是全世界这个畛域的事实性标准
RabbitMQ 的劣势：
可靠性 (Reliablity)：应用了一些机制来保障可靠性，比方长久化、传输确认、公布确认。灵便的路由 (Flexible Routing)：在音讯进入队列之前，通过 Exchange 来路由音讯。对于典型的路由性能，Rabbit 曾经提供了一些内置的 Exchange 来实现。针对更简单的路由性能，能够将多个 Exchange 绑定在一起，也通过插件机制实现本人的 Exchange。音讯集群 (Clustering)：多个 RabbitMQ 服务器能够组成一个集群，造成一个逻辑 Broker。高可用 (Highly Avaliable Queues)：队列能够在集群中的机器上进行镜像，使得在局部节点出问题的状况下队列依然可用。多种协定 (Multi-protocol)：反对多种音讯队列协定，如 STOMP、MQTT 等。多种语言客户端 (Many Clients)：简直反对所有罕用语言，比方 Java、.NET、Ruby 等。治理界面 (Management UI)：提供了易用的用户界面，使得用户能够监控和治理音讯 Broker 的许多方面。跟踪机制 (Tracing)：如果音讯异样，RabbitMQ 提供了音讯的跟踪机制，使用者能够找出产生了什么。插件机制 (Plugin System)：提供了许多插件，来从多方面进行扩大，也能够编辑本人的插件。
RabbitMQ 的几种应用模式
1、生产与生产
生产端通过路由规定发送音讯到不同 queue，生产端依据 queue 名称生产音讯。
RabbitMQ 是向生产端推送音讯，订阅关系和生产状态保留在服务端。
生产端发送一条音讯通过路由投递到 Queue，只有一个消费者能生产到。
举例：零碎外部的点赞操作，和用户的点赞数据列表。点赞操作执行实现后，如果还须要解决用户已点赞数据等一些列逻辑，会减少以后点赞接口耗时。所以只须要发消息进去，点赞接口后行返回点赞后果，供点赞数据收到音讯后处理已点赞数据逻辑等。点赞服务可能也是集群，只有一个服务生产到这个点赞音讯即可。如果存在多个服务均生产该数据，有可能会存在数据反复问题。
2、公布与订阅
当 RabbitMQ 须要反对多订阅时，发布者发送的音讯通过路由同时写到多个 Queue，不同订阅组生产此音讯。
举例：棋谱负责解决 feed 流数据，记录 feed 的各种状态。小视频，创作核心都关怀 feed 的状态，须要晓得 feed 是否发生变化。那 qipu 就说 我把音讯放到音讯池里好了，你们谁须要新数据，通过订阅我，而后就可到池里拿了。后续新增随刻创作，也能够通过订阅的 qipu 的数据，来获取 feed 数据。
两者的次要区别：
生产模式：生产消费者是所有消费者抢占音讯，订阅公布是所有订阅者共享音讯。
（1）生产者消费者模式：生产者生产音讯放到队列里，多个消费者同时监听队列，谁先抢到音讯谁就会从队列中取走音讯；即对于每个音讯只能被最多一个消费者领有；
（2）发布者订阅者模式：发布者生产音讯放到队列里，多个监听队列的消费者都会收到同一份音讯；即失常状况下每个消费者收到的音讯应该都是一样的。
公布订阅中 EXchange 有四种工作模式：fanout，direct，topic，headers（不罕用）
公布与订阅要借助交换机（EXchange）的原理来实现
Exchange：音讯交换机，他制订音讯按什么规定，路由到哪个队列。
Queue：音讯队列载体，每个音讯都会被投入一个或多个队列。
Binding：绑定，他的作用就是把 exchange 和 queue 依照路由规定绑定起来。
Routing Key：路由关键字，exchange 依据这个关键字进行音讯投递。
1、fanout
每个发到 fanout 类型交换器的音讯都会分到所有绑定的队列下来。
fanout 交换器不解决该路由键，只是简略的将队列绑定到交换器上，每个发送到交换器的音讯都会被转发到与该交换器绑定的所有队列上。很像子网播送，每台子网内的主机都取得了一份复制的音讯。fanout 类型转发音讯是最快的。
2、direct
每个发到 fanout 类型交换器的音讯都会分到所有绑定的队列下来。
音讯中的路由键 (routing key) 如果和 Binding 中的 binding key 统一，交换器就将音讯发到对应的队列中。路由键与队列名 齐全匹配。
3、topic
topic 交换器通过模式匹配 (能够了解依照肯定规定为 含糊匹配 ) 调配音讯的路由键属性，将路由键和某个模式进行匹配，此时队列须要绑定到一个模式上。
