这是我参与「第五届青训营 」伴学笔记创作活动的第 13 天
消息队列发展历程
TIB
诞生于1985年，服务于金融和新闻机构
IBM MQ/WebSphere
诞生于1993年，商业消息队列平台市场主要玩家
MSMQ
微软发布于1997年
JMS
诞生于2001年，本质上是一套Java API
AMQP/RabbitMQ
规范发布于2004年，同年RabbitMQ面世
Kafka
2010年由Linked开源
RocketMQ
2011年由阿里中间件团队自研
Pulsar
2012年诞生于雅虎内部
业界消息队列对比
Kafka
分布式、分区、多副本的日志提交服务，在高吞吐场景下发挥较为出色
RocketMQ
低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可拓展性，在一些实时场景中运用较广
Pulsar
下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体，采用存算分离的架构设计
BMQ
和Pulsar类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群
Kafka入门
如何使用Kafka
- 创建一个Kafka集群
- 在集群中创建一个Topic，并且设置好分片数量
- 引入对应语言的SDK，配置好集群和Topic等参数，初始化一个生产者，调用Send方法，将你的消息发送出去
- 引入对应语言的SDK，配置好集群和Topic等参数，初始化一个消费者，调用Poll方法，接收消息
但是这只是如何使用，里面涉及到一些如Topic、Send等概念需要慢慢捋清
概念理解
-
Topic：逻辑队列，可以理解成每一个不同的业务场景就是一个不同的Topic，对于这个业务来说，所有的数据都存储在这个Topic中
-
Cluster：Kafka的物理集群，每个集群可以新建多个不同的Topic
-
Producer：生产者，负责将业务消息发送到Topic中
-
Comsumer：消费者，负责消费已经发送到Topic中的消息
-
ComsumerGroup：消费者组，不同组ComsumerGroup消费进度互不干涉
-
Partition：通常Topic会有多个分片，不同分片直接消息是可以并发来处理的，这样提高单个Topic的吞吐
-
Offset：消息在Partition内的相对位置信息，可以理解为唯一ID，在Partition内部严格递增
-
Replica：分片的副本，分布在不同的机器上，可以用来容灾，Leader对外服务，Follower异步去拉取Leader的数据进行一个同步，如果Leader掉线，可以将Follower提生成Leader再对外进行服务
-
ISR：同步中的副本，对于Follower来说，始终和Leader是有一定差距的，但当这个差距比较小时，我们可以将这个Follower副本加入到ISR中，不在ISR中的副本是不允许提升成Leader的
- 每个分片有多个Replica，Leader Replica将会从ISR中选出
-
Zookeeper：在集群的基础上，实际上还有一个ZooKeeper模块，这个模块实际上是存储了集群的元数据信息，比如副本的分配信息等，Controller计算好的方案都会放到这个地方
一条消息的流程
首先由Producer生产消息->消息到达Broker->由消费者从Broker中消费掉
Broker消息文件结构
其实我个人认为，Topic可以理解为“主题”，这样可以从新的角度去理解消息队列
帮助Kafka提高吞吐/稳定性的功能
- Producer：批量发送、数据压缩
- Broker：顺序写、消息索引、零拷贝
- Comsumer：Rebalance
Kafka存在的问题
- 运维成本高： 存在数据复制的问题
- 对于负载不均衡的场景，解决方案复杂，我们需要一个较为复杂的解决方案进行数据迁移，从而来权衡IO升高的问题
- Kafka没有自己的缓存，在数据读取的时候，完全依赖Page Cache，灵活性不高
- Kafka的Controller和Coordinator都是和Broker部署在一起的，Broker承载了大量IO原因，会导致Controller和Coordinator的性能下降，如果IO到了一定程度的话，可能会影响整个集群的可用性
