han_MQ

MQ

为什么使用MQ

• 异步处理：相比传统的串行、并行方式，提高了系统吞吐量。
• 应用解耦：系统间通过消息通信，不用关心其他系统的处理。
• 流量削峰：可以通过消息队列长度控制请求量；可以缓解时间内的高并发请求。
• 日志处理：解决大量日志传输。
• 消息通讯：消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯。比如实现点对点消息队列，或者聊天室等。

MQ的优点

• 主要是：解耦、异步、削峰
  解耦：A系统发送数据到BCD三个系统，通过接口调用发送。如果E系统也要这个数据呢？那如果C系统现在不需要了呢？A系统负责人几乎崩溃…A系统跟其它各种乱七八糟的系统严重耦合，A系统产生一条比较关键的数据，很多系统都需要A系统将这个数据发送过来。如果使用MQ，A系统产生一条数据，发送到MQ里面去，哪个系统需要数据自己去MQ里面消费。如果系统需要数据，直接从MQ消费即可；如果某个系统不需要这个条数据了，就取消对MQ消息的消费即可。这样下来，A系统压根儿不需要考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败、超时等情况。
  就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用MQ给它异步化解耦。
  异步：A系统接收一个请求，需要在自己本地写库，还需要在BCD三个系统写库，自己本地写库要3ms，BCD三个系统分别写库要300ms、450ms、200ms。最终请求延时是3+300+450+200 = 953ms，接近1s，用户感觉搞个什么东西，慢死了慢死了。用户通过浏览器发起请求，如果使用MQ，那么A系统连续发送3条消息到MQ队列中，假如耗时5ms，A系统从接受一个请求到返回响应给用户，总时长是3+5 = 8ms。
  削峰：减少高峰时期对服务器压力。

有什么缺点？RabbitMQ有什么缺点？

• 系统可用性降低：本来系统运行好好的，现在你非要加入个消息队列进去，那消息队列挂了，你的系统和它绑定在一起，要挂掉一起挂掉。因此，系统可用性会降低；
• 系统复杂度提高：加入了消息队列，要考虑很多方面的问题，比如：一致性问题、如何保证消息不被重复消费、如何保证消息可靠性传输等。因此，需要考虑的东西太多，复杂性增大。
• 一致性问题：A系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是BCD三个系统那里，BD两个系统写库成功了，结果C系统写库失败了，导致了数据就不一致了。
  所以，消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，做好之后，你会发现，系统复杂度提升了一个数量级，也许是复杂了10倍。

Kafka、ActiveMQ、RabbitMQ、RocketMQ有什么优缺点？

	ActiveMQ	RabbitMQ	RocketMQ	kafka	ZeroMQ
单机吞吐量	比RabbitMq低	2.6w/s（消息做持久化）	11.6w/s	17.3w/s	29w/s
开发语言	java	Erlang	java	Scala/java	C
主要维护者	Apache	Mozilla/Spring	Alibaba	Apache	iMatix，创始人已去世
成熟度	成熟	成熟	开源版本不够成熟	比较成熟	只有C、PHP等版本成熟
订阅形式	点对点（p2p）、广播（发布-订阅）	提供了4种：direct,topic,Headers和fanout。fanout就是广播模式	基于topic/message Tag以及按照消息类型、属性进行正则匹配的发布订阅模式	基于topic以及按照topic进行正则匹配的发布订阅模式	点对点（p2p）
持久化	支持少量堆积	支持少量堆积	支持大量堆积	支持大量堆积	不支持
顺序消息	不支持	不支持	支持	支持	不支持
性能稳定性	好	好	一般	较差	很好
集群方式	支持简单集群模式，比如‘主-备’，对高级集群模式支持不好	支持简单集群模式，‘复制’模式，对高级集群模式支持不好	常用 多对‘Master-Slave’模式，开源版本需手动切换Slave变成Master	天然的‘Leader-Slave’无状态集群，每台服务器既是Master也是Slave	不支持
管理界面	一般	较好	一般	无	无

中小型公司，技术实力较为一般，技术挑战不是特别的高，用RabbitMQ是不错的选择；
大型公司，基础架构研发实力较强，用RocketMQ是很好的选择。
大数据领域的实时计算、日志采集等场景，用kafka是业内标准的，绝对没问题，社区活跃度很高，何况是全世界这个领域的事实性规范。

