公司网站没有备案是不是违法的,关于文明网站建设存在的问题,中国电子商务研究中心,北京建设部官方网站证书查询文章目录 前言一、Kafka 存储选择二、Kafka 存储方案剖析三、Kafka 存储架构设计四、Kafka 日志系统架构设计4.1、Kafka日志目录布局4.2、Kafka磁盘数据存储 五、Kafka 可靠性5.1、Producer的可靠性保证5.1.1、kafka 配置为 CP(Consistency Partition tolerance)系统5.1.… 文章目录 前言一、Kafka 存储选择二、Kafka 存储方案剖析三、Kafka 存储架构设计四、Kafka 日志系统架构设计4.1、Kafka日志目录布局4.2、Kafka磁盘数据存储 五、Kafka 可靠性5.1、Producer的可靠性保证5.1.1、kafka 配置为 CP(Consistency Partition tolerance)系统5.1.2、kafka 配置为 AP(Availability Partition tolerance)系统 5.2、Broker 的可靠性保证5.3、Consumer 的可靠性策略 前言
Kafka 是为了解决大数据的实时日志流而生的, 每天要处理的日志量级在千亿规模。对于日志流的特点主要包括
数据实时产生。海量数据存储与处理。
所以它必然要面临分布式系统遇到的高并发、高可用、高性能等三高问题。
对于 Kafka 的存储需要保证以下几点
存储的主要是消息流可以是简单的文本格式也可以是其他格式。要支持海量数据的高效存储、高持久化保证重启后数据不丢失。要支持海量数据的高效检索消费的时候可以通过offset或者时间戳高效查询并处理。要保证数据的安全性和稳定性、故障转移容错性。
一、Kafka 存储选择
磁盘的顺序I/O性能要强于内存的随机I/O性能。如果需要较高的存储性能必然是提高读速度和写速度
提高读速度利用索引来提高查询速度但是有了索引大量写操作都会维护索引那么会降低写入效率。常见的如关系型数据库mysql等。提高写速度这种一般是采用日志存储, 通过顺序追加批量写的方式来提高写入速度因为没有索引无法快速查询最严重的只能一行行遍历读取。常见的如大数据相关领域的基本都基于此方式来实现。
二、Kafka 存储方案剖析
对于 Kafka 来说 它主要用来处理海量数据流这个场景的特点主要包括
写操作写并发要求非常高基本得达到百万级 TPS顺序追加写日志即可无需考虑更新操作。读操作相对写操作来说比较简单只要能按照一定规则高效查询即可offset或者时间戳。
对于写操作来说直接采用顺序追加写日志的方式就可以满足 Kafka 对于百万TPS写入效率要求。重点在如何解决高效查询这些日志。Kafka采用了稀疏哈希索引底层基于Hash Table 实现的方式。 把消息的 Offset 设计成一个有序的字段这样消息在日志文件中也就有序存放了也不需要额外引入哈希表结构 可以直接将消息划分成若干个块对于每个块我们只需要索引当前块的第一条消息的Offset 类似二分查找算法的原理即先根据 Offset 大小找到对应的块 然后再从块中顺序查找这样就可以快速定位到要查找的消息。 一个Topic对应多个partition一个partition对应多个segment一个segment有.log/.index/.timeindex等文件。
由于生产者生产的消息会不断追加到 log 文件末尾为防止 log 文件过大导致数据定位效率低下Kafka采取了分片和索引机制。 它将每个 Partition 分为多个 Segment每个 Segment 对应两个文件“.index” 索引文件和 “.log” 数据文件。
这些文件位于同一文件下该文件夹的命名规则为topic 名-分区号。例如test这个 topic 有三个分区则其对应的文件夹为 test-0test-1test-2。
$ ls /tmp/kafka-logs/test-0
00000000000000000000.index 00000000000000000000.log 00000000000000000000.timeindex leader-epoch-checkpointindex 和 log 文件以当前 Segment 的第一条消息的 Offset 命名。下图为 index 文件和 log 文件的结构示意图 “.index” 文件存储大量的索引信息“.log” 文件存储大量的数据。索引文件中的元数据指向对应数据文件中 Message 的物理偏移量。 查看索引
sh ./kafka-dump-log.sh --files /tmp/kafka-logs/test-0/00000000000000000000.indexDumping /tmp/kafka-logs/test-0/00000000000000000000.index
offset: 19999 position: 300695
Mismatches in :/tmp/kafka-logs/test-0/00000000000000000000.indexIndex offset: 19999, log offset: 10000三、Kafka 存储架构设计
Kafka 最终的存储实现方案基于顺序追加写日志 稀疏哈希索引。 Kafka 是基于「主题 分区 副本 分段 索引」的结构
kafka 中消息是以主题 Topic 为基本单位进行归类的这里的 Topic 是逻辑上的概念实际上在磁盘存储是根据分区 Partition 存储的, 即每个 Topic 被分成多个 Partition分区 Partition 的数量可以在主题 Topic 创建的时候进行指定。Partition 分区主要是为了解决 Kafka 存储的水平扩展问题而设计的 如果一个 Topic 的所有消息都只存储到一个 Kafka Broker上的话 对于 Kafka 每秒写入几百万消息的高并发系统来说这个Broker 肯定会出现瓶颈 故障时候不好进行恢复所以 Kafka 将 Topic 的消息划分成多个Partition 然后均衡的分布到整个 Kafka Broker 集群中。Partition 分区内每条消息都会被分配一个唯一的消息 id即偏移量 Offset因此kafka 只能保证每个分区内部有序性并不能保证全局有序性。为了防止 Log 日志过大Kafka 又引入了日志分段(LogSegment)的概念将 Log 切分为多个 LogSegement相当于一个巨型文件被平均分割为一些相对较小的文件这样也便于消息的查找、维护和清理。这样在做历史数据清理的时候直接删除旧的 LogSegement 文件就可以了。Log 日志在物理上只是以文件夹的形式存储而每个 LogSegement 对应磁盘上的一个日志文件和两个索引文件以及可能的其他文件(比如以.snapshot为后缀的快照索引文件等)。
四、Kafka 日志系统架构设计
kafka 消息是按主题 Topic 为基础单位归类的各个 Topic 在逻辑上是独立的每个 Topic 又可以分为一个或者多个 Partition每条消息在发送的时候会根据分区规则被追加到指定的分区中
4.1、Kafka日志目录布局
Log 对应了一个命名为-的文件夹。举个例子假设现在有一个名为“topic-order”的 Topic该 Topic 中 有4个 Partition那么在实际物理存储上表现为“topic-order-0”、“topic-order-1”、“topic-order-2”、“topic-order-3” 这4个文件夹。
Log 中写入消息是顺序写入的。但是只有最后一个 LogSegement 才能执行写入操作之前的所有LogSegement 都不能执行写入操作。为了更好理解这个概念我们将最后一个 LogSegement 称 为activeSegement即表示当前活跃的日志分段。随着消息的不断写入当 activeSegement 满足一定的条件时就需要创建新的 activeSegement之后再追加的消息会写入新的 activeSegement。 为了更高效的进行消息检索每个 LogSegment 中的日志文件以“.log”为文件后缀都有对应的几个索引文件偏移量索引文件以“.index”为文件后缀、时间戳索引文件以“.timeindex”为文件后缀、快照索引文件 以“.snapshot”为文件后缀。其中每个 LogSegment 都有一个 Offset 来作为基准偏移量baseOffset用来表示当前 LogSegment 中第一条消息的 Offset。偏移量是一个64位的Long 长整型数日志文件和这几个索引文件都是根据基准偏移量baseOffset命名的名称固定为20位数字没有达到的位数前面用0填充。比如第一个 LogSegment 的基准偏移量为0对应的日志文件为00000000000000000000.log。
注意每个 LogSegment 中不只包含“.log”、“.index”、“.timeindex”这几种文件还可能包含“.snapshot”、“.txnindex”、“leader-epoch-checkpoint”等文件, 以及 “.deleted”、“.cleaned”、“.swap”等临时文件。
消费者消费的时候会将提交的位移保存在 Kafka 内部的主题__consumer_offsets中。
4.2、Kafka磁盘数据存储
Kafka 是依赖文件系统来存储和缓存消息以及典型的顺序追加写日志操作另外它使用操作系统的 PageCache 来减少对磁盘 I/O 操作即将磁盘的数据缓存到内存中把对磁盘的访问转变为对内存的访问。 在 Kafka 中大量使用了 PageCache 这也是 Kafka 能实现高吞吐的重要因素之一 当一个进程准备读取磁盘上的文件内容时操作系统会先查看待读取的数据页是否在 PageCache 中如果命中则直接返回数据从而避免了对磁盘的 I/O 操作如果没有命中操作系统则会向磁盘发起读取请求并将读取的数据页存入 PageCache 中之后再将数据返回给进程。同样如果一个进程需要将数据写入磁盘那么操作系统也会检查数据页是否在页缓存中如果不存在则 PageCache 中添加相应的数据页最后将数据写入对应的数据页。被修改过后的数据页也就变成了脏页操作系统会在合适的时间把脏页中的数据写入磁盘以保持数据的一致性。
除了消息顺序追加写日志、PageCache以外 kafka 还使用了零拷贝Zero-Copy技术来进一步提升系统性能。
五、Kafka 可靠性
Kafka 从拓扑上分有如下角色
Consumer: 消费者。Producer: 生产者。Kafka broker: kafka 集群中的服务器topic 里的消息数据存在上面。 Producer 采用发送 push 的方式将消息发到 broker 上broker 存储后。由 consumer 采用 pull 模式订阅并消费消息。
5.1、Producer的可靠性保证
生产者的可靠性保证依靠回答 发消息之后有没有 ack发消息收到 ack 后是不是消息就不会丢失了而 Kafka 通过配置来指定 producer 生产者在发送消息时的 ack 策略
# -1(全量同步确认强可靠性保证)
Request.required.acks -1
# 1(leader 确认收到, 默认)
Request.required.acks 1
# 0(不确认但是吞吐量大)
Request.required.acks 05.1.1、kafka 配置为 CP(Consistency Partition tolerance)系统
request.required.acks-1
min.insync.replicas ${N/2 1}
unclean.leader.election.enable falseN是follower的数量。 正常情况下所有 follower 复制完成后leader 回 producer ack。 异常情况下如果当数据发送到 leader 后部分副本(f1 和 f2 同步) leader 挂了此时任何 follower 都有可能变成新的 leader producer 端会得到返回异常producer 端会重新发送数据但这样数据可能会重复(但不会丢失)。
min.insync.replicas 参数用于保证当前集群中处于正常同步状态的副本 follower 数量当实际值小于配置值时集群停止服务。如果配置为 N/21, 即多一半的数量则在满足此条件下通过算法保证强一致性。当不满足配置数时牺牲可用性即停服。
unclean.leader.election.enable 来控制在有些follower未同步的情况下是否可以选举未同步的follower为 leader。旧版本中默认为true在某个版本下已默认为 false避免这种情况下消息截断的出现。
通过 ack 和 min.insync.replicas 和 unclean.leader.election.enable 的配合保证在 kafka 配置为 CP系统时要么不工作要么得到 ack 后消息不会丢失且消息状态一致。
5.1.2、kafka 配置为 AP(Availability Partition tolerance)系统
request.required.acks1
min.insync.replicas 1
unclean.leader.election.enable false通过 producer 策略的配置和 kafka 集群通用参数的配置可以针对自己的业务系统特点来进行合理的参数配置在通讯性能和消息可靠性下寻得某种平衡。
5.2、Broker 的可靠性保证
消息落到 broker 后集群通过何种机制来保证不同副本建的消息状态一致性。 LEO和HW简单介绍 LEOLogEndOffset的缩写表示每个partition的log最后一条Message的位置。 HW HighWaterMark的缩写是指consumer能够看到的此partition的位置。 取一个partition对应的ISR中最小的LEO作为HWconsumer最多只能消费到HW所在的位置。 HW用于标识消费者可以读取的最大消息位置LEO用于标识消息追加到文件的最后位置。 如果消息发送成功不代表消费者可以消费这条消息。
5.3、Consumer 的可靠性策略
1 AutoCommit。
enable.auto.commit true
auto.commit.interval.ms 默认5000 (5 seconds)配置如上的 consumer 收到消息就返回正确给 brocker, 但是如果业务逻辑没有走完中断了实际上这个消息没有消费成功。这种场景适用于可靠性要求不高的业务。其中 auto.commit.interval.ms 代表了自动提交的间隔。
2 手动 Commit。
enable.auto.commit false配置为手动提交的场景下业务开发者需要在消费消息到消息业务逻辑处理整个流程完成后进行手动提交。如果在流程未处理结束时发生重启则之前消费到未提交的消息会重新消费到即消息显然会投递多次。此处应用与业务逻辑明显实现了幂等的场景下使用。
