图解Kafka设计原理解析.docxVIP

图解Kafka设计原理解析 简约来说，消息队列是存放消息的容器。客户端可以将消息发送到消息服务器，也可以从消息服务器猎取消息。 问题导读: 为什么需要消息系统? kafka架构? kafka如何存储消息? Producer如何发送消息? Consumer如何消费消息? Offset如何保存? 如何保证消息不被反复消费? 如何保证消息的牢靠性传输? 如何保证消息的挨次性? 为什么需要消息系统？ 削峰 数据库的处理力量是有限的，在峰值期，过多的恳求落到后台，一旦超过系统的处理力量，可能会使系统挂掉。 如上图所是，系统的处理力量是2k/s，MQ处理力量是8k/s，峰值恳求5k/s，MQ的处理力量远远大于数据库，在高峰期，恳求可以先积压在MQ中，系统可以依据本身的处理力量以2k/s的速度消费这些恳求。这样等高峰期一过，恳求可能只要100/s，系统可以很快的消费掉积压在MQ中的恳求。 留意，上面的恳求指的是写恳求，查询恳求一般通过缓存处理。 解耦 如下场景，S系统与A、B、C系统紧密耦合。由于需求变动，A系统修改了相关代码，S系统也需要调整A相关的代码；过几天，C系统需要删除，S紧跟着删除C相关代码；又过了几天，需要新增D系统，S系统又要添加与D相关的代码；再过几天，程序猿疯了... 这样各个系统紧密耦合，不利于维护，也不利于扩展。现在引入MQ，A系统变动，A本人修改本人的代码即可；C系统删除，直接取消订阅；D系统新增，订阅相关消息即可。 这样通过引入消息两头件，使各个系统都与MQ交互，从而避开它们之间的错综简单的调用关系。 Kafka架构 相关概念 1. broker kafka 集群中包含的服务器。 2. producer消息生产者。 3. consumer消息消费者 4. consumer group每个 consumer 都属于一个 consumer group，每条消息只能被 consumer group 中的一个 consumer 消费，但可以被多个 consumer group 消费。 5. topic消息的类别。每条消息都属于某个 topic，不同的 topic 之间是相互独立的，即 kafka 是面对 topic 的。 6. partition每个 topic 分为多个 partition，partition 是 kafka 安排的单位。kafka 物理上的概念，相当于一个名目，名目下的日志文件构成这个 partition。 7. replicapartition 的副本，保障 partition 的高可用。 8. leaderreplica 中的一个角色， producer 和 consumer 只跟 leader 交互。 9. followerreplica 中的一个角色，从 leader 中复制数据。 10. controllerkafka 集群中的其中一个服务器，用来进行 leader election 以及 各种 failover。 12. zookeeperkafka 通过 zookeeper 来存储集群的 meta 信息。 Topic and Logs Message是依据topic来组织的，每个topic可以分成多个partition（对应perties/num.partitions）。partition是一个挨次的追加日志，属于挨次写磁盘（挨次写磁盘效率比随机写内存要高，保障 kafka 吞吐率）。其结构如下 perties/num.partitions 表示文件 perties 中的 num.partitions 配置项，下同 partition中的每条记录（message）包含三个属性：offset, messageSize和data。其中offset表示消息偏移量；messageSize表示消息的大小；data表示消息的具体内容。 partition是以文件的方式存储在文件系统中，位置由perties/log.dirs指定，其命名规章为-。 比如，topic为page_visits的消息，分为5个partition，其名目结构为： partition可能位于不同的broker上 partition是分段的，每个段是一个segment文件。segment的常用配置有： #perties #segment 文件的大小，默认为 1Glog.segment.bytes=102410241024#滚动生成新的 segment 文件的最大时长log.roll.hours=247#segment 文件保留的最大时长，超时将被删除log.retention.hours=247 partition名目下包括了数据文件和索引文件，下图是某个partition的名