消息队列的本质
保存消息的一个数组（队列），支持高吞吐，高并发，高可用
Kafka
使用场景
日志，Metrics数据（程序运行时的信息），用户行为
使用方法
创建集群->新增topic->编写生产者逻辑->编写消费者逻辑
基本概念
offset
消息队列在partition内的相对位置
replica
leader:直接和生产者消费者交互的
follower：leader的副本，每隔一段时间更新，如果和leader差距过大就删除这个follower，作用是在leader所在机器宕机时复制到leader中
实现机制
producer
批量发送，减少IO
数据压缩，减小数据大小，减轻带宽压力
broker
文件结构：
写入方式：顺序写，减少磁盘延迟
查找方式：根据目标offset查找，获取position，查找方式和B+树类似：
consumer
分配方式：使用coordinator
优势：当某个group内部的consumer宕机，可以把对应的partition再分配给别的consumer；如果新增consumer，就重新在这个group内分配
问题
负载不均衡
每个partition都在一个broker中，如果有一个partition过大就会造成影响
partition3要移到另一个broker中，但是本来的目的是减少IO，移过去的时候导致了新的IO
重启的代价
数据的复制导致重启代价高
BMQ
兼容kafka，同时实现存算分离，云原生消息队列
架构：
与kafka的不同：broker写，proxy读
文件结构
使用datanode，写的时候随机选择几个node写，解决了负载不均衡的问题
写文件：broker
多了个buffer
读文件：proxy
设置一个等待机制，避免太多consumer
多了cache
高级特性
泳道
解决两个问题：
- 测试和生产的topic不同
- 如果每个测试都用一个topic则负载太大，不同泳道有自己的id，不会混用
mirror
解决跨region调用太慢的问题
相当于先写到cache里再一块传输到另一端