MQ有哪些常见的问题？如何解决这些问题？

MQ常见的问题有：

• 消息的顺序问题
• 消息的重复问题

消息的顺序问题
消息有序指的是可以按照消息的发送顺序来消费。

假如生产者产生了2条消息：M1、M2，假定M1发送到S1，M2发送到S2，如果要保证M1先于M2被消费，怎么做？

解决方案：

• 保证生产者-MQServer-消费者是一对一 的关系
  
  缺陷：

• 并行就会成为消息系统的瓶颈（吞吐量不够）

• 更多的异常处理，比如：只要消费端出现问题，就会导致整个处理流程阻塞，我们不得不花费更多的精力来解决阻塞的问题；通过合理的设计或者将问题分解来规避。

• 不关注乱序的应用实际大量存在

• 队列无序并不意味着消息无序，所以从业务层面来保证消息的顺序而不仅仅是依赖于消息系统，是一种更合理的方式。

消息重复问题
造成消息重复根本原因是：网络不发达。
消费端处理消息的业务逻辑保持幂等性（简单来说，对于同一个系统，在同样条件下，一次请求和重复多次请求对资源的影响是一致的）。只要保持幂等性，不管来多少条重复消息，最后处理的结果都一样。保证每条消息都有唯一编号且保证消息处理成功与去重的日志同时出现。利用一张日志表来记录已经处理成功的消息的ID,如果新到的消息ID已经在日志表中，那么就不再处理这条消息。

什么是RabbitMQ？

RabbitMQ是一款开源的，Erlang编写的，基于AMQP协议的消息中间件。

rabbitMQ使用场景

• 服务间异步通信
• 顺序消费
• 定时任务
• 请求削峰

RabbitMQ基本概念

• Broker：简单来说就是消息队列服务器实体。
• Exchange：消息交换机，它指定消息按什么规则，路由到哪个队列
• Queue：消息队列载体，每个消息都会被投入到一个或多个队列
• Binding：绑定，它的作用就是把exchange和queue按照路由规则绑定起来。
• Routing Key：路由关键字，exchange根据这个关键字进行消息投递。
• VHost：vhost可以理解为虚拟broker，即mini-RabbitMQ server。其内部含有独立的queue、exchange和binding等，但最最重要的是，其拥有独立的权限系统，可以做到vhost范围的用户控制。当然，从RabbitMQ的全局角度，vhost可以作为不同权限隔离手段（一个典型的例子就是不同的应用可以跑在不同的vhost中）。
• Producer：消息生产者，就是投递消息的程序。
• Consumer：消息消费者，就是接受消息的程序。
• Channel：消息通道，在客户端的每个连接里，可建立多个channel，每个channel代表一个会话任务。

由Exchange、Queue、RoutingKey三个才能决定一个从Exchange到Queue的唯一线路

RabbitMQ的工作模式

一、simple模式（即最简单的收发模式）

• 消息产生消息，将消息放入队列
• 消息的消费者（consumer）监听 消息队列，如果队列中有消息，就消费掉，消息被拿走后，自动从队列中删除（隐患 消息可能没有被消费者正确处理，已经从队列中消息的丢失，这里可以设置成手动的ack，但如果设置成手动ack，处理完后要及时发送ack消息给队列，否则会造成内存溢出）。

二、work工作模式（资源竞争）

• 消息生产者将消息放入队列消费者可以有多个，消费者1，消费者2同时监听同一个队列，消息被消费。C1 C2共同争抢当前的消息队列内容，谁先拿到谁负责消费消息（隐患：高并发情况下，默认会产生某一个消息被多个消费者共同使用，可以设置一个开关（syncronize）保证一条消息只能被一个消费者使用）。
  三、publish/subscribe发布订阅（共享资源）

• 每个消费者监听自己的队列；
• 生产者将消息发给broker，由交换机将消息转发到绑定此交换机的每个队列，每个绑定交换机的队列都将收到消息。
  四、routing路由模式
  
