kafka
1.高吞吐， 分布式，基于发布订阅的消息系统
2. Kafka应用场景简介
2.1.Kafka和其他组件比较，具有消息持久化、高吞吐、实时等特性，适用于离线和实时的消息消费，如网站活性跟踪、聚合统计系统运营数据（监控数据）、日志收集等大量数据的数据收集场景。
3.Kafka Topics
3.1.每条发布到Kafka的消息都有一个类别，这个类别被称为Topic，也可以理解为一个存储消息的队列。例如：天气作为一个Topic，每天的温度消息就可以存储在“天气”这个队列里。
3.2.图片中的蓝色框为Kafka的一个Topic，即可以理解为一个队列，每个格子代表一条消息。生产者产生的消息逐条放到Topic的末尾。消费者从左至右顺序读取消息，使用Offset来记录读取的位置。
4.Kafka Partition
4.1.每个Topic 都有一个或者多个Partitions构成。每个Partition都是有序且不可变的消息队列。引入Partition机制，保证了Kafka的高吞吐能力。
4.2.每个topic被分成多个partition(区),每个partition在存储层面对应一个log文件，log文件中记录了所有的消息数据。
4.3.引入Partition机制，保证了Kafka的高吞吐能力，因为Topic的多个Partition分布在不同的Kafka节点上，这样一来多个客户端（Producer和Consumer）就可以并发访问不同的节点对一个Topic进行消息的读写。
4.4.Topic的Partition数量可以在创建时配置。
4.5.Partition数量决定了每个Consumer group中并发消费者的最大数量。
5.Kafka Partition偏移量
5.1.每条消息在文件中的位置称为offset（偏移量），offset是一个long型数字，它唯一标记一条消息。消费者通过（offset、partition、topic）跟踪记录。
5.2.任何发布到此Partition的消息都会被直接追加到log文件的尾部。
6.Kafka Partition副本 (1)
7.副本特性：
7.1.副本以分区为单位。每个分区都有各自的主副本和从副本。
7.2.主副本叫做Leader，从副本叫做Follower。Follower通过拉取的方式从Leader中同步数据。
7.3.消费者和生产者都是从Leader中读写数据，不与Follower交互。
7.4.为了提高Kafka的容错性，Kafka支持Partition的复制策略，可以通过配置文件配置Partition的副本个数。Kafka针对Partition的复制同样需要选出一个Leader，同时由该Leader负责Partition的读写操作，其他的副本节点只是负责数据的同步。如果Leader失效，那么将会有其他follower来接管(成为新的Leader)，如果由于Follower自身的性能，或者网络原因导致同步的数据落后Leader太多，那么当Leader失效后，就不会将这个Follower选为Leader。由于Leader的Server承载了全部的请求压力,因此从集群的整体考虑,Kafka会将Leader均横的分散在每个实例上，来确保整体的性能稳定。一个Kafka集群各个节点间可能互为Leader和Flower。
8.Kafka Partition副本 (2)
8.1.Kafka中partition replication之间同步数据，从partition的leader复制数据到follower只需要一个线程(ReplicaFetcherThread)，实际上复制是follower(一个follower相当于consumer)主动从leader批量拉取消息的，这极大提高了吞吐量。
9.Kafka Partition副本 (3)
9.1.Kafka中每个Broker启动时都会创建一个副本管理服务(ReplicaManager)，该服务负责维护ReplicaFetcherThread与其他Broker链路连接关系。该Broker中存在的Follower partitions对应的leader partitions分布在不同的Broker上，这些Broker创建相同数量的ReplicaFetcherThread线程同步对应partition数据。Kafka中partition间复制数据是由follower(扮演consumer角色)主动向leader获取消息， follower每次读取消息都会更新HW状态（High Watermark，用于记录当前最新消息的标识）。每当Follower的partitions发生变更而影响leader所在Broker时，ReplicaManager就会新建或销毁相应的ReplicaFetcherThread。
9.2.简单的说就是，follower启动一线程用于同步leader数据。
10.Kafka Logs (1)
10.1.为了使得Kafka的吞吐率可以线性提高，物理上把Topic分成一个或多个Partition，每个Partition在物理上对应一个文件夹，该文件夹下存储这个Partition的所有消息和索引文件。
10.2.Kafka把Topic中一个Parition大文件分成多个小文件段，通过多个小文件段，就容易定期清除或删除已经消费完文件，减少磁盘占用。
11.Kafka Logs (2)
11.1.segment file组成：由2大部分组成，分别为index file和data file，此2个文件一 一对应，成对出现，后缀“.index”和“.log”分别表示为segment索引文件、数据文件。
11.2.segment文件命名规则：partion全局的第一个segment从0开始，后续每个segment文件名为上一个全局partion的最大offset(偏移message数)。数值最大为64位long大小，19位数字字符长度，没有数字用0填充。
11.3.Kafka的存储布局非常简单。Topic的每个分区对应一个逻辑日志。物理上，一个日志为相同大小的一组分段文件。每次生产者发布消息到一个分区，代理就将消息追加到最后一个段文件中。当发布的消息数量达到设定值或者经过一定的时间后，段文件真正写入磁盘中。写入完成后，消息公开给消费者。同一个topic下有不同分区，每个分区下面会划分为多个文件，只有一个当前文件在写，其他文件只读。当写满一个文件（写满的意思是达到设定值）后，新建一个空文件用来写，老的文件切换为只读。文件的命名以起始偏移量来命名。
11.4.一个日志文件默认1G，当达到1G的时候，创建新的log文件和index文件。如果参数设置过小，则会产生大量的log文件和index文件，系统在启动时，需要加载大量index到内存，占用大量句柄。如果设置太大，分段文件比较少，不利于快速查找消息。
12.Kafka Logs (3)
12.1.通过索引信息可以快速定位message。
12.2.使index元数据全部映射到memory，可以避免segment file的index数据IO磁盘操作。
12.3.索引文件稀疏存储，可以大幅降低index文件元数据占用空间大小。
12.4.稀疏存储，即将原来的完整数据，只间隔的选择多条进行存储。例如：针对100条数据，只存储了1、20、40、60、80条的数据位置，这样如果要查找第23条数据，则直接在index中找到20的位置，再偏移3条即得到。
13.Kafka Message
13.1.Message即Kafka中的一条消息。
14.Kafka Log Cleanup (1)
14.1.日志的清理方式有两种：delete 和 compact。
14.2.删除的阈值有两种：过期的时间和分区内总日志大小。
14.3.对于传统的message queue而言，一般会删除已经被消费的消息，而Kafka集群会保留所有的消息，无论其被消费与否。当然，因为磁盘限制，不可能永久保留所有数据（实际上也没必要），因此Kafka提供两种策略删除旧数据。
15.Kafka Log Cleanup (2)
15.1.Compact的清理方式是指至少保留每个key值最新的value消息。例如：一条消息包含Key和Value两个内容，Key为K1的有3条消息，其值分别为V1、V3、V4，则采用Compact的清理方式时，只保留最新的那条消息，即值为V4的消息。（如何判断哪条消息为最新消息，因为消息是顺序存储的，offset大的即为后存入的、最新的消息）。
15.2.简单的说：只保留最新版数据。
16.Kafka数据可靠性
16.1.Kafka所有消息都会被持久化到硬盘中，同时Kafka通过对Topic Partition设置Replication来保障数据可靠。
17.Message Delivery Semantics
17.1.仅有一次（Exactly Once） ：kafka尚未实现。
17.2.消息传输保障通常有以下三种：
17.3.最多一次（At Most Once）
17.4.消息可能丢失。
17.5.消息不会重复发送和处理。
17.6.最少一次（At Lease Once）
17.7.消息不会丢失。
17.8.消息可能会重复发送和处理。
17.9.仅有一次（Exactly Once）
17.10.消息不会丢失。
17.11.消息仅被处理一次。
18.Kafka消息传输
18.1.Kafka消息传输保障机制，通过配置不同的消息发送模式来保障消息传输，进而满足不同的可靠性要求应用场景。
18.2.同步发送：client每写一条，发送一条到broker。可靠性高，常用。
18.3.异步发送：client先将数据写入一buffer，待写入达到一定条数后，将buffer内数据一次性发送到broker。容易造成数据丢失，一般不用。
18.4.同步复制、异步复制与同步发送、异步发送原理相同。常用同步发送带确认+同步复制。
19.Kafka Cluster Mirroring
19.1.Kafka Cluster Mirroring是Kafka跨集群数据同步方案，通过Kafka内置的MirrorMaker工具来实现。
19.2.图中展示了如何从源Kafka集群（Source Cluster）到目标Kafka集群(Target Cluster)同步数据，即通过MirrorMaker工具中的Consumer从源集群消费数据，然后再通过内置的Producer将数据重新发送到目标集群。
20.Producer写数据
20.1.Producer连接任意存活的Broker，请求制定Topic、Partition的Leader元数据信息，然后直接与对应的Broker直接连接，发布数据。
21.Consumer读数据
21.1.Consumer连接指定TopicPartition所在的LeaderBroker，用主动获取方式从Kafka中获取消息。
22.Kafka架构与功能
22.1.一个典型的Kafka集群中包含若干Producer（可以是web前端产生的Page View，或者是服务器日志，系统CPU、Memory等），若干Broker（Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高），若干Consumer，以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置，选举Leader，以及在Consumer发生变化时进行rebalance。Producer使用push模式将消息发布到Broker，Consumer使用pull模式从Broker订阅并消费消息。
22.2.Broker：Kafka集群包含一个或多个服务实例，这些服务实例被称为Broker。
22.3.Producer：负责发布消息到Kafka Broker。
22.4.Consumer：消息消费者，从Kafka Broker读取消息的客户端。
