十四、RabbitMQ

135. rabbitmq 的使用场景有哪些？

• 1异步处理
  场景：用户注册后，需要发注册邮件和注册短信；
  引入消息队列后，把发送邮件,短信不是必须的业务逻辑异步处理

image.png

• 2 应用解耦
  场景：订单系统和库存系统解耦
  订单系统:用户下单后,订单系统完成持久化处理,将消息写入消息队列,返回用户订单下单成功。

  库存系统:订阅下单的消息,获取下单消息,进行库操作。
  就算库存系统出现故障,消息队列也能保证消息的可靠投递,不会导致消息丢失

  
  image.png

• 3 流量削峰
  流量削峰一般在秒杀活动中应用广泛
  场景:秒杀活动，一般会因为流量过大，导致应用挂掉,为了解决这个问题，一般在应用前端加入消息队列。

  
  image.png

作用:
1.可以控制活动人数，超过此一定阀值的订单直接丢弃
2.可以缓解短时间的高流量压垮应用(应用程序按自己的最大处理能力获取订单)
过程：
1.用户的请求,服务器收到之后,首先写入消息队列,加入消息队列，如果请求数量超过最大值,则直接抛弃用户请求或跳转到错误页面.
2.秒杀业务根据消息队列中的请求信息，再做后续处理.

136. rabbitmq 有哪些重要的角色？

略

137. rabbitmq 有哪些重要的组件？

• 1. Server(broker): 接受客户端连接，实现AMQP消息队列和路由功能的进程。
• 2. Virtual Host:其实是一个虚拟概念，类似于权限控制组，一个Virtual Host里面可以有若干个Exchange和Queue，但是权限控制的最小粒度是Virtual Host

• 3.Exchange:接受生产者发送的消息，并根据Binding规则将消息路由给服务器中的队列。ExchangeType决定了Exchange路由消息的行为，例如，在RabbitMQ中，ExchangeType有direct、Fanout和Topic三种，不同类型的Exchange路由的行为是不一样的。

• 4.Message Queue：消息队列，用于存储还未被消费者消费的消息。

• 5.Message: 由Header和Body组成，Header是由生产者添加的各种属性的集合，包括Message是否被持久化、由哪个Message Queue接受、优先级是多少等。而Body是真正需要传输的APP数据。

• 6.Binding:Binding联系了Exchange与Message Queue。Exchange在与多个Message Queue发生Binding后会生成一张路由表，路由表中存储着Message Queue所需消息的限制条件即Binding Key。当Exchange收到Message时会解析其Header得到Routing Key，Exchange根据Routing Key与Exchange Type将Message路由到Message Queue。Binding Key由Consumer在Binding Exchange与Message Queue时指定，而Routing Key由Producer发送Message时指定，两者的匹配方式由Exchange Type决定。

• 7.Connection:连接，对于RabbitMQ而言，其实就是一个位于客户端和Broker之间的TCP连接。

• 8.Channel:信道，仅仅创建了客户端到Broker之间的连接后，客户端还是不能发送消息的。需要为每一个Connection创建Channel，AMQP协议规定只有通过Channel才能执行AMQP的命令。一个Connection可以包含多个Channel。之所以需要Channel，是因为TCP连接的建立和释放都是十分昂贵的，如果一个客户端每一个线程都需要与Broker交互，如果每一个线程都建立一个TCP连接，暂且不考虑TCP连接是否浪费，就算操作系统也无法承受每秒建立如此多的TCP连接。RabbitMQ建议客户端线程之间不要共用Channel，至少要保证共用Channel的线程发送消息必须是串行的，但是建议尽量共用Connection。

• 9.Command:AMQP的命令，客户端通过Command完成与AMQP服务器的交互来实现自身的逻辑。例如在RabbitMQ中，客户端可以通过publish命令发送消息，txSelect开启一个事务，txCommit提交一个事务。

140. rabbitmq 怎么保证消息的稳定性？

141.rabbitmq 怎么避免消息丢失？

• 第一种：消息持久化
  RabbitMQ 的消息默认存放在内存上面，如果不特别声明设置，消息不会持久化保存到硬盘上面的，如果节点重启或者意外crash掉，消息就会丢失。
  所以就要对消息进行持久化处理。如何持久化，下面具体说明下：
  要想做到消息持久化，必须满足以下三个条件，缺一不可。

  1） Exchange 设置持久化
  2）Queue 设置持久化
  3）Message持久化发送：发送消息设置发送模式deliveryMode=2，代表持久化消息