• 消息生产者将消息发送给交换机按照路由判断，路由是字符串（info）当前产生的消息携带路由字符（对象的方法）。交换机根据路由的key,只能匹配上路由key对应的消息队列，对应的消费者才能消费信息。
• 根据业务功能定义路由字符串
• 从系统的代码逻辑中获取对应功能字符串，将消息任务扔到对应队列中。
• 业务场景：error通知；EXCEPTION;错误通知的功能；传统意义的错误通知；客户通知；利用key路由，可以将程序中的错误封装成消息传入消息队列中，开发者可以自定义消费者，实时接受错误。
  五、topic主体模式（路由模式的一种）

• 星号代表通配符
• 星号代表多个单词，井号代表一个单词
• 路由功能添加模糊匹配
• 消息生产者产生消息，把消息交给交换机
• 交换机根据key的规则模糊匹配到对应的队列，由队列的监听消费者接受消息消费

如何保证RabbitMQ消息的顺序性

拆分多个queue，每个queue一个consumer，就是多一些queue而已，确实麻烦点；或者就一个queue但是对应一个consumer，然后这个consumer内部用内存队列做排队，然后分发给底层不同的worker来处理。

消息如何分发？

若该队列至少有一个消费者订阅，消息将以循环（round-robin）的方式发送给消费者。每条消息只会发给一个订阅的消费者（前提是消费者能够正常处理消息并进行确认）。通过路由可实现多消费的功能

消息怎么路由

消息提供方 -> 路由 -> 一至多个队列消息发布到交换器时，消息将拥有一个路由键（routing key），在消息创建时设定。通过队列路由键，可以把队列绑定到交换机上。消息到达交换机后，RabbitMQ会将消息的路由键与队列的路由键进行匹配（针对不同的交换器有不同的路由规则）；
常用的交换器主要分为以下三种：
fanout：如果交换器收到消息，将会广播到所有绑定的队列上；
direct：如果路由键完全匹配，消息就被投递到相应的队列；
topic：可以使用来自不同源头的消息能够到达同一个队列。使用 topic交换器，可以使用通配符；

消息基于什么传输

由于TCP连接的创建和销毁开销较大，且并发数受系统资源限制，会造成性能瓶颈。RabbitMQ使用信道的方式来传输数据。信道是建立在真实的TCP连接内的虚拟连接，且每条TCP连接上的信道数量没有限制。

如何保证消息不被重复消费？或者说，如何保证消息消费时的幂等性？

先说为什么会重复消费：正常情况下，消费者在消费消息的时候，消费完毕后，会发送一个确认消息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除；
但是因为网络传输等等故障，确认信息没有传送到消息队列，导致消息队列不知道自己已经消费过该消息了，再次将消息分发给其它的消费者。
针对 以上问题，一个解决思路是：保证消息的唯一性，就算是多次传输，不要让消息的多次消费带来影响；保证消息的等幂性；
比如：在写入消息队列的数据做唯一标识，消费消息时，根据唯一标识来判断是否消费过；
假设你有个系统，消费一条消息就往数据库里插入一条数据，要是你一个消息重复两次，你不就插入了两条，这数据不就错了？但是你要是消费到第二次的时候，自己判断一下是否消费过了，若是就直接扔掉，这样不就保留了一条数据，从而保证了数据的正确性。

如何确保消息正确地发送至RabbitMQ？如何确保消息接收方消费了消息？

发送方确认模式
将信道设置成confrim模式（发送确认模式），则所有在信道上发布的消息都会被指派一个唯一的ID。

一旦消息被投递到目的队列，或者消息被写入磁盘后（可持久化消息），信道会发送一个确认给生产者（包含消息唯一ID）。
如果RabbitMQ发生内部错误从而导致消息丢失，会发送一条nack（notacknowledged，未确认）消息

发送放确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。当确认消息到达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息。
接受方确认机制
消费者接收每一条消息后都必须进行确认（消息接收和消息确认是两个不同操作）。只有消费者确认了消息，RabbitMQ才能安全地把消息从队列中删除。

这里并没有用到超时机制，RabbitMQ仅通过Consumer的连接中断来确认是否需要重新发送消息。也就是说，只要连接不中断，RabbitMQ给了Consumer足够长的时间来处理消息。保证数据的最终一致性；
几种特殊情况

