kafka详解
概述
Kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统（也可以当做MQ系统），常见可以用于web/nginx日志、访问日志，消息服务等等
应用场景
- 日志收集
- 业务解耦：添加中间件，把业务分开分开（解耦）通过中间件来进行访问
- 流量削峰
消息中间件的两种通信模式
点对点：消息持久化到一个队列，将有一个或多个消费者消费队列中的数据。但是一条消息只能被消费一次。当一个消费者消费了队列中的某条数据之后，该条数据则从消息队列中删除。该模式即使有多个消费者同时消费数据，也能保证数据处理的顺序。
发布—订阅：消息被持久化到一个topic中。与点对点消息系统不同的是，消费者可以订阅一个或多个topic，消费者可以消费该topic中所有的数据，同一条数据可以被多个消费者消费，数据被消费后不会立马删除。在发布-订阅消息系统中，消息的生产者称为发布者，消费者称为订阅者。
broker
Kafka 集群包含一个或多个服务器，服务器节点称为broker。
- broker存储topic的数据。如果某topic有N个partition，集群有N个broker，那么每个broker存储该topic的一个partition。
- 如果某topic有N个partition，集群有(N+M)个broker，那么其中有N个broker存储该topic的一个partition，剩下的M个broker不存储该topic的partition数据。
- 如果某topic有N个partition，集群中broker数目少于N个，那么一个broker存储该topic的一个或多个partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致Kafka集群数据不均衡
topic
每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。，主题，消息的类别，比如nginx，mysql日志给不同的主题，就是不同的类型（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）
partition
分区，提高吞吐量，提高并发，一般几个broker就设置几个partition，真正存放消息的地方。
topic中的数据分割为一个或多个partition。每个topic至少有一个partition。每个partition中的数据使用多个segment文件存储。partition中的数据是有序的，不同partition间的数据丢失了数据的顺序。如果topic有多个partition，消费数据时就不能保证数据的顺序。在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1。
一个partition
对顺序有要求的话，Kafka保证一个Partition内的消息的有序性。，多个partition顺序会被打乱
多个partition
提高并发
Producer
生产者即数据的发布者，该角色将消息发布到Kafka的topic中。broker接收到生产者发送的消息后，broker将该消息追加到当前用于追加数据的segment文件中。生产者发送的消息，存储到一个partition中，生产者也可以指定数据存储的partition
Consumer
消费者可以从broker中读取数据。消费者可以消费多个topic中的数据。
Consumer Group
每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。
消费者组是逻辑上的一个订阅者。
replica
副本----就是完整的分区备份，用来实现kafka里的高可用
leader和follower
根据replica来的，如果有多个，partition和这些replica之间就要有一个leader（一台机器一个）
多个replica，副本加原本的partition，follower是N-1个
leader
每个partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责数据的读写的partition。
follower
Follower跟随Leader，所有写请求都通过Leader路由，数据变更会广播给所有Follower，Follower与Leader保持数据同步。如果Leader失效，则从Follower中选举出一个新的Leader。当Follower与Leader挂掉、卡住或者同步太慢，leader会把这个follower从“in sync replicas”（ISR）列表中删除，重新创建一个Follower。
segment
每一个partition的数据都会由很多segment存储，每一个segment由一个 index和log文件组成
分出多个segment便于做数据清理。
kafka可以按照两个维度清理数据
- 按时间kafka/conf/server.properties（log.retention.hours=168）
- 按大小kafka/conf/server.properties（log.segment.bytes=1073741824）
任意一个条件满足，都可以触发日志清理
ISR（in-sync-replica）
集合列表 ---- 需要同步的follower集合
比如有5个副本：1个leader 4个follower
有一条消息来了，leader怎么知道要同步到那些副本，根据ISR，如果一个follower挂掉了，就被从ISR种剔除，重新加载上来后自己再进行同步
。 如果一个follower卡住了，也会被剔除，这个是通过 replica.lag.time.max.ms 参数配置的。只有 ISR 里的成员才有被选为 leader 的可能。
所以当 Leader 挂掉了，而且 unclean.leader.election.enable=false 的情况下，Kafka 会从 ISR 列表中选择第一个 follower 作为新的 Leader，因为这个分区拥有最新的已经 committed 的消息。通过这个可以保证已经 committed 的消息的数据可靠性。
如果有一个机器宕机，后续启动之后想要重新加入ISR，必须同步到HW（最高水位线）值才能加入进来
生产者生产数据流程
生产者 —》leader（根据ISR）—》follower
如果leader挂掉了，那就会在ISR中选一个follower当leader（一般是列表中第一个）
kafka如何保持高可用：多个broker+多个partition+多个replica
kafka如何保持数据可靠性和数据一致性
数据可靠性
Producer往Broker发送消息
当producer要把生产的数据给到kafka对应的主题，kafka的每个主题都对应了多个partition，每个partition下面又有多个replica，为了让用户设置数据可靠性，kafka在Producer里面提供了消息确认机制（通过配置来决定怎么算消息发送成功），可以在定义Producer时通过ack指定（在 0.8.2.X 版本之前是通过 request.required.acks 参数设置的），这个参数支持三种值：
- ack为0：生产者不需要接收响应，发完就发下一条，不安全，会导致数据丢失
- ack为1（默认）：leader收到就会给生产者发送响应，失败Producer会受到错误响应，为避免数据丢失，Producer会重发消息
- 如果一个没有收到消息的节点成为新Leader，消息还是会丢失
- ack为-1：等待ISR列表中的每一个副本都收到，才给生产者响应，最安全，可以保证不止一个服务器收到消息，就算有服务器发生崩溃，整个集群依然可以运行，但效率不高
另外，Producer 发送消息还可以选择同步（默认，通过 producer.type=sync 配置） 或者异步（producer.type=async）模式。如果设置成异步，虽然会极大的提高消息发送的性能，但是这样会增加丢失数据的风险。如果需要确保消息的可靠性，必须将 producer.type 设置为 sync。
Consumer从Broker拉去消息
消费者要消费数据时，引入了High Water Mark机制，木桶效应，消费者只能消费ISR列表里偏移量最少的副本的消息数量。
Topic分区副本
kafka可以保证单个分区里的数据是有序的，分区可以在线（可用），也可以离线（不可用）。在众多的分区副本里面有一个副本是 Leader，其余的副本是 follower，所有的读写操作都是经过 Leader 进行的，同时 follower 会定期地去 leader 上复制数据。当 Leader 挂掉之后，其中一个 follower 会重新成为新的 Leader。通过分区副本，引入了数据冗余，同时也提供了 Kafka 的数据可靠性。
**kafka的分区多replica架构是kafka可靠性保证的核心，把消息写入多个副本可以使 Kafka 在发生崩溃时仍能保证消息的持久性。**如果broker数量和replica一致，理论上可以坏掉n-1台
leader选举
每个分区的leader都会维护一个ISR列表，ISR列表中就是follower副本的Broker编号，具体ISR见上。
生产者跟任何一台broker连接都可以，broker会返回当前强求副本leader的信息，最后生产者再跟leader交互
738
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