• 第二种：ACK确认机制
  多个消费者同时收取消息，比如消息接收到一半的时候，一个消费者死掉了(逻辑复杂时间太长，超时了或者消费被停机或者网络断开链接)，如何保证消息不丢？
  这个使用就要使用Message acknowledgment 机制，就是消费端消费完成要通知服务端，服务端才把消息从内存删除。
  这样就解决了，及时一个消费者出了问题，没有同步消息给服务端，还有其他的消费端去消费，保证了消息不丢的case。

• 第三种：设置集群镜像模式
  我们先来介绍下RabbitMQ三种部署模式：

  1）单节点模式：最简单的情况，非集群模式，节点挂了，消息就不能用了。业务可能瘫痪，只能等待。
  2）普通模式：默认的集群模式，某个节点挂了，该节点上的消息不能用，有影响的业务瘫痪，只能等待节点恢复重启可用（必须持久化消息情况下）。
  3）镜像模式：把需要的队列做成镜像队列，存在于多个节点，属于RabbitMQ的HA方案

• 第四种：消息补偿机制
  为什么还要消息补偿机制呢？难道消息还会丢失，没错，系统是在一个复杂的环境，不要想的太简单了，虽然以上的三种方案，基本可以保证消息的高可用不丢失的问题，但是，一些特殊的情况，比如持久化的消息，保存到硬盘过程中，当前队列节点挂了，存储节点硬盘又坏了，消息丢了，怎么办？

  产线网络环境太复杂，所以不知数太多，消息补偿机制需要建立在消息要写入DB日志，发送日志，接受日志，两者的状态必须记录。
  然后根据DB日志记录check 消息发送消费是否成功，不成功，进行消息补偿措施，重新发送消息处理。

image.png

142. 要保证消息持久化成功的条件有哪些？

• Exchange 持久化：如果不设定Exchange持久化，那么在RabbitMQ由于某些异常等原因重启之后，Exchange会丢失。Exchange丢失， 会影响发送端发送消息到RabbitMQ。

• Queue持久化：发送端将消息发送至Exchange，Exchange将消息转发至关联的Queue。如果Queue不设置持久化，那么在RabbitMQ重启之后，Queue信息会丢失。导致消息发送至Exchange，但Exchange不知道需要将该消息发送至哪些具体的队列。

• Message持久化：发送端将消息发送至Exchange，Exchange将消息转发至关联的Queue，消息存储于具体的Queue中。如果RabbitMQ重启之后，由于Message未设置持久化，那么消息会在重启之后丢失。

为了保证发布订阅的持久化，必须设置Exchange、Queue、Message的持久化，才可以保证消息最终不会丢失。

143. rabbitmq 持久化有什么缺点？

持久化会造成性能损耗，但为了生产环境的数据一致性，这是我们必须做出的选择。但我们可以通过设置消息过期时间、降低发送消息大小等其他方式来尽可能的降低MQ性能的降低。
将Exchange、Queue、Message都设置持久化，能保证消息100%会被成功消费吗？

答案肯定是否，天下没有绝对的事情，尤其是复杂的MQ。

原因简单介绍，一、如果消息的自动确认为true，那么在消息被接收以后，RabbitMQ就会删除该消息，假如消费端此时宕机，那么消息就会丢失。因此需要将消息设置为手动确认。

二、设置手动确认会出现另一个问题，如果消息已被成功处理，但在消息确认过程中出现问题，那么在消费端重启后，消息会重新被消费。

三、发送端为了保证消息会成功投递，一般会设定重试。如果消息发送至RabbitMQ之后，在RabbitMQ回复已成功接收消息过程中出现异常，那么发送端会重新发送该消息，从而造成消息重复发送。

四、RabbitMQ的消息磁盘写入，如果出现问题，也会造成消息丢失。

总结：Exchange、Queue、Message持久化，队列设定手动确认、AutoDelete=false。可以最大程度的保证消息不丢失。

144. rabbitmq 有几种广播类型？

广播模式：1对多，produce发送一则消息多个consumer同时收到。
注意：广播是实时的，produce只负责发出去，不会管对端是否收到，若发送的时刻没有对端接收，那消息就没了，因此在广播模式下设置消息持久化是无效的。
三种广播模式：
fanout: 所有bind到此exchange的queue都可以接收消息（纯广播，绑定到RabbitMQ的接受者都能收到消息）；
direct: 通过routingKey和exchange决定的那个唯一的queue可以接收消息；
topic:所有符合routingKey(此时可以是一个表达式)的routingKey所bind的queue可以接收消息；

145. rabbitmq 怎么实现延迟消息队列？