• 如果消費者接收到消息，在确认断开了连接或者取消了订阅，RabbitMQ会认为消息没有被分发，然后重新分发给下一个订阅的消费者。（可能存在消息重复消费的隐患，需要去重）
• 如果消费者接收到消息却没有确认消息，连接也未断开，则RabbitMQ认为该消费者繁忙，将不会给该消费者分发更多的消息。

如何保证RabbitMQ消息的可靠传输？

消息不可靠的情况可能是消息丢失，劫持等原因；
丢失又分为：生产者丢失消息、消息列表丢失消息、消费者丢失消息；

生产者丢失消息：从生产者弄丢数据这个角度来看，RabbitMQ提供transaction和confirm模式来确保生产者不丢消息；

transaction机制就是说：发送消息前，开启事务（channel.txSelect()）,然后发送消息，如果发送过程中出现什么异常，事务就会回滚（channel.txRollback()），如果发送成功则提交事务（channel.txCommit()）。然而，这种方式有个缺点：吞吐量下降；

confirm模式用的居多：一旦channel进入confirm模式，所有在该信道上发布消息都将会被指派一个唯一的ID（从1开始），一旦消息被投递到所有匹配的队列之后；

rabbitMQ就会发送一个ACK给生产者（包含消息的唯一ID），这就使得生产者知道消息已经正确到达目的队列了；

如果rabbitMQ没能处理该消息，则会发送一个Nack消息给你，你可以进行重试操作。

消息队列丢失数据：消息持久化

处理消息队列丢数据的情况，一般是开启持久化磁盘的配置。
这个持久化配置可以和confirm机制配合使用，你可以在消息持久化磁盘后，再给生产者发送一个Ack信号。
这样，如果消息持久化磁盘之前rabbitMQ阵亡了，那么生产者收不到Ack信号，生产者会自动发。

那如何持久化呢？
1.将queue的持久化标识durable设置为true，则代表是一个持久的队列
2.发送消息的时候将deliveryMode=2

这样设置以后，即使rabbitMQ挂了，重启后也能恢复数据

消费者丢失消息：消费者丢数据一般是因为采用了自动确认消息模式，改为手动确认消息即可！
消费者在收到消息之后，处理消息之前，会自动回复RabbitMQ已收到消息；

如果这时处理消息失败，就会丢失该消息；

解决方案：处理消息成功后，手动回复确认消息。

为什么不应该对所有的message都使用持久化机制？

首先，必须导致性能下降，因为写磁盘比写RAM慢的多，message的吞吐量可能j有10倍的差距，

其次，message的持久化机制用在RabbitMQ的内置cluster方案时会出现“坑的”问题。矛盾点在于，若message设置了persistent属性，但queue未设置durable属性，那么当该queue的owner node 出现异常后，在未重建该queue前，发往该queue的message将被blackholed;若message设置了persistent属性，同时queue也设置了durable属性，那么当queue的owner node异常且无法重启的情况下，则该queue无法在其他node上重建，只能等待其owner node重启后，才能恢复该queue的使用，而在这段时间内发送给该queue的message将被blackholed.

所以，是否要对message进行持久化，需要综合考虑性能需要，以及可能遇到的问题。若想达到100000条/秒以上的消息吞吐量（单RabbitMQ服务器），则要么使用其他的方式来确保message的可靠delivery，要么使用非常快速存储系统以支持全持久化（例如使用SSD）。另外一种处理原则是：仅对关键消息做持久化处理（根据业务重要程度），且应该保证关键消息的量不会导致性能瓶颈。

如何保证高可用的？RabbitMQ的集群

RabbitMQ是比较有代表性的，因为是基于主从（非分布式）做高可用性的，我们就以RabbitMQ为例子讲解第一种MQ的高可用性怎么实现。RabbitMQ有三种模式：单机模式，普通集群模式，镜像集群模式。

单机模式：就是Demo级别的，一般就是你本地启动了玩玩的？没人生产用单机模式

