a、如果每次pull时间间隔比较久，会增加消息延迟，消息到达消费者时间会加长。这样时间一长会导致MQ中消息的堆积，而消息长时间堆积就会导致一系列的问题：
1、如果积压了几个小时的数据，有几千万的数据量，消费端处理的压力会越来越大。
2、如果是带有过期时间的消息，可能这些消息已经到了过期时间，因为积压时间太长，但还没被消费端消费掉，消费端来不及消费。
3、如果持续的积压，达到了MQ能存储消息数量的上限，也就是说MQ满了，存不下了，会导致MQ丢掉数据，导致数据丢失。
想一下，上面的情形是不是跟TCP/IP协议的流量控制和拥塞控制遇到的一些问题很像，也有很多不同。
b、如果每次pull的时间间隔比较短，在一段时间内MQ中没有可消费的消息，会产生很多无效的pull请求，导致一定的网络开销。
所以解决问题的办法最主要就是优化消费端的消费性能。1.优化消费逻辑 2.水平扩容，增加消费端并发。
延迟问题处理如果消息堆积已经发生了，导致了上面的3个问题，这时怎么办？
1、积压了几个小时几千万的数据
第一：肯定要找到积压数据的原因，一般都是消费端的问题。
第二：如果可以的，扩大消费端的数量，快速消费掉消息。
第三：扩容，增加多机器消费。新建一个topic，partition是原来10倍，建立原先10倍的queue。然后写一个临时的消费程序，这个消费程序去转移积压的数据，把积压的数据均匀轮询写入建立好的10倍数量的queue。然后在征用10倍机器的消费端来消费这个queue。这种做法相当于临时将 queue 资源和 consumer 资源扩大 10 倍，以正常的 10 倍速度来消费数据。消费完了，恢复原来的部署。这是大厂做法。
2、积压时间过长，带有过期时间的消息过期失效了
这个没有好的办法处理，只能通过程序找出丢失的数据，然后也是通过程序把丢失的数据重新导入到MQ里，重新消费。
3、长时间积压倒是MQ写满了
这个也没啥好办法处理，只能快速消费掉MQ里的数据，快速消费指消费一个，丢掉一个，不要这些数据了，然后重新导入数据。用户少的时候在补回数据。
kafka基本架构：
Broker：一个kafka节点就是一个broker，多个broker组成一个kafka集群。一个broker可以是一个单机器kafka服务器。
Topic：存放消息的主题，相当于一个队列。可以理解为存放消息的分类，比如你可以有前端日志的Topic，后端日志的Topic。可以理解为MySQL里的表。
Partition：一个topic可以划分为多个partition，每个partition都是一个有序队列。把topic主题中的消息进行分拆，均摊到kafka集群中不同机器上。partition是topic的进一步拆分。
Replica：副本消息。kafka可以以partition为单位，保存多个副本，分散在不同的broker上。副本数是可以设置的。
Segment: 一个Partition被切分为多个Segment，每个Segment包含索引文件和数据文件。
Message：kafka里最基本消息单元。
一个kafka集群可以由多个broker组成，每个broker是一个节点，你创建一个topic，这个topic可以划分为多个partition，每个partition可以存储在不同的broker上，每个partition存放一部分数据。
6.2 RocketMQ在 RocketMQ 4.5 版本之前，RocketMQ 只有 Master/Slave 一种部署方式来实现高可用。
一组 Broker 中有一个 Master，有零到多个 Slave，Slave 通过同步复制或异步复制方式去同步 Master 的数据。Master/Slave 部署模式，提供了一定的高可用性。
上面主从高可用架构有一个缺点：
主节点挂了后需要人为的进行重启或者切换。为了解决这个问题，后续引入了raft，用raft协议来完成自动选主。RocketMQ的DLedger 就是一个基于 raft 协议的 commitlog 存储库，也是 RocketMQ 实现新的高可用多副本架构的关键。
还可以多master多slave部署，防止单点故障。
五、参考https://www.hicsc.com/post/2020041566
https://tech.meituan.com/2016/07/01/mq-design.html
https://lamport.azurewebsites.net/pubs/time-clocks.pdf
https://bug-free.cn/2020/01/09/Kafka-架构设计/