1.11 Kafka的持久化
1、一个Topic可以认为是一类消息，每个topic将被分成多partition(区),每个partition在存储层面是append log文件。任何发布到此partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置称为offset（偏移量），partition是以文件的形式存储在文件系统中。
2、Logs文件根据broker中的配置要求,保留一定时间后删除来释放磁盘空间。
Kafka消息分区Partition图1-4
Partition：
Topic物理上的分组，一个 topic可以分为多个 partition，每个 partition 是一个有序的队列。partition中的每条消息都会被分配一个有序的 id（offset）。
3、为数据文件建索引：稀疏存储，每隔一定字节的数据建立一条索引。下图为一个partition的索引示意图：
Kafka消息分区Partition索引图1-5
1.12 Kafka的分布式实现：
Kafka分布式关系图1-6
Kafka生产环境关系图1-7
1.13 Kafka的通讯协议：
1、Kafka的Producer、Broker和Consumer之间采用的是一套自行设计基于TCP层的协议，根据业务需求定制，而非实现一套类似ProtocolBuffer的通用协议。
2、基本数据类型：（Kafka是基于Scala语言实现的，类型也是Scala中的数据类型）
定长数据类型：int8,int16,int32和int64，对应到Java中就是byte, short, int和long。
变长数据类型：bytes和string。变长的数据类型由两部分组成，分别是一个有符号整数N(表示内容的长度)和N个字节的内容。其中，N为-1表示内容为null。bytes的长度由int32表示，string的长度由int16表示。
数组：数组由两部分组成，分别是一个由int32类型的数字表示的数组长度N和N个元素。
3、Kafka通讯的基本单位是Request/Response。
4、基本结构：
5、通讯过程：
客户端打开与服务器端的Socket
往Socket写入一个int32的数字(数字表示这次发送的Request有多少字节)
服务器端先读出一个int32的整数从而获取这次Request的大小
然后读取对应字节数的数据从而得到Request的具体内容
服务器端处理了请求后，也用同样的方式来发送响应。
6、RequestMessage结构：
7、ResponseMessage结构：
Kafka采用是经典的Reactor(同步IO)模式，也就是1个Acceptor响应客户端的连接请求，N个Processor来读取数据，这种模式可以构建出高性能的服务器。
8、Message结构：
9、MessageSet结构：
MessageSet:用来组合多条Message，它在每条Message的基础上加上了Offset和MessageSize
MessageSet => [Offset MessageSize Message]
10、 Request/Respone和Message/MessageSet的关系：
Request/Response是通讯层的结构，和网络的7层模型对比的话，它类似于TCP层。
Message/MessageSet定义的是业务层的结构，类似于网络7层模型中的HTTP层。Message/MessageSet只是Request/Response的payload中的一种数据结构。
备注：Kafka的通讯协议中不含Schema，格式也比较简单，这样设计的好处是协议自身的Overhead小，再加上把多条Message放在一起做压缩，提高压缩比率，从而在网络上传输的数据量会少一些。
1.14 数据传输的事务定义：
1、at most once:最多一次,这个和JMS中”非持久化”消息类似.发送一次，无论成败，将不会重发。
at most once:消费者fetch消息,然后保存offset，然后处理消息;当client保存offset之后，但是在消息处理过程中出现了异常，导致部分消息未能继续处理.那么此后”未处理”的消息将不能被fetch到，这就是“atmost once”。
2、at least once:消息至少发送一次，如果消息未能接受成功，可能会重发，直到接收成功。
at least once:消费者fetch消息，然后处理消息，然后保存offset.如果消息处理成功之后，但是在保存offset阶段zookeeper异常导致保存操作未能执行成功，这就导致接下来再次fetch时可能获得上次已经处理过的消息，这就是“atleast once”，原因offset没有及时的提交给zookeeper，zookeeper恢复正常还是之前offset状态。
3、exactly once:消息只会发送一次。
exactly once: kafka中并没有严格的去实现(基于2阶段提交，事务)，我们认为这种策略在kafka中是没有必要的。
注：通常情况下“at-least-once”是我们首选。(相比at most once而言，重复接收数据总比丢失数据要好)。
二、消息队列之Kafka工作原理与安装介绍
2.1消息队列之Kafka工作原理 -- broker
2.2消息队列之Kafka工作原理 -- topic
2.3消息队列之Kafka工作原理 – partition
2.4消息队列之Kafka安装介绍
版本
Apache Kafka 与 Confluent Platform
Docker镜像 Confluent kafka 的docker镜像
客户端工具
Apache Kafka的Python客户端：kafka-python
Confluent kafka的Python客户端： confluent-kafka-python
git地址
使用文档
2.5消息队列之Kafka使用介绍
Kafka启动：
单节点单broker 单节点多broker
Kafka使用时的显著特征
分区之间是无序的，但分区内的消息是有序的
对于topic的消费，消费者的数量 应 不多于 该topic分区的数量，否则多余的消费者将必定无法接收到消息
一个消费者可同时消费多个topic
在订阅消费时，Kafka保证每条消息在同一个Consumer Group里只会被某一个Consumer消费
总结：掌握原理 活用文档 多实践
