这是我参与「第五届青训营 」伴学笔记创作活动的第 15 天
消息队列的前世今生
针对四个场景：
- 系统崩溃 ： 解耦 利用消息队列与存储进行交互
- 服务处理能力有限 ：削峰 每次获取10个请求进行处理
- 链路耗时长尾 ：异步
- 日志如何处理 ： log
消息队列-Kafka
分布式 分区的 多副本 日志提交 ，在高吞吐场景较为出色
kafka使用场景，业务日志、用户行为数据、Metrics数据
基本概念，Producer、Cluster、Consumer、Topic、Partition
Topic: Kakfa中的逻辑队列，可以理解成每一个不同的业务场景就是一个不同的topic，对于这个业务来说，所有的数据都存储在这个topic中
Cluster: Kafka的物理集群，每个集群中可以新建多个不同的topic
Producer:顾名思义，也就是消息的生产端，负责将业务消息发送到Topic当中
Consumer:消息的消费端，负责消费已经发送到topic中的消息
Partition:通常topic会有多个分片，不同分片直接消息是可以并发来处理的，这样提高单个Topic的吞吐
数据迁移、Offset、Partition选主
Replica:分片的副本，分布在不同的机器上，可用来容灾
Leader对外服务，Follwer异步去拉取leader的数据进行一个同步，如果Leader挂掉了，可以将Follower提升成Leader再对外进行服务
ISR:意思是同步中的副本，对于Follower来说，始终和Leader是有一定差距的，但当这个差距比较小的时候，我们就可以将这个Follower副本加入到ISR中，不在ISR中的副本是不允许提升成Leader的
一条消息从生产到消费是如何处理的，Producer端逻辑、Broker端逻辑、Consumer端逻辑
producer端 批量发送，进行数据压缩
broker 数据存储 顺序存储 减少寻道时间
二分查找小于目标offset的最大索引位置
consumer： rebalance
消息队列-RocketMQ
低延迟强一致高性能高可靠万亿级容量和灵活的可扩展
RocketMQ使用场景
RocketMQ和Kafka对比
RocketMQ架构介绍，Producer、Broker、Nameserver、Consumer
一条消息从生产到消费是如何处理的，Producer端逻辑、Broker端逻辑、Consumer端逻辑
消息队列在字节
一些最佳实践的场景，包括数据展示
课后
-
消息队列的应用场景有哪些？
系统崩溃 ， 服务处理能力有限 ，链路耗时长尾 ，日志如何处理 -
Kafka的哪些Feature让其可以支撑大吞吐写入的场景？
-
Kafka Consumer Rebalance的流程简述？
consumer group在执行rebalance之前必须首先确认coordinator在哪个broker上。并创建与该broker通信的socket连接。确定 coordinator 的算法与确定 offset 被提交到consumer offsets 目标分区的算法是相同的 算法如下：
目前 rebalance 主要分为两步：加入组和同步更新分配方案
加入组：consumer group中所有consumer实例向coordinator发送JoinGroup请求。当收集全JoinGroup请求，coordinator从中选择一个consumer group作为group的leader，并把所有成员信息以及他们订阅的topic信息发送给leader。需要注意的是leader是consumer group中的一个consumer实例，而coordinator为集群的一个broker。是leader而不是coordinator负责为整个consumer group成员制定分配方案。
同步更新分配方案：这一步leader开始制定分配方案，即根据前面提到的分配策略，决定哪个consumer消费哪些topic的哪些分区，一旦分配完成，leader会将分配方案封装进SyncGroup请求发送给coordinator。值得注意的是，组内所有成员都会发送SyncGroup请求，不过只有leader发送的请求中包含分配方案。coordinator收到分配方案后把属于每个consumer的分配方案单独抽取出来做作为SyncGroup请求的response返回给各个consumer。
