Kafka_kafka每秒吞吐量是多大
赞
踩
概述
Kafka是一个分布式的、可分区的、可复制的消息系统。
Kafka特点
①高吞吐量：Kafka每秒可以生产约25万消息（50MB），每秒处理 55 万消息（110 MB）
②持久化数据存储：可进行持久化操作。将消息持久化到磁盘，因此可用于批量消费，例如 ETL，以及实时应用程序。通过将数据持久化到硬盘以及 replication 防止数据丢失。
③分布式系统易于扩展：所有的 producer、broker 和 consumer 都会有多个，均为分布式的。无需停机即可扩展机器。
④ 客户端状态维护：消息被处理的状态是在 客户 端维护，而不是由 服务端维护。减轻服务器端的压力，为客户端会话管理提供了更好的灵活性。
Topic–主题
一个topic是对一组消息的归纳。
在一个Kafka集群中，可以创建多个topic主题，以topic主题为单位管理消息，Kafka中多个topic主题之间是互相隔离、互不影响。
Partition分区
Kafka的topic主题中还可以划分出若干的分区。Kafka以分区为单位对主题中的数据实现多副本并进行分布式存储。利用分区机制保证了每个分区的数据量不会太大，可以在单个服务上保存。分区通过多副本实现了Kafka的负载均衡及失败恢复。另外每个分区可以单独发布和消费，为并发操作topic提供了一种可能。
offset–序号
分区中的每个消息都有一个连续的序列号叫做offset,用来在分区中唯一的标识这个消息。
每个分区都由一系列有序的、不可变的消息组成，这些消息被连续的追加到分区中。在一个可配置的时间段内，Kafka集群保留所有发布的消息，不管这些消息有没有被消费。（可以设置消息的保存策略，指定保存期限，在期限到来之前数据会一直存在，无论是否被消费过，而当保存期限结束，消息会被连续的擦除，释放空间）
这一系列的机制，保证了Kafka中的数据是连续的读写磁盘，保障了性能，从而实现了Kafka的性能和数据量无关,只和磁盘性能相关
Replication–副本
每个分区都可以有若干个副本，这些副本分布式的存放在不同的服务器中，共同处理请求提升性能，并使Kafka具备了容错能力。
为了保证数据的一致性，若干副本中会有一个成为leader负责读写操作，而其他副本成为follower负责同步leader的数据，对外只提供读的能力。
Kafka中不是以broker为单位划分leader，follower，而是以分区副本为单位划分。这样，集群中的每个broker是其持有的一部分分区的leader和另一部分分区的follower，从而将写入的压力分摊在集群上不同broker中，提升性能。
Producer
它会生产数据到指定的topic中，默认采用负载均衡机制随机选择分区，如果需要可以通过特定的分区函数选择分区，指定发布到哪个分区。
Cosumer
在KafKa消费的中默认有两种消费方式：
①发布订阅模式：在这种模式下所有的消费者共享分区中的所有数据，而且各个消费者之间的数据获取互不影响。
②队列模式：在队列模式下各个消费者获取数据是互斥的，互相竞争的。
在生产环境下我们通常混合使用这两种模式。在Kafka中可以将多个消费者组成一个消费者组。在组内，多个消费者处于竞争状态，一个消息只能被组内的一个消费者消费到。在多个组之间，同一份消息会同时被多个消费者组各自消费到，形成共享状态。
Kafka的存储策略
Kafka通过topic分主题存放数据，而topic中又有很多的分区，分区还可以有多个副本。在分区内部，还存在一个个的segment（在分区对应的文件夹下产生的文件）。一个分区会被划分成大小相等的若干segment，既保证了每个分区中不会产生体积过大的文件，又可以基于这些segment文件进行历史数据的删除，从而提高效率。
一个segment由一个**.log文件（存放数据）和一个.index**（索引文件，保存对应的**.log**文件的索引信息）文件组成，这两个文件的命名规则为：partition第一个segment从0开始，后续每个segment文件为上一个segment文件最后一条消息的offset序号值，数值大小为64位，20位数字字符长度，没有数字用0填充。
所以真正开始读取指定分区中某个offset对应的数据时 ，先根据offset和当前分区 的所有segment的名称做比较 ，确定出数据在哪个segment中 ，查找该segment的索引文件 ，确定当前offset在数据文件中的开始位置 ，从该位置开始读取数据文件， 再根据数据格式判断结果 ，最终获取到完整数据。
Kafka的可靠性保证
- 数据提交的条件：有2种方法：①只要leader写入成功，就认为写入成功。②要求所有的follower都必须同步完成，才认为写入成功。这2种方法都比较极端，前者容易丢失数据，后者存在单点故障问题。
- Kafka采用了AR，ISR ，OSR列表机制
在Kafka的分区中，维护了一个AR列表，包括当前分区的所有副本的编号。
AR=ISR+OSR
① ISR同步列表，写入数据时，要求所有的ISR中的副本都同步数据完成后，才能被提交，才可以被消费者访问。
② OSR是非同步列表，OSR内的副本是否同步了leader的数据，不影响数据的提交，OSR内的follower只是尽力的去同步leader，存在数据版本可能落后的情况。
最开始所有的副本都在ISR中，在Kafka工作的过程中，如果某个副本同步速度慢于replica.lag.time.max.ms指定的阈值，则被踢出ISR 存入OSR ，如果后续速度恢复可以回到ISR中。这种方案是一种介于leader独裁和所有follower民主方式之间的方案，同时兼顾了可用性和性能，相对于zookeeper的过半同意、过半存活机制，提供了更好的可用性。 - Kafka中的可靠性保障 - LEO 、HW
① LEO - LogEndOffset
分区的最新的数据的offset，只要有数据写入分区，LEO就指向最新的数据，无论这个数据是否已经在ISR中同步完成。
② HW - HighWatermark
消费者能够看到的最大的offset，这个offset及小于这个offset的数据时可以被消费者访问的，而大于这个offset的数据，要么不存在，要么没有同步完成，外界无法访问。
HW永远小于等于LEO. - Kafka分区同步数据的流程
最开始,分区中HW等于LEO，外界可以看到所有的数据，之后生产者写入数据，先写入leader中，此时LEO指向最后一条数据，而此时ISR中其他follower还未完成数据同步，HW扔然指向最初位置，外界也只能访问HW位置及其之前的数据，之后follower同步数据，任何一条数据同步完，HW指向新的offset，外界就可以访问到该数据，直到最后，所有数据都同步完成，HW重新等于LEO，外界可以访问到所有数据。 - Kafka分区同步数据时截断机制
当leader宕机，重新选举leader后，之前未同步完成的数据该如何处理呢？
如果leader宕机 选出了新的leader，所有副本都会先将数据截断到leader宕机之前的HW位，保证所有副本不会持有未同步完成的数据，这个机制就称之为截断机制。
另外，即使此时旧的leader恢复，成为一个follower，也要先截断数据到宕机之前的HW位，再和新的leader同步数据。保证了数据的一致性。
利用截断机制，保证了不会有未同步完成的数据干扰从新选举leader后的数据一致性。 - Kafka消费数据时的可靠性保证
对于消费数据的过程，所谓的可靠性，指的是被访问到的数据一直能够被访问到，绝对不会存在之前还能访问的数据，突然之间就无法访问了。
利用LEO-HW机制，保证了在读取数据时，能够读取到的仅仅是HW之前也即ISR列表的副本完成了同步的数据，这样即使leader宕机，从ISR列表中选取一个follower成为新的leader，也会持有HW之前的数据，保证了读取数据的可靠性不会因为重新选举leader而造成影响。
而在leader宕机的过程中，新leader选举后，会先进行截断操作，保证数据是从之前已经同步过的位置继续增加，未同步的数据全部都截断丢弃掉，保证了切换leader时，对于外界消费者没有影响。
唯一存风险的情况就是，当ISR列表中只有leader，其他副本都在OSR中，此时如果leader宕机，ISR列表中不存在任何存活的副本，如果坚持要ISR列表中的副本才可以成为新的leader，则除非原来的leader恢复，否则无法选出新的leader，无法进行写入操作。或者可以允许OSR列表中的follower成为新的leader，但此时存在读取数据不一致的风险。 - Kafka生产数据的可靠性保证
通常在分布式系统中可靠性保障可以体现在三个层面：
① 可能丢数据，但不会多数据，数据至多一次 — 0
② 不会丢数据，但可能会多数据，数据至少一次 — 1（默认）
③ 不丢也不多，数据恰好一次 — -1
而Kafka中对于生产者来说，可以通过request.required.acks参数来控制发送数据过程中要求的可靠性级别。
Kafka原生的机制最多可以实现到不丢数据但可能多数据，对于恰好一次的语义，Kafka建议根据业务的幂等性 或 业务本身特点 由开发人员自己来实现去重。 - Kafka中leader的选举
当leader宕机时 Kafka会选择ISR中的一个follower成为新的leader，由于ISR中的所有follower都同步着leader中的数据，再基于截断机制，保证未同步的数据在新leader选举时被抛弃，所以保证了新leader产生后不会有数据一致的问题。
但，在极端情况下，如果ISR列表中只有一个leader存在，其他副本都进入了OSR，此时leader宕机，ISR列表中为空，则该如何选举新的leader?
此时存在两种策略
策略1：不允许OSR中的follower成为新的leader，则必须等待原来的leader恢复，才可以继续工作，如果原来的leader一直无法回复，则集群一直无法使用写功能。这种方式，追求一致性，但放弃了可用性。如果将unclean.leader.election.enable=false则Kafka集群将猜中这种策略。
策略2：允许OSR中的follower成为新的leader，则可以快速的恢复集群工作，但可能会造成数据丢失。这种方式，追求了可用性，但放弃了极端情况下的一致性。如果将unclean.leader.election.enable=true则Kafka集群将猜中这种策略.
策略1，一致性有保证，但是可用性低，只有最后挂了leader活过来Kafka才能恢复
策略2，可用性高，一致性没有保证，任何一个副本活过来就可以继续工作，但是有可能存在数据不一致的情况。
本质上是 一致性 和 可用性之间的矛盾,需要根据业务需求进行取舍.
