在单消息队列场景下，随着生产者和消费者增多，生产者和消费者会出现争抢问题
解决方案：
对消息进行分类，每个分类就是一个 topic,
根据 topic 增加队列的数量
生产者将数据按 topic 投递到不同的队列中
消费者根据需要订阅不同的 topic
单个 topic 中消息过多问题
解决方案：
将单个队列拆分成好几段，每段就是一个 partition 分区
每个消费者负责一个 partition
高扩展性：
所有 partition 在同一台机器上就会导致单机 CPU 和内存过高
解决方案：
将 partition 分散部署到多台机器上
每台机器就代表一个 broker
通过增加机器横向扩展来解决 CPU 和内存过高带来的性能问题
高可用
如果 partition 所在的 broker 挂了， partition 中的数据就会丢失，如何解决？
解决方案：
增加副本，统称为 replicas
副本可以放在不同的 broker 上
其中有一个叫做 leader 剩下的叫做 follower
leader 负责生产者和消费者的读写请求， follower 只负责备份
leader 挂了，则从剩余的 follower 中选举一个 leader
持久化和过期策略
如果所有 borker 都挂了，数据就会丢失
解决方案：
将数据保存到硬盘中，borker 重启后可以从硬盘将数据加载到内存
一直往硬盘写数据，硬盘写满怎么办？
解决方案：
增加保留策略（retention policy）
设置保存在硬盘中的数据最大值，超过后，则删除最旧的数据；
设置硬盘中数据的最长时间，超过删除保存时间最长的数据；
每次新增的消费者只能跟着最新的 offset 接着消费，如何让新增的消费者从某个 offset 开始消费？
offset：消费者的消费进度
解决方案：
引入消费者组（consumer group）
不同消费者组维护自己的消费者进度
如何 检测 broker 的状态，以及如何记录消费者组的消费进度？
解决方案：
引入 zookeeper,
/定时检测每个 broker 的状态，如果挂了，触发故障转移机制
记录每个消费者组的消费进度0
