消息队列是J2EE技术中常用的中间件,需要了解常用的消息队列实现方案与优缺点
- 消息模型
- push推模型:代表程序RabbitMq
- 需要考虑客户端的消费能力
- 客户端增加receive buffer,防止OOM
- 对于事务处理支持的好
- 消息状态维护在服务端
- 实时性较好
- 对服务端性能要求较高
- pull拉模型:Kafka
- 无需考虑客户端的消费能力
- 消息状态分别维护在客户端
- 消费能力重点在于客户端
- Kafka具体实现
- Kafka的基本角色 broker,provider,consumer
- 每个topic对应一个或者多个consumer group
- 每个topic对应多个partition以及replication,每个partition之间不能保证消费顺序
- 如何实现consumer的rebalance
- 每个partiton有对应的replication,多个replication需要一个leader,写操作只针对leader,然后执行leader-follower复制,其备份策略可以选择同步备份以及异步备份,也可以选择半数同步返回或者全同步,效率不一样,不同数量的replication也会影响性能
- 每个partition有对应的offset,对应有四个指针
- Last Committed Offset:这是 group 最新一次 commit 的 offset,表示这个 group 已经把 Last Committed Offset 之前的数据都消费成功了;
- Current Position:group 当前消费数据的 offset,也就是说,Last Committed Offset 到 Current Position 之间的数据已经拉取成功,可能正在处理,但是还未 commit;
- Log End Offset:Producer 写入到 Kafka 中的最新一条数据的 offset;
- High Watermark:已经成功备份到其他 replicas 中的最新一条数据的 offset,也就是说 Log End Offset 与 High Watermark 之间的数据已经写入到该 partition 的 leader 中,但是还未成功备份到其他的 replicas 中,这部分数据被认为是不安全的,是不允许 Consumer 消费的。
- kafka的消息日志存储,索引结构