以下为总结的技术面试题目：
RabbitMQ
RabbitMQ 的使用场景有哪些？
削峰、解耦、延迟队列
RabbitMQ 怎么保证消息的稳定性？
- 提供了事务的功能。
- 通过将 channel 设置为 confirm（确认）模式。
RabbitMQ 怎么避免消息丢失？
- 把消息持久化磁盘，保证服务器重启消息不丢失。
- 每个集群中至少有一个物理磁盘，保证消息落入磁盘。
要保证消息持久化成功的条件有哪些？
- 队列持久化
- 交换机持久化
- 消息持久化
RabbitMQ 持久化有什么缺点？
持久化的缺点就是降低了服务器的吞吐量，因为使用的是磁盘而非内存存储，从而降低了吞吐量。可尽量使用 ssd 硬盘来缓解吞吐量的问题。
RabbitMQ 有几种广播类型？
- direct（默认方式）：最基础最简单的模式，发送方把消息发送给订阅方，如果有多个订阅者，默认采取轮询的方式进行消息发送。
- topic：匹配订阅模式，使用正则匹配到消息队列，能匹配到的都能接收到。
- fanout：分发模式，把消费分发给所有订阅者。
- headers：与 direct 类似，只是性能很差，此类型几乎用不到。
RabbitMQ 怎么实现延迟消息队列？
延迟队列的实现有两种方式：
- 通过消息过期后进入死信交换器，再由交换器转发到延迟消费队列，实现延迟功能；
- 使用 RabbitMQ-delayed-message-exchange 插件实现延迟功能。
RabbitMQ 集群有什么用？
集群主要有以下两个用途：
- 高可用：某个服务器出现问题，整个 RabbitMQ 还可以继续使用；
- 高容量：集群可以承载更多的消息量。
RabbitMQ 节点的类型有哪些？
- 磁盘节点：消息会存储到磁盘。
- 内存节点：消息都存储在内存中，重启服务器消息丢失，性能高于磁盘类型。
RabbitMQ 集群搭建需要注意哪些问题？
- 各节点之间使用“–link”连接，此属性不能忽略。
- 各节点使用的 erlang cookie 值必须相同，此值相当于“秘钥”的功能，用于各节点的认证。
- 整个集群中必须包含一个磁盘节点。
cRabbitMQ 每个节点是其他节点的完整拷贝吗？为什么？
不是，原因有以下两个：
- 存储空间的考虑：如果每个节点都拥有所有队列的完全拷贝，这样新增节点不但没有新增存储空间，反而增加了更多的冗余数据；
- 性能的考虑：如果每条消息都需要完整拷贝到每一个集群节点，那新增节点并没有提升处理消息的能力，最多是保持和单节点相同的性能甚至是更糟。
RabbitMQ 集群中唯一一个磁盘节点崩溃了会发生什么情况？
如果唯一磁盘的磁盘节点崩溃了，不能进行以下操作：
- 不能创建队列
- 不能创建交换器
- 不能创建绑定
- 不能添加用户
- 不能更改权限
- 不能添加和删除集群节点
唯一磁盘节点崩溃了，集群是可以保持运行的，但你不能更改任何东西。
RabbitMQ 对集群节点停止顺序有要求吗？
RabbitMQ 对集群的停止的顺序是有要求的，应该先关闭内存节点，最后再关闭磁盘节点。如果顺序恰好相反的话，可能会造成消息的丢失。
zookeeper
zookeeper 都有哪些功能？
zookeeper是分布式应用程序协调服务，具备以下功能；
- 文件系统
- 通知机制
zookeeper 有几种部署模式？
有两种部署方式，单机和集群
Zookeeper有哪几种节点类型
- 持久：创建之后一直存在，除非有删除操作，创建节点的客户端会话失效也不影响此节点。
- 持久顺序：跟持久一样，就是父节点在创建下一级子节点的时候，记录每个子节点创建的先后顺序，会给每个子节点名加上一个数字后缀。
- 临时：创建客户端会话失效（注意是会话失效，不是连接断了），节点也就没了。不能建子节点。
- 临时顺序：不用解释了吧。
集群中的机器角色都有哪些？集群最少要几台机器？
- Leader 一个Zookeeper集群同一时间只会有一个实际工作的Leader，它会发起并维护与各Follwer及Observer间的心跳。所有的写操作必须要通过Leader完成再由Leader将写操作广播给其它服务器。
- Follower 一个Zookeeper集群可能同时存在多个Follower，它会响应Leader的心跳。Follower可直接处理并返回客户端的读请求，同时会将写请求转发给Leader处理，并且负责在Leader处理写请求时，对请求进行投票（“过半写成功”策略）。
- Observer 角色与Follower类似，但是无投票权。
集群最低3（2N+1）台，保证奇数，主要是为了选举算法。
zookeeper 怎么保证主从节点的状态同步？
为了保证写操作的一致性与可用性，Zookeeper专门设计了一种名为原子广播（ZAB）的支持崩溃恢复的一致性协议。基于该协议，Zookeeper实现了一种主从模式的系统架构来保持集群中各个副本之间的数据一致性。
写数据时保证一致性：Zookeeper 客户端会随机连接到 Zookeeper 集群的一个节点，如果是读请求，就直接从当前节点中读取数据；如果是写请求且当前节点不是leader，那么节点就会向 leader 提交事务，leader 会广播事务，只要有超过半数节点写入成功，该写请求就会被提交（类 2PC 协议）。
集群中为什么要有主节点？
在分布式环境中，有些业务逻辑只需要集群中的某一台机器进行执行，其他的机器可以共享这个结果，这样可 以大大减少重复计算，提高性能，于是就需要进行 leader 选举。
集群中有 3 台服务器，其中一个节点宕机，这个时候 zookeeper 还可以使用吗？
不可以，过半存活即可用。
说一下 zookeeper 的通知机制？
client 端会对某个 znode 建立一个 watcher 事件，当该 znode 发生变化时，这些 client 会收到 zk 的通知， 然后 client 可以根据 znode 变化来做出业务上的改变等。
Watcher（事件监听器）是Zookeeper中的一个很重要的特性。Zookeeper允许用户在指定节点上注册一些Watcher，并且在一些特定事件触发的时候，ZooKeeper服务端会将事件通知到感兴趣的客户端上去，该机制是Zookeeper实现分布式协调服务的重要特性
