这是我参与「第三届青训营 -后端场」笔记创作活动的的第1篇笔记。
主要内容
- 消息队列的前世今生
- 消息队列-Kafka
- 消息队列-BMQ
- 消息队列-RocketMQ
背景
现今，越来越多的企业面临着各种各样的数据集成和系统整合，CORBA、DCOM、RMI等RPC中间件技术也应运而生，但由于采用RPC同步处理技术，在性能、健壮性、可扩展性上都存在着诸多缺点。而基于消息的异步处理模型采用非阻塞的调用特性，发送者将消息发送给消息服务器，消息服务器在合适的时候再将消息转发给接收者；发送和接收是异步的，发送者无需等待，二者的生命周期也可以不必相同，而且发送者可以将消息间接传给多个接收者，大大提高了程序的性能、可扩展性及健壮性，这使得异步处理模型在分布式应用上比起同步处理模型更具有吸引力。
消息队列的前世今生
- Kaflka:分布式的、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色
- RocketMQ:低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性，在一些实时场景中运用较广
- Pulsar:是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体、采用存算分离的架构设计
- BMQ:和Pulsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群
Kafka
（ 1 ） Producer ： 消息生产者，就是向Kafka broker发消息的客户端。
（ 2 ） Consumer ： 消息消费者，向Kafka broker取消息的客户端。
（ 3 ） Consumer Group （ CG ）： 消费者组，由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。 所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
（ 4 ） Broker ： 一台Kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。
（ 5 ） Topic ： 可以理解为一个队列，生产者和消费者面向的都是一个 topic。
（ 6 ） Partition ： 为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个 topic 可以分为多个 partition，每个partition是一个有序的队列。
（ 7 ） Replica ： 副本。一个topic的每个分区都有若干个副本，一个Leader和若干个Follower。
（ 8 ） Leader ： 每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是Leader。
（9）Follower： 每个分区多个副本中的“从”，实时从Leader中同步数据，保持和Leader数据的同步。Leader发生故障时，某个Follower会成为新的Leader。
整体架构
存在的问题：
- 运维成本高
- 对于负载不均衡的场景，解决方案复杂
- 没有自己的缓存，完全依赖 Page Cache
- Controller和Coordinator和Broker在同一进程中，大量IO会造成其性能下降
BMQ
- 兼容Kafka协议，存算分离，云原生消息队列
整体架构
文件结构
- BMQ的架构模型(解决Kafka存在的问题)
- BMQ读写流程(Failover机制，写入状态机)
- BMQ 高级特性(泳道、Databus、Mirror、Index、Parquet)
RocketMQ
- 高级特性：
- 事务场景
- 事务消息
- 延迟发送
- 延迟消息
- 处理失败
- 消费重试
- 死信队列
