安装Kafka
1.安装Zookeeper
Kafka内置了Zookeeper，但是独立安装一个完整的Zookeeper更好一些
2.安装Kafka Broker
下载地址: http://kafka.apache.org/downloads
多节点
config/server-1.properties: <div> broker.id=1 </div><div> listeners=PLAINTEXT://:9093 </div><div> log.dirs=/tmp/kafka-logs-1 </div><div>config/server-2.properties: </div><div> broker.id=2 </div><div> listeners=PLAINTEXT://:9094 </div><div> log.dirs=/tmp/kafka-logs-2</div>
> tar -xzf kafka_2.11-2.1.0.tgz <div>> cd kafka_2.11-2.1.0 </div><div>> bin/zookeeper-server-start.sh config/zookeeper.properties<br>> bin/kafka-server-start.sh config/server.properties(单节点)<br></div>
4.测试
1.创建Kafka Topic
> bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test
2.查看Topic列表
> bin/kafka-topics.sh --list --zookeeper localhost:2181
3.创建生产者，并写入消息
> bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test <div>This is a message </div><div>This is another message</div>
4.创建消费者，订阅消息
> bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test --from-beginning <div>This is a message </div><div>This is another message</div>
5.更多参考
https://kafka.apache.org/quickstart
数据丢失的几种可能性
生产者写入时的数据丢失
1.提交策略不当，数据会丢失
2.提交时偏移量处理不正确，数据会丢失
3.关闭了不完全首领选举，acks=all，但是生产者写入数据时，首领挂了，正在重新选举中，Kafka会返回首领不可用的响应，但是生产者没能正确的处理——这不是broker可靠性问题，因为broker并没有收到这个消息，也不是一致性问题，因为消费者也没读到这个消息
Kafka接收数据时的数据丢失
1.副本还未同步，但是使用了首领接收即确认(acks=1)，<div>首领确认后宕机，数据会丢失</div>
举例子：副本3个，禁用不完全首领选举，acks=1，生产者写入消息，首领接收并写入成功，返回“写入成功”响应，然后首领宕机，此时跟随副本还没有复制数据，但是他们会被认为是同步的（判断一个副本不同需要一小段时间），其中一个副本变成了新首领，因为消息并没有写入，所以数据丢失了
2.如果使用了不完全首领选举，数据可能会丢失
运维层的数据丢失
1.所有节点全部宕机，数据会丢失
2.acks=0
发送的对象无法序列化<br>
网卡故障
分区离线或者整个集群长时间不可用
核心概念
定义：基于发布与订阅的消息系统
主题和分区
消息：Kafka数据单元被称之为“消息”
Kafka的消息通过“主题”进行分类，一个主题可以跨多个服务器
“批次” ： 就是属于同一个主题和分区的一组消息
主题可以被分为若干个分区，一个分区就是一个提交日志，Kafka通过分区来实现数据的冗余和伸缩，分区可以分布在不同的服务器
消息的写入与读取： 消息以追加的方式写入分区然后以先入先出的顺序读取
消息的顺序：一个主题包含几个分区，因此无法在整个主题内保证消息的顺序，但是可以保证消息在单个分区内的顺序
流的概念： 人们把一个主题的数据看成一个流，不管它有多少个分区，流是一组从生产者移动到消费者的数据
存储与传输
数据按一定的顺序持久化保存，可以按需读取
单个消息传输于网络，会导致较大的网络开销；消息分批传输可以减少网络开销，但是在时间和吞吐量上要做权衡，批次越大，单位时间内处理的消息就越多，单个消息的传输时间就越长，批次数据会被压缩，提升传输和存储能力，但要做更多的计算处理
Kafka的数据存储是基于二进制字节码的，晦涩难懂，所以有了Schema便于让人理解，通用的Avro作为序列化工具，同时也支持Json、String等，参考序列化类库和文档
Kafka是基于磁盘的数据存储，这也就是说Kafka允许消费者非实时的读取消息；消息被提交到磁盘，根据设置的保留规则进行保存，每个主题可以设置单独的保留规则，
生产者和消费者
Kafka的基本类型客户端：生产者和消费者；生产者创建消息，默认情况下，一个消息会被发布到一个特定的主题上，生产者在默认情况下把消息均衡的分布到主题的所有分区上，而不关心特定消息会被写到哪个分区，不过也可以用分区器将其映射到指定的分区；
更高级的客户端 ：用于数据集成的Kafka Connect API和用于流式处理的Kafka Streams；<br>
多个生产者： kafka可以无缝的支持多个生产者，不管客户端在使用单个主题还是多个主题
多个消费者： Kafka支持多个消费者从一个单独的消息流上读取数据，而且消费者之间互不影响；其他的消息队列的消息一旦被一个客户端读取，其他客户端就无法再读取它。多个消费者可以组成一个群组，他们共享一个消息流，并保证整个群组对每个给定的消息只处理一次。
消费者群组：消费者是消费者群组的一部分，也就是说会有一个或多个消费者共同读取一个主题；一个群组里的消费者订阅的是同一个主题，每个消费者接收主题一部分分区的消息（消费者的个数一定小于等于分区数）
消费所有权： 群组保证每个分区只能被一个消费者使用，消费者与分区之间的映射通常被称为消费者对分区的所有权关系
偏移量： 他是一个不断递增的整数值，在创建消息时，kafka会把它添加到消息里，在给定的分区里，每个消息的偏移量都是唯一的，消费者把每个分区最后读取的消息偏移量保存在Zookeeper或kafka上，如果消费者关闭或者重启，它的读取状态不会丢失
Broker和集群
一个独立的kafka服务器被称为broker
broker接收来自生产者的消息，为消息设置偏移量，并提交消息到磁盘保存；
Broker为消费者提供服务，对读取分区的请求做出响应，返回已经提交到磁盘上的消息
broker是集群的组成部分，每个集群都有一个broker同时充当了“集群控制器”的角色（自动从活跃成员中选举出来）
在集群中一个分区从属于一个broker，该broker被称为分区的首领；一个分区可以分配给多个broker，这时候会发生分区复制
保留消息： 是Kafka的一个重要特性，Kafka默认的消息保留策略是：要么保留一段时间(比如7天)，要么保留到消息达到一定大小的字节数（比如10GB），如果达到任意一个阀值，旧消息就会被删除。
多集群： 随着Kafka数量的增加，基于以下几点原因，最好使用多个集群：1.数据类型分离 2.安全需求隔离 3.多数据中心（灾难恢复）
多集群直接的消息复制： Kafka提供了一个叫做MirrorMaker的工具，可以用它来实现集群间的消息复制，其核心组件包含了一个生产者和一个消费者，两者之间通过一个队列相连。
为什么选择Kafka
1.多个生产者： Kafka可以无缝的支持多个生产者，不管客户端在使用单个主题还是多个主题。所以它适合用来从多个前端系统收集数据，并以统一的格式对外提供数据
2.多个消费者： kafka支持多个消费者从一个单独的消息流上读取数据，而且消费者之间互不影响；多个消费者可以组成一个群组，它们共享一个消息流，并保证整个群组对每个给定的消息只处理一次。其它队列系统的消息一旦被一个客户端读取，其它客户端就无法再读取它。
3.基于磁盘的数据存储： Kafka允许消费者非实时的读取消息，这归功于Kafka的数据保留特性，消息被提交到磁盘，根据设置的保留规则进行保存；每个主题可以设置单独的保留规则，以便满足不同消费者的需求，各个主题可以保留不同数量的消息。
4.伸缩性： Kafka可以单点提供服务，也可以集群提供服务，甚至上百个broker
5.高性能： 通过横向扩展生产者、消费者、broker，kafka可以轻松处理巨大的消息流，在处理数据的同时，他还能保证亚秒级的消息延迟
Kafka的可靠性
可靠性保证
1.Kafka可以保证分区消息的顺序；如果同一个生产者往同一个分区写入消息，而且消息B在消息A之后写入，那么Kafka是可以保证消息B的偏移量一定比消息A的偏移量大
2.消息的“已提交”
只有当消息被写入分区的所有同步副本时（但不一定要写入磁盘），它才被认为是“已提交”的
消息的确认；不同类型确认
消息被完全提交时确认
acks=all
与min.insync.replicas参数结合，决定返回确认时要至少有多个副本能够接到消息，这是最保险的，也是最慢的
上述方法想加速可以使用异步和大批次来加速，但是还是会降低吞吐量
消息被写入首领副本时的确认
acks=1
首领在收到消息并把它写入到分区数据文件时，返回确认或者错误
这时数据是否丢失，取决于生产者能否正确处理恰好碰到首领选举时LeaderNotAvailableException异常<div>以及如果遇到了首领确认后，未复制给跟随节点就宕机了，也会丢失数据</div>
消息被发送到网络时的确认
acks=0；如果生产者通过网络把消息发送出去，就认为消息已经写入kafka
数据丢失
发送的对象无法序列化
网卡故障
分区离线或者整个集群长时间不可用
基准测试
运行速度很快，所以经常使用这种模式做基准测试
3.只要有一个副本是活跃的，那么已经提交的消息就不会丢失
4.消费者只能读取已提交的消息
复制
Kafka的复制机制和分区的多副本架构是Kafka可靠性保证的核心
副本的概念
跟随副本
1.保持和首领副本同步，但是不一定每个副本都会同步，比如出现异常
2.首领副本故障会从跟随副本中选举新的
同步副本
数据最实时更新的，已经更新的副本，并且是存活状态
首领副本或者的时候，它一定是同步的，跟随副本正常情况下也是同步副本，但是出现网络延迟、挂掉，就都不是同步副本
复习:主题—>多个分区—>分区内有序—>一个分区多个副本—>其中一个副本是首领—>所有的事件都直接发送给首领或者直接从首领副本读取事件—>其他副本只需要和首领副本保持同步—>首领副本故障，重新选举一个新的副本作为首领
跟随者副本需要满足的条件
1.与Zookeeper之间有一个活跃的会话，也就是说，它在过去的6s内向Zookeeper发送过心跳
2.在过去的10s内从首领那里获取过信息
3.在过去的10s内从首领获取过最新的消息；光从首领获取消息是不够的，它还必须是几乎零延迟的
end：如果不能满足上述的任何一点，就认为它是不同步的，这是就需要重新与zookeeper重新建立连接
supplement：如果一个或多个副本在同步和非同步状态之间快速切换，说明集群内部出现了问题，通常是java不恰当的GC导致；不恰当的GC配置会导致几秒的停顿，从而让Broker和zookeeper断开连接
性能影响：一个滞后的同步副本会导致生产者和消费者变慢；如果副本不需要同步了那么对性能无影响
broker配置
可靠性配置:
Kafka有3个配置参数会影响Kafka消息存储的可靠性
<br>
配置可以应用在broker级别，用于控制所有主题的行为
配置可以应用在主题级别，用于控制个别主题行为
配置细节
1.复制系数
主题级别的配置参数是replication.factor
broker级别的，可以通过default.replication.factor来配置自动创建的主题
复制系数小于等于broker节点数，同时具有相对应的副本数，也就是会占用对应N倍的磁盘空间
复制系数如果为1会出现broker重启或者停止的时候，主题不可用
如果复制系数为2，表面看是可以容忍1个broker失效，但是这时候还可能导致集群不稳定，迫使重启另一个broker——集群控制器，这时候其实服务也是不可用的
默认的复制系数为3
容灾的再思考，如何分布broker
不同的主机？不同的机架（broker.rack）?不同的地域
2.不完全的首领选举
问题产生的原因
场景一
分区有3个副本，首先跟随副本都不可用，这时生产者继续向首领写入数据，然后首领也不可用了，这时，如果之前的跟随者重启，它就成了分区的唯一不同步副本
场景二
分区有3个副本，因为网络问题，两个跟随副本复制消息滞后，所以他们尽管在复制，但是已经不同步了，首领做为同步副本继续接收，这是如果首领不可用，另外两个副本也就无法变成同步了
两难的选择
1.数据丢失和数据不一致？
如果不同的副本可以被提升为新首领，那么在这个副本变为不同步后写入旧首领的消息会全部丢失，导致数据不一致
2.服务一段时间的不可用？
如果不同步的副本不能被提升为新首领，那么分区在旧首领恢复之前是不可用的
配置: unclean.leader.election.enable=true/false
true 允许新副本成为首领，需要承担数据丢失风险
false 对数据的一致性有高质量的要求，需要承担服务不可用的风险——可用性降低
3.最少同步副本
在主题级别和broker级别，这个参数都叫min.insync.replicas
举个例子：如果当前参数配置为2，然后一共有3个broker；那么如果一个跟随副本挂了，另一个跟随副本还能正常同步，此时系统还是OK的，因为满足配置，但是如果2个跟随副本都挂了，此时就不满足配置，生产者再继续写入数据就会收到NotEnoughReplicasException,但是消费者是可以读数据的，也就是说此时整个集群变成了只读的，什么时候恢复呢，也就是让另外两个或者有新的节点恢复成可用的。
在可靠的系统里使用生产者
不同的确认模式的异同
生产者的重试次数
生产者需要处理的错误
1.可以自动处理的错误
2.需要手动处理的错误
在可靠的系统里使用消费者
验证系统可靠性
配置验证
应用程序验证
在生产环境监控可靠性
深入Kafka
kafka集群成员关系
Kafka使用Zookeeper来维护集群成员关系
每个Broker有一个唯一的标识符，id,可以主动配置，可以自动生成
如果启动了两个相同brokerId的节点，那么后启动的会报错，
在Zookeeper的 /brokers/ids路径下注册
broker停机、出现网络分区、长时间垃圾回收停顿时，broker会从Zookeeper上断开连接
再关闭一个节点之后，用相同的ID启动一个全新的节点，那么这个节点将具有和旧的节点相同的分区和主题
控制器
复制
物理存储
分区分配
文件管理
文件格式
索引
清理
清理的工作原理
被删除的事件
何时会清理主题
