浅谈分布式消息技术 Kafka.docxVIP

浅谈分布式消息技术 Kafka 2021-09-02 Kafka的基本引见 Kafka是最后由Linkedin公司开发，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统（也可以当做MQ系统），常见可以用于web/nginx日志、访问日志，消息服务等等，Linkedin于2021年贡献给了Apache基金会并成为顶级开源项目。 次要应用场景是：日志收集系统和消息系统。 Kafka次要设计目标如下： 以时间简单度为O(1)的方式供应消息长久化力量，即便对TB级以上数据也能保证常数时间的访问功能。 高吞吐率。即便在格外廉价的商用机器上也能做到单机支持每秒100K条消息的传输。 支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息挨次传输。 同时支持离线数据处理和实时数据处理。 Kafka的设计原理分析 一个典型的kafka集群中包含若干producer，若干broker，若干consumer，以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置，选举leader，以及在consumer group发生变化时进行ducer使用push模式将消息发布到broker，consumer使用pull模式从broker订阅并消费消息。 　 Kafka公用术语： Broker：消息两头件处理结点，一个Kafka节点就是一个broker，多个broker可以组成一个Kafka集群。 Topic：一类消息，Kafka集群能够同时担任多个topic的分发。 Partition：topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列。 Segment：partition物理上由多个segment组成。 offset：每个partition都由一系列有序的、不行变的消息组成，这些消息被连续的追加到partition中。partition中的每个消息都有一个连续的序列号叫做offset，用于partition独一标识一条消息。 Producer：担任发布消息到Kafka broker。 Consumer：消息消费者，向Kafka broker读取消息的客户端。 Consumer Group：每个Consumer属于一个特定的Consumer Group。 Kafka数据传输的事务特点 at most once：最多一次，这个和JMS中非长久化消息类似，发送一次，无论成败，将不会重发。消费者fetch消息，然后保存offset，然后处理消息；当client保存offset之后，但是在消息处理过程中消灭了特别，导致部分消息未能连续处理。那么此后未处理的消息将不能被fetch到，这就是at most once。 at least once：消息至少发送一次，假如消息未能接受成功，可能会重发，直到接收成功。消费者fetch消息，然后处理消息，然后保存offset。假如消息处理成功之后，但是在保存offset阶段zookeeper特别导致保存操作未能执行成功，这就导致接下来再次fetch时可能获得上次已经处理过的消息，这就是at least once，缘由offset没有准时的提交给zookeeper，zookeeper恢复正常还是之前offset形态。 exactly once：消息只会发送一次。kafka中并没有严格的去实现（基于2阶段提交），我们认为这种策略在kafka中是没有必要的。 通常情况下at-least-once是我们首选。 Kafka消息存储格式 Topic Partition 一个topic可以认为一个一类消息，每个topic将被分成多个partition，每个partition在存储层面是append log文件。 在Kafka文件存储中，同一个topic下有多个不同partition，每个partition为一个名目，partiton命名规章为topic名称+有序序号，第一个partiton序号从0开头，序号最大值为partitions数量减1。 每个partion（名目）相当于一个巨型文件被平均安排到多个大小相等segment（段）数据文件中。但每个段segment file消息数量不肯定相等，这种特性便利old segment file快速被删除。 每个partiton只需要支持挨次读写就行了，segment文件生命周期由服务端配置参数打算。 这样做的好处就是能快速删除无用文件，有效提高磁盘利用率。 segment file组成：由2大部分组成，分别为index file和data file，此2个文件逐一对应，成对消灭，后缀.index和“.log”分别表示为segme