普通集群模式：意思就是在多台机器上启动多个RabbitMQ实例，每个 机器启动一个。你创建的queue，只会放在一个RabbitMQ实例上，但是每个实例都同步queue的元数据（元数据可以认为是queue的一些配置信息，通过元数据，可以找到queue所在实例）。你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从queue所在实例上拉取数据过来，这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个queue的读写操作。

镜像集群模式：这种模式，才是所谓的RabbitMQ的高可用模式。跟普通集群模式不一样的是，在镜像集群模式下，你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，就是说，每个RabbitMQ节点都有这个queue的一个完整镜像，包含queue的全部数据的意思，然后每次你写消息到queue的时候，都会自动把消息同步到多个实例的queue上。
RabbitMQ有很好的管理控制台，就是在后台新增一个策略，这个策略时镜像集群模式，指定的时候是可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建queue的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。
这样的话，
好处在于，你任何一个机器宕机了，没事，其它的机器（节点）还包含了这个queue的完整数据，别的consumer都可以到其它节点上去消费数据。
坏处在于，这个性能开销太大，消息需要同步到所有机器上，导致网络带宽压力和消耗很重！RabbitMQ一个queue的数据都是放在一个节点里的，镜像集群下，也是每个节点都放这个queue的完整数据。

如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几个小时，说说该怎么解决？

消息积压处理办法 -> 临时紧急扩容：
先修复consumer的问题，确保其恢复消费速度，然后将现有consumer都停掉。
新建一个topic，partition是原来的10倍，临时建立好原先10倍的queue数量。
然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的10倍数量的queue。
接着临时用10倍的机器来部署consumer，每一批consumer消费一个临时queue的数据。这种做法相当于是临时将queue资源和consumer资源扩大10倍，以正常的10倍速度来消费数据。
等快速消费完积压数据之后，得恢复原先部署的架构，重新用原先的consumer机器来消费消息。

MQ中消息失效：假设你用的是RabbitMQ，RabbitMQ是可以设置过期时间的，也就是TTL。如果消息在queue中积压超过一定的时间就会被RabbitMQ给清理掉，这个数据就没了。那这就是第二个坑了。这就不是说数据会大量积压在mq里，而是大量的数据会直接搞丢。我们可以采取一个方案，就是批量重导，这个我们之前线上也有类似的场景干过。就是大量积压的时候，我们当时就直接丢弃数据了，然后等过了高峰期以后，比如大家一起喝咖啡熬夜到晚上12点以后，用户都睡觉了。这个时候我们就开始写程序，将丢失的那批数据，写个临时程序，一点一点的查出来，然后重新灌入mq里面去，把白天丢的数据给他补回来。也只能是这样了。假设1万一个订单积压在mq里面，没有处理，其中1000个订单都丢了，你只能手动写程序把那个1000个订单给查出来，手动发到mq里去再补一次。

mq消息队列快满了：如果积压在mq里，你很长时间都没有处理掉，此时导致mq都快写满了，咋办？这个还有别的办法吗？没有，谁让你第一个方案执行的太慢了，你临时写程序，接入数据来消费，消费一个丢弃一个，都不要了，快速消费掉所有的消息。然后走第二个方案，到了晚上再补数据。

设计MQ思路

比如说这个消息队列系统，我们从以下几个角度来考虑一下：

首先这个mq得支持可伸缩性，就是需要的时候快速扩容，就可以增加吞吐量和容量，那怎么搞？设计个分布式的系统呗，参照一下kafka的设计理念，broker-> topic -> partition,每个partition放一个机器，就存一部分数据。如果现在资源不够了，简单啊，给topic增加partition，然后做数据迁移，增加机器，不就可以存放更多数据，提供更高的吞吐量？

其次你得考虑一下mq的数据要不要落地磁盘吧？那肯定要了，落磁盘才能保证别进程挂了数据就丢了。那落磁盘的时候怎么落啊？顺序写，这样就没有磁盘随机读写的寻址开销，磁盘顺序读写的性能 是很高的，这就是kafka的思路。

其次你考虑一下你的mq的可用性啊？这个事儿，具体参考之前可用性那个环节讲解的kafka的高可用保障机制。多副本 -> leader&follow -> broker挂了重新选举leader即可对外服务。

能不能支持数据0丢失啊？可以的，参考我们之前说的那个kafka数据零丢失方案。