什么是延迟队列
延迟队列存储的对象肯定是对应的延时消息，所谓”延时消息”是指当消息被发送以后，并不想让消费者立即拿到消息，而是等待指定时间后，消费者才拿到这个消息进行消费。

场景一：在订单系统中，一个用户下单之后通常有30分钟的时间进行支付，如果30分钟之内没有支付成功，则系统自动取消订单。。这是就可以使用延时队列将订单信息发送到延时队列。

场景二：用户希望通过手机远程遥控家里的智能设备在指定的时间进行工作。这时候就可以将用户指令发送到延时队列，当指令设定的时间到了再将指令推送到只能设备。

场景三：物联网系统经常会遇到向终端下发命令，如果命令一段时间没有应答，就需要设置成超时

使用RabbitMQ来实现延迟任务必须先了解RabbitMQ的两个概念：消息的TTL和死信Exchange，通过这两者的组合来实现上述需求

• 消息的TTL（Time To Live）：消息的TTL就是消息的存活时间。RabbitMQ可以对队列和消息分别设置TTL。对队列设置就是队列没有消费者连着的保留时间，也可以对每一个单独的消息做单独的设置。超过了这个时间，我们认为这个消息就死了，称之为死信。如果队列设置了，消息也设置了，那么会取小的。所以一个消息如果被路由到不同的队列中，这个消息死亡的时间有可能不一样（不同的队列设置）。这里单讲单个消息的TTL，因为它才是实现延迟任务的关键。

• Dead Letter Exchanges
  Exchage的概念在这里就不在赘述，可以从这里进行了解。一个消息在满足如下条件下，会进死信路由，记住这里是路由而不是队列，一个路由可以对应很多队列。

  • 1. 一个消息被Consumer拒收了，并且reject方法的参数里requeue是false。也就是说不会被再次放在队列里，被其他消费者使用。

  • 2. 上面的消息的TTL到了，消息过期了。

  • 3. 队列的长度限制满了。排在前面的消息会被丢弃或者扔到死信路由上。

Dead Letter Exchange其实就是一种普通的exchange，和创建其他exchange没有两样。只是在某一个设置TTL的队列中有消息过期了，会自动触发消息的转发，发送到Dead Letter Exchange中去。
实现延迟队列
延迟任务通过消息的TTL和Dead Letter Exchange来实现。我们需要建立2个队列，一个用于发送消息，一个用于消息过期后的转发目标队列。

生产者输出消息到Queue1，并且这个消息是设置有有效时间的，比如60s。消息会在Queue1中等待60s，如果没有消费者收掉的话，它就是被转发到Queue2，Queue2有消费者，收到，处理延迟任务。

image.png

注意点：一个消息比在同一队列中的其他消息提前过期，提前过期的也不会优先进入死信队列，它们还是按照入库的顺序让消费者消费。如果第一进去的消息过期时间是1小时，那么死信队列的消费者也许等1小时才能收到第一个消息。参考官方文档发现“Only when expired messages reach the head of a queue will they actually be discarded (or dead-lettered).”只有当过期的消息到了队列的顶端（队首），才会被真正的丢弃或者进入死信队列。

所以在考虑使用RabbitMQ来实现延迟任务队列的时候，需要确保业务上每个任务的延迟时间是一致的。如果遇到不同的任务类型需要不同的延时的话，需要为每一种不同延迟时间的消息建立单独的消息队列。

146. rabbitmq 集群有什么用？

• 允许消费者和生产者在Rabbit节点崩溃的情况下继续运行；
• 通过增加节点来扩展Rabbit处理更多的消息，承载更多的业务量

147. rabbitmq 集群节点的类型有哪些？

节点的存储类型分为两种：

• 磁盘节点
• 内存节点
  磁盘节点就是配置信息和元信息存储在磁盘上，内存节点把这些信息存储在内存中，当然内存节点的性能是大大超越磁盘节点的。
  单节点系统必须是磁盘节点，否则每次你重启RabbitMQ之后所有的系统配置信息都会丢失
  RabbitMQ要求集群中至少有一个磁盘节点，当节点加入和离开集群时，必须通知磁盘节点

148. rabbitmq 集群搭建需要注意哪些问题？

集群搭建分为两步：

步骤一：安装多个RabbitMQ
步骤二：加入RabbitMQ节点到集群

注意点：

多个容器之间使用“--link”连接，此属性不能少；
Erlang Cookie值必须相同，也就是RABBITMQ_ERLANG_COOKIE参数的值必须相同，原因见下文“配置相同Erlang Cookie”部分；

