面试题-中间件篇

面试题-中间件篇

MQ

是什么

MessageQuene，消息队列，队列是一种FiFO先进先出的数据结构。消息由生产者发送到MQ进行排队，然后由消费者对消费进行处理。

优缺点

优点

1. 异步，提升系统的响应速度和吞吐量
2. 解耦，服务之间进行解耦，可以减少服务之间的影响，提高系统的稳定性和可扩展性。
3. 削峰，以稳定的系统资源应对突发的流量冲击。

缺点

1. 系统的可用性，一旦mq宕机，整个业务就会产生影响；
2. 系统的复杂度提高，引入mq之后数据链路会变得很复杂；
3. 数据一致性，需要保证各系统之间的数据一致性。

各种MQ的区别

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
单机吞吐量	万级，比 RocketMQ、Kafka 低一个数量级	同 ActiveMQ	10 万级，支撑高吞吐	10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic 数量对吞吐量的影响			topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic	topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源
时效性	ms 级	微秒级，这是 RabbitMQ 的一大特点，延迟最低	ms 级	延迟在 ms 级以内
可用性	高，基于主从架构实现高可用	同 ActiveMQ	非常高，分布式架构	非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性	有较低的概率丢失数据	基本不丢	经过参数优化配置，可以做到 0 丢失	同 RocketMQ
功能支持	MQ 领域的功能极其完备	基于 erlang 开发，并发能力很强，性能极好，延时很低	MQ 功能较为完善，还是分布式的，扩展性好	功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用

消息重复问题

所有的mq产品并没有提供主动解决幂等性的机制，需要由消费者自行控制；
最好的方法时消息体带一个业务标识的ID,来进行幂等性判断。

如何设计一个mq

1. 实现一个单机的队列数据结构，高效，可扩展性；
2. 将单机的队列扩展为分布式队列；
3. 基于topic定制消费路由策略，发送者路由策略，消费者与队列的对应关系，消费者路由策略
4. 实现高效的网络传输，-netty，http
5. 规划日志文件，实现文件的高效读写，-零拷贝，顺序写，快读还原运行现场；
6. 定制高级功能，死信队列，延迟队列，事务消息等

Kafka篇

保证消息不丢失

发送消息阶段

在生产者向mq写入数据时，可以通过设置参数来确定kafka是否接受到数据，参数的值可为0、1、all。
0：表示生产者向mq集群发送消息，不需要mq回复，也就是不确保消息发送成功，安全性低，但是高效；
1：表示生产者向mq集群发送消息，leader应答回复可以发送下一条，确保leader发送成功；
all：生产者向mq集群发送消息，需要确保leader和所有的follower都收到消息并完成备份。安全性高，效率低；

集群方式阶段

Kafka在2.8版本中正式废弃了Zookeeper，拥抱Raft

保存数据阶段

kafka会单独开辟一块磁盘空间用于数据的顺序写入。

消费数据阶段

kafka采用点对点模式，消费者主动的去kafka集群拉取消息，
多个消费者可以组成一个消费组，每个消费组都有一个组ID，同一个消费者组的消费者可以消费同一个topic下不同分区的数据，但是同一个分区的数据不会被不同的组内消费者消息。

消息消费顺序问题

生产者通过定制partition分配规则，将消息分配到同一个partition，topic下只对应一个消费者。

参考文章

RocketMQ篇

保证消息不丢失

发送消息阶段

同步发送：producer发送消息收到MQ的响应再发下一个数据，用在重要通知邮件上；
异步发送：producer发送消息，不等MQ响应接着发送下一个数据；
单向发送：producer只负责消息的发送，不管MQ的响应，如日志收集；
事务消息：

1. producer发送half消息给mq，mq返回消息响应，并写入结果
2. 如果消息响应成功执行本地事务，并返回本地事务状态的执行结果；
3. 事务消息有三种状态，1、commit事务执行成功，它允许消费者消费此消息；2、rollback事务执行失败，他代表消息将被删除，不允许消息；3、unknown未知状态，它代表需要检查消息队列来确定状态；
4. 当没有收到commit/Rollback的事务消息，MQ会发起回查消息，producer检查对应的本地事务状态，返回给MQ。如果还是未知状态继续下次回查；

集群方式阶段

1. 普通的主从集群，有异步复制模式，和同步双写模式。
2. Dledger新集群，基于raft协议的

保存数据阶段

消息刷盘来持久化，消息通过producer写入MQ的时候，有二种刷盘方式，分布式同步刷盘和异步刷盘；
同步刷盘，在返回给producer成功状态时，消息已经被写入磁盘。
异步刷盘，在返回给producer成功状态时，消息只是被写入内存中，当内存消息积累一定程度，统一写入磁盘。

消费数据阶段

支持集群消费和广播消费；
集群消费：客户端主动向MQ拉取数据，并返回消费结果；
广播消息：MQ主动推送消息给所有的客户端。消费结果由用户应用程序自己实现。

消息消费顺序问题

顺序需要由三个阶段保证：

1. 消息被发送时保持顺序
   producer端通过MessageQueueSelector来实现把一组有序的消息放在同一队列下。
2. 消息被存储时保持和发送的顺序一致
   MQ同步刷盘
3. 消息被消费时保持和存储的顺序一致
   如果队列在进行消费，则对该队列进行加锁，只有消费完才释放。
   每个分区只能有一个消费者消费，并对消费的队列进行加锁，

参考文章

RabbitMQ篇

保证消息不丢失

发送消息阶段

1. 消息发送+回调
2. 手动事务，channel.txSelect()开启事务，channel.exCommit()提交事务，channel.txRollback()回滚事务，这种方式对channel是会产生堵塞的，减少吞吐量下降

集群方式阶段

1. 普通的集群，消息是分散存储，节点之间不会主动进行消息同步，是有可能丢失消息的；
2. 镜像集群，镜像集群会在节点之间主动进行数据同步，这样数据安全性得到提高。

保存数据阶段

将队列配置成持久化队列，新增的Quorum类型的队列，会采用raft协议来进行消息同步。

消费数据阶段

autoCommit->手动提交offeset

消息消费顺序问题

保证目标的exchange只对应一个队列，并且一个队列只对应一个消费者