发展历程
kafka
使用场景
- 搜索服务
- 直播服务
- 订单服务
- 支付服务
- 用户行为服务
- 日志信息存储
kafka的使用
- 创建集群
- 新增Topic
- 编写生产者逻辑
- 编写消费者逻辑
kafka基本概念
Topic：逻辑队列，不同Topic 可以建立不同的 Topic
Cluster：物理集群，每个集群中可以建立多个不同的 Topic
Producer：生产者，负责将业务消息发送到 Topic 中
Consumer：消费者，负责消费 Topic 中的消息
ConsumerGroup： 消费者组，不同组 Consumer 消费进度互不干涉
Offset：消息在 partition 内的相对位置信息，可以理解为唯一1D，在partition 内部严格递增。
Replica：每个分片有多个 Replica
消息队列零拷贝问题
Consumer和Partition的分配
- 手动分配
- 不能自动容灾
- 自动分配
- 选取一个broker来作为Coordinator，作为哨兵（Rebalance）
- 每个Consumer每隔一段时间都会给Coordinator发送一段心跳包
Kafka的缺点
- 节点变化所需要的代价比较大
- 负载不均衡
- 没有自己的缓存，完全依赖 Page Cache
- Controller 和 Coordinator和Broker 在同一进程中，大量10会造成其性能下降
BMQ
简介
兼容Kafka协议，存算分离，云原生消息队列
与Kafka对比
文件结构
Partition状态机
保证对于任意分片在同一时刻只能在一个 Broker上存活
数据写入流程
数据读取流程
泳道消息
根据泳道过滤消息，避免了人力和资源的浪费。
DataBus
直接使用原生SDK会有什么问题？
- 客户端配置较为复杂
- 不支持动态配置，更改配置需要停掉服务
- 对于latency不是很敏感的业务，batch效果不佳
DataBus作用
- 简化消息队列复杂度
- 节藕业务与topic
- 缓解集群压力
Mirror（跨Region问题）
RocketMQ
使用场景
实时场景：
例如，针对电商业务线，其业务涉及广泛，如注册、订单、库存、物流等；同时，也会涉及许多业务峰值时刻，如秒杀活动、周年庆、定期特惠等
基本概念
基本架构
存储模型
高级特效
事物场景
保证事物的最终一致性
RocketMQ采用了两次提交机制