149. rabbitmq 集群中每个节点是其他节点的完整拷贝吗？为什么？

RabbitMQ节点不完全拷贝特性
RabbitMQ的集群是由多个节点组成的，但我们发现不是每个节点都有所有队列的完全拷贝。

为什么默认情况下RabbitMQ不将所有队列内容和状态复制到所有节点？

有两个原因：

• 存储空间——如果每个节点都拥有所有队列的完全拷贝，这样新增节点不但没有新增存储空间，反而增加了更多的冗余数据。
• 性能——如果消息的发布需安全拷贝到每一个集群节点，那么新增节点对网络和磁盘负载都会有增加，这样违背了建立集群的初衷，新增节点并没有提升处理消息的能力，最多是保持和单节点相同的性能甚至是更糟。

所以其他非所有者节点只知道队列的元数据，和指向该队列节点的指针

150. rabbitmq 集群中唯一一个磁盘节点崩溃了会发生什么情况？

特殊异常：集群中唯一的磁盘节点崩溃了
如果集群中的唯一一个磁盘节点，结果这个磁盘节点还崩溃了，那会发生什么情况？

如果唯一磁盘的磁盘节点崩溃了，不能进行如下操作：

不能创建队列
不能创建交换器
不能创建绑定
不能添加用户
不能更改权限
不能添加和删除集群几点
总结：如果唯一磁盘的磁盘节点崩溃，集群是可以保持运行的，但你不能更改任何东西。

解决方案：在集群中设置两个磁盘节点，只要一个可以，你就能正常操作。

151. rabbitmq 对集群节点停止顺序有要求吗？

集群重启的顺序是固定的，并且是相反的。如下所述：

启动顺序：磁盘节点 => 内存节点
关闭顺序：内存节点 => 磁盘节点

十五、Kafka

152. kafka 可以脱离 zookeeper 单独使用吗？为什么？

不可以，kafka必须要依赖一个zookeeper集群才能运行。kafka系群里面各个broker都是通过zookeeper来同步topic列表以及其它broker列表的，一旦连不上zookeeper，kafka也就无法工作。

kafka使用ZooKeeper用于管理、协调代理。每个Kafka代理通过Zookeeper协调其他Kafka代理。

当Kafka系统中新增了代理或某个代理失效时，Zookeeper服务将通知生产者和消费者。生产者与消费者据此开始与其他代理协调工作。

Zookeeper在Kakfa中扮演的角色：Kafka将元数据信息保存在Zookeeper中，但是发送给Topic本身的数据是不会发到Zk上的；

kafka使用zookeeper来实现动态的集群扩展，不需要更改客户端（producer和consumer）的配置。broker会在zookeeper注册并保持相关的元数据（topic，partition信息等）更新。

· 而客户端会在zookeeper上注册相关的watcher。一旦zookeeper发生变化，客户端能及时感知并作出相应调整。这样就保证了添加或去除broker时，各broker间仍能自动实现负载均衡。这里的客户端指的是Kafka的消息生产端(Producer)和消息消费端(Consumer)

· Broker端使用zookeeper来注册broker信息,以及监测partitionleader存活性.

· Consumer端使用zookeeper用来注册consumer信息,其中包括consumer消费的partition列表等,同时也用来发现broker列表,并和partitionleader建立socket连接,并获取消息.

· Zookeer和Producer没有建立关系，只和Brokers、Consumers建立关系以实现负载均衡，即同一个ConsumerGroup中的Consumers可以实现负载均衡（因为Producer是瞬态的，可以发送后关闭，无需直接等待）

153. kafka 有几种数据保留的策略？

1）N天前的删除。

2）保留最近的多少Size数据。

154. kafka 同时设置了 7 天和 10G 清除数据，到第五天的时候消息达到了 10G，这个时候 kafka 将如何处理？

Kafka Broker默认的消息保留策略是：要么保留一定时间，要么保留到消息达到一定大小的字节数。

当消息达到设置的条件上限时，旧消息就会过期并被删除，所以，在任何时刻，可用消息的总量都不会超过配置参数所指定的大小。

155. 什么情况会导致 kafka 运行变慢？

156. 使用 kafka 集群需要注意什么？

十六、Zookeeper

157. zookeeper 是什么？

Zookeeper是一个高可用、高性能的分布式协调服务，可用于服务发现、分布式锁、分布式领导选举、配置管理等。

158. zookeeper 都有哪些功能？

