谷歌绘制的网站,wordpress edu2.0,直播开放平台是什么意思,做er图的网站基本概念
主题#xff1a;Topic。主题是承载消息的逻辑容器#xff0c;在实际使用中多用来区分具体的业务。
分区#xff1a;Partition。一个有序不变的消息序列。每个主题下可以有多个分区。消息位移#xff1a;Offset。表示分区中每条消息的位置信息#xff0c;是一个…基本概念
主题Topic。主题是承载消息的逻辑容器在实际使用中多用来区分具体的业务。
分区Partition。一个有序不变的消息序列。每个主题下可以有多个分区。消息位移Offset。表示分区中每条消息的位置信息是一个单调递增且不变的值。
副本Replica。Kafka 中同一条消息能够被拷贝到多个地方以提供数据冗余这些地方就是所谓的副本。副本还分为领导者副本和追随者副本各自有不同的角色划分。副本是在分区层级下的即每个分区可配置多个副本实现高可用。
生产者Producer。向主题发布新消息的应用程序。
消费者Consumer。从主题订阅新消息的应用程序。
消费者位移Consumer Offset。表征消费者消费进度每个消费者都有自己的消费者位移。
消费者组Consumer Group。多个消费者实例共同组成的一个组同时消费多个分区以实现高吞吐。
重平衡Rebalance。消费者组内某个消费者实例挂掉后其他消费者实例自动重新分配订阅主题分区的过程。Rebalance 是 Kafka 消费者端实现高可用的重要手段。 Kafka 的三层消息架构
第一层是主题层每个主题可以配置 M 个分区而每个分区又可以配置 N 个副本。
第二层是分区层每个分区的 N 个副本中只能有一个充当领导者角色对外提供服务其他 N-1 个副本是追随者副本只是提供数据冗余之用。
第三层是消息层分区中包含若干条消息每条消息的位移从 0 开始依次递增。最后客户端程序只能与分区的领导者副本进行交互。 Broker 是如何持久化数据
总的来说Kafka 使用消息日志Log来保存数据一个日志就是磁盘上一个只能追加写Append-only消息的物理文件。因为只能追加写入故避免了缓慢的随机 I/O 操作改为性能较好的顺序 I/O 写操作这也是实现 Kafka 高吞吐量特性的一个重要手段。不过如果你不停地向一个日志写入消息最终也会耗尽所有的磁盘空间因此 Kafka 必然要定期地删除消息以回收磁盘。怎么删除呢简单来说就是通过日志段Log Segment机制。在 Kafka 底层一个日志又进一步细分成多个日志段消息被追加写到当前最新的日志段中当写满了一个日志段后Kafka 会自动切分出一个新的日志段并将老的日志段封存起来。Kafka 在后台还有定时任务会定期地检查老的日志段是否能够被删除从而实现回收磁盘空间的目的。 高性能 消息的顺序性、顺序写磁盘 零拷贝 RocketMQ内部主要是使用基于mmap实现的零拷贝用来读写文件 减少cpu的拷贝次数和上下文切换次数实现文件的高效读写操作 Kafka
零拷贝
Kafka 使用到了 mmap 和 sendfile 的方式来实现零拷贝。分别对应 Java 的 MappedByteBuffer 和 FileChannel.transferTo
顺序写磁盘
Kafka 采用顺序写文件的方式来提高磁盘写入性能。顺序写文件基本减少了磁盘寻道和旋转的次数 完成一次磁盘 IO需要经过寻道、旋转和数据传输三个步骤如果在写磁盘的时候省去寻道、旋转可以极大地提高磁盘读写的性能。Kafka 中每个分区是一个有序的不可变的消息序列新的消息不断追加到 Partition 的末尾在 Kafka 中 Partition 只是一个逻辑概念Kafka 将 Partition 划分为多个 Segment每个 Segment 对应一个物理文件Kafka 对 segment 文件追加写这就是顺序写文件
页缓存技术
应当使用本地磁盘作为存储介质。Page Cache 的存在就可以提升消息的读取速度
批量传输与压缩消息
生产端有两个重要的参数batch.size和linger.ms。这两个参数就和 Producer 的批量发送消息有关。
网络模型
Kafka 自己实现了网络模型做 RPC。底层基于 Java NIO采用和 Netty 一样的 Reactor 线程模型。 Kafka 即基于 Reactor 模型实现了多路复用和处理线程池。Reactor 模型基于池化思想避免为每个连接创建线程连接完成后将业务处理交给线程池处理基于 IO 复用模型多个连接共用同一个阻塞对象不用等待所有的连接。遍历到有新数据可以处理时操作系统会通知程序线程跳出阻塞状态进行业务逻辑处理
分区并发
Kafka 的 Topic 可以分成多个 Partition每个 Paritition 类似于一个队列保证数据有序。同一个 Group 下的不同 Consumer 并发消费 Paritition分区实际上是调优 Kafka 并行度的最小单元因此可以说每增加一个 Paritition 就增加了一个消费并发。
高效的文件数据结构
每个 Topic 又可以分为一个或多个分区。每个分区各自存在一个记录消息数据的日志文件。Kafka 每个分区日志在物理上实际按大小被分成多个 Segment。 segment file 组成由 2 大部分组成分别为 index file 和 data file此 2 个文件一一对应成对出现index 采用稀疏索引这样每个 index 文件大小有限Kafka 采用mmap的方式直接将 index 文件映射到内存这样对 index 的操作就不需要操作磁盘 IO分段和索引的策略利用偏移量和时间索引文件实现快速消息查找
高可用 Kafka Kafka 从 0.8 版本开始提供了高可用机制可保障一个或多个 Broker 宕机后其他 Broker 能继续提供服务
分区副本、备份机制 同一个 Partition 存在多个消息副本每个 Partition 的副本通常由 1 个 Leader 及 0 个以上的 Follower 组成
Kafka 会尽量将所有的 Partition 以及各 Partition 的副本均匀地分配到整个集群的各个 Broker 上多副本机制 分区Partition引入了多副本Replica机制。多分区、多副本机制好处呢 1. Kafka 通过给特定 Topic 指定多个 Partition分区, 而各个 Partition 可以分布在不同的 Broker 上, 这样便能提供比较好的并发能力负载均衡。2. Partition 可以指定对应的 Replica 数, 这也极大地提高了消息存储的安全性, 提高了容灾能力不过也相应的增加了所需要的存储空间。
ACK 机制 生产者发送消息中包含 acks 字段该字段代表 Leader 应答生产者前 Leader 收到的应答数「acks0」 生产者无需等待服务端的任何确认因此 acks0 不能保证服务端已收到消息 「acks1」默认值 只要 Partition Leader 接收到消息而且写入本地磁盘了就认为成功了不管其他的 Follower 有没有同步 「acksall or -1」 服务端会等所有的 follower 的副本受到数据后才会收到 leader 发出的 ack这样数据不会丢失Broker 有个配置项min.insync.replicas(默认值为 1)代表了正常写入生产者数据所需要的最少 ISR 个数 发送的 acks1 和 0 消息会出现丢失情况为了不丢失消息可配置生产者acksall min.insync.replicas 2
ISR 机制 ISR 中的副本都是与 Leader 同步的副本不在 ISR 中的Follower副本就被认为是没有资格的Follower 周期性地向 Leader 发送 FetchRequest 请求发送时间间隔配置在replica.fetch.wait.max.ms中默认值为 500每个分区的 Leader 负责维护 ISR 列表并将 ISR 的变更同步至 ZooKeeper被移出 ISR 的 Follower 会继续向 Leader 发 FetchRequest 请求试图再次跟上 Leader 重新进入 ISRISR 中所有副本都跟上了 Leader通常只有 ISR 里的成员才可能被选为 Leader
主从同步 1、Follower副本通过发送Fetch请求来同步Leader副本上的数据。LEOLog End Offset 对于Leader副本和每个Follower副本来说它们都有各自的LEOLEO是下一个要写入的消息的偏移量 HWHigh Watermark HW是分区中所有副本的已提交消息的最大偏移量。是分区中所有ISRIn-Sync Replicas副本的LEO中的最小值只要分区的Leader副本和至少一个Follower副本保持同步消费者就能看到所有已提交的消息即使Leader副本发生故障 确保了Kafka在分区的Leader副本发生故障时可以从ISR中选举出一个Follower副本作为新的Leader Unclean 领导者选举 当 Kafka 中unclean.leader.election.enable配置为 true(默认值为 false)且 ISR 中所有副本均宕机的情况下开启 Unclean 领导者选举可能会造成数据丢失但好处是它使得分区 Leader 副本一直存在不至于停止对外提供服务因此提升了高可用性
Leader 选举 故障恢复机制 「Kafka 从 0.8 版本开始引入了一套 Leader 选举及失败恢复机制」在集群所有 Broker 中选出一个 Controller负责各 Partition 的 Leader 选举以及 Replica 的重新分配Controller 集群中的 Controller 也会出现故障因此 Kafka 让所有 Broker 都在 ZooKeeper 的 Controller 节点上注册一个 Watcher。 当出现 Leader 故障后Controller 会将 Leader/Follower 的变动通知到需要为此作出响应的 Broker。Kafka 使用 ZooKeeper 存储 Broker、Topic 等状态数据Kafka 集群中的 Controller 和 Broker 会在 ZooKeeper 指定节点上注册 Watcher(事件监听器)以便在特定事件触发时由 ZooKeeper 将事件通知到对应 Broker当 Broker 发生故障后由 Controller 负责选举受影响 Partition 的新 Leader 并通知到相关 Broker