• 分布式服务注册与订阅 适用：dubbo的provider和consumer
• 分布式配置中心 代表：百度的disconf
• 命名服务 代表：dubbo
• 分布式通知协调
• 分布式锁

159. zookeeper 有几种部署模式？

单机模式
集群模式
伪集群模式

160. zookeeper 怎么保证主从节点的状态同步？

根据ZAB协议
ZAB协议是为zookeeper专门设计的一种支持奔溃恢复的原子广播协议。虽然它不像Paxos算法那样通用通用，但是它却比Paxos算法易于理解。在我看来ZAB协议主要的作用在于三个方面1、选举出leader;2、同步节点之间的状态达到数据一致；3、数据的广播。
协议作用

• 选举leader
  每个follower广播自己事务队列中最大事务编号maxId
  获取集群中其他follower发出来的maxId，选取出最大的maxId所属的follower，投票给该follower，选它为leader。
  统计所有投票，获取投票数超过一半的follower被推选为leader
• 同步数据
  各个follower向leader发送自己保存的任期E
  leader,比较所有的任期，选取最大的E，加1后作为当前的任期E=E+1
  将任务E广播给所有follower
  follower将任期改为leader发过来的值，并且返回给leader事务队列L
  leader从队列集合中选取任期最大的队列，如果有多个队列任期都是最大，则选取事务编号n最大的队列Lmax。将Lmax最为leader队列，并且广播给各个follower。
  follower接收队列替换自己的事务队列，并且执行提交队列中的事务。
  至此各个节点的数据达成一致，zookeeper恢复正常服务。
• 广播
  leader节点接收到请求，将事务加入事务队列，并且将事务广播给各个follower。
  follower接收事务并加入都事务队列，然后给leader发送准备提交请求。
  leader 接收到半数以上的准备提交请求后，提交事务同时向follower 发送提交事务请求
  follower提交事务。

161. 集群中为什么要有主节点？

主从，主节点提供写，从节点提供读

162. 集群中有 3 台服务器，其中一个节点宕机，这个时候zookeeper 还可以使用吗？

可以

163. 说一下 zookeeper 的通知机制？

在 ZooKeeper 中，引入了 Watcher 机制来实现这种分布式的通知功能。ZooKeeper 允许客户端向服务端注册一个 Watcher 监听，当服务器的一些特定事件触发了这个 Watcher，那么就会向指定客户端发送一个事件通知来实现分布式的通知功能

ZooKeeper 的 Watcher 机制主要包括客户端线程、客户端 WatchManager 和 ZooKeeper 服务器三部分

image.png

在上图中：

• ZooKeeper ：部署在远程主机上的 ZooKeeper 集群，当然，也可能是单机的。
• Client ：分布在各处的 ZooKeeper 的 jar 包程序，被引用在各个独立应用程序中。
• WatchManager ：一个接口，用于管理各个监听器，只有一个方法 materialize()，返回一个 Watcher 的 set。

在具体流程上，简单讲，客户端在向 ZooKeeper 服务器注册 Watcher 的同时，会将 Watcher 对象存储在客户端的 WatchManager 中。当ZooKeeper 服务器触发 Watcher 事件后，会向客户端发送通知，客户端线程从 WatchManager 的实现类中取出对应的 Watcher 对象来执行回调逻辑。

ZooKeeper 的 Watcher 具有以下几个特性

• 一次性
  无论是服务端还是客户端，一旦一个 Watcher 被触发，ZooKeeper 都会将其从相应的存储中移除。因此，在 Watcher 的使用上，需要反复注册。这样的设计有效地减轻了服务端的压力。

• 客户端串行执行
  客户端 Watcher 回调的过程是一个串行同步的过程，这为我们保证了顺序，同时，需要注意的一点是，一定不能因为一个 Watcher 的处理逻辑影响了整个客户端的 Watcher 回调，所以，我觉得客户端 Watcher 的实现类要另开一个线程进行处理业务逻辑，以便给其他的 Watcher 调用让出时间。

• 轻量
  WatcherEvent 是 ZooKeeper 整个 Watcher 通知机制的最小通知单元，这个数据结构中只包含三部分内容：通知状态、事件类型和节点路径。也就是说，Watcher 通知非常简单，只会告诉客户端发生了事件，而不会说明事件的具体内容。例如针对 NodeDataChanged 事件，ZooKeeper 的Watcher 只会通知客户端指定数据节点的数据内容发生了变更，而对于原始数据以及变更后的新数据都无法从这个事件中直接获取到，而是需要客户端主动重新去获取数据——这也是 ZooKeeper 的 Watcher 机制的一个非常重要的特性。