闫燕飞：Kafka的高性能揭秘及优化

欢迎你们前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~

本文首发在云+社区，未经许可，不得转载。

你们下午好，我是来自腾讯云基础架构部ckafka团队的高级工程师闫燕飞。今天在这里首先为你们先分享一下开源Kafka在高性能上面的一些关键点，而后我会分享一下咱们腾讯云ckafka对社区Kafka所作的一些优化点，最后我会介绍一下我对Kafka社区将来的展望。

Kafka高性能揭秘

在这里首先我会介绍一下整个Kafka的架构，让你们对Kafka有一个较为宏观的了解，紧接着我会在更加详细的介绍一下Kafka的存储方式以及具体消息存储格式。固然为了方便你们对kafka的高性能有个直观的理解，最后我也会给出其性能数据。

整体架构

咱们能够看到Kafka整个集群里面仅仅包含了Broker，zookeeper两个组件。

Broker是整个Kafka集群的核心引擎，负责消息的存储转发，并对外提供服务。咱们能够看到，Kafka集群能够很是简单的经过增删Broker，实现整个集群的扩缩容。Kafka对外提供服务的基本单位是Topic，那么实现Topic级别的平行扩展能力，也就实现了应用级的平行扩展能力。为了实现应用级的平行扩展能力，Kafka采用了对Topic进行分区的作法，经过对Topic进行分区让不一样的分区落在不一样的Broker上，从而利用到更多Broker的能力，最终实现了应用级的水平扩展。

Zookeeper则在整个集群中则主要负责存储一些配置信息、Broker信息、Topic信息等等元数据，而且承担了一部分协调选主的功能，能够将其理解为Kafka集群的配置管理中心。讲到这里，你们会以为在Kafka集群中，能够简单的经过Broker动态的增删实现集群扩缩容，但在整个集群中却仅仅存在一个Zookeeper，那么Zookeeper会不会成为整个集群的瓶颈点，从而制约了整个集群的平行扩展能力？的确，在Kafka一些较老版本，Kafka的生产者及消费者都须要与Zookeeper进行通讯交互，进行元数据拉取、消费分组协调、以及消费分组offset提交与保存等等。这样形成的一个问题，就是全部的客户端都要直接与ZooKeeper进行通信交互，对其形成了很是大的压力，影响了系统的稳定性，最终影响整Kafka集群的平行扩展能力。但从0.9(含)版本以后，Kafka团队对整个Kafka进行了优化中，经过增长了一些协议，而且增长了协调模块。当前Kafka已经作到了客户端的生产及消费不须要与Zookeeper进行任何通信交互，故Zookeeper当前仅仅充当了配置管理中心，压力很是的小，不会成为集群的瓶颈点进而制约集群的水平扩展能力。

你们也能够看到生产者及消费者是直接与Broker进行交互实现生产消费功能，Kafka在设计上并未采用传统系统中经过增长一层代理实现系统的平行扩展能力。Kafka在设计中经过内部路由协议，实现了生产者与消费者能够直接与Broker进行路由协商，从而实现了客户端直接与Broker进行生产消费，而不须要借助第三方代理。无代理的方式不只会减小整个数据链路的长度，下降延迟，也能够提升整个系统的稳定性，并且也会节省大量的成本。

总结下Kafka的整体架构体现了以下几个主要的优点。其一，Kafka集群能够经过增删Broker实集群级的水平扩展。其二，经过对Topic进行分区，实现了应用级别的无限平行扩展能。其三，经过优良通信协议，实现了生产系统直接与后端的Broker进行通信，节省了代理，不只减小了数据链路长度下降了延迟，并且极大的下降了成本。

至此，我想你们对Kafka已经有一个较为宏观了解。咱们知道系统整体架构，决定了整个系统的能力上限。但系统中关键组件的性能，则是决定了相同能力下集群中服务器数量。服务器数量的增长，不只仅会增长成本，并且会带来更多的运维压力及影响系统的稳定性。因此下面我将会介绍下Kafka核心引擎Broker的系统架构。

Broker架构

咱们能够看Broker是一个典型的Reactor模型，其主要包含一个网络线程池，负责处理网络请求进行网络的收发以及打包解包，而后把请求经过请求队列推送给核心处理模块，由其负责真正的业务逻辑处理（Kafka会把全部消息落地存储，故主要是些文件I/0操做）。咱们能够看到kafka采用多线程方式，能够充分利用现代系统的多核优点。其次，其采用队列方式实现了网络处理模块及核心处理模块的异步解耦，实现了网络处理和文件I/O并行处理，极大的提升了整个系统的效率。

讲到这里，你们对Kafka架构已经有一个宏观的理解。上面咱们也提到，Kafka会把全部的消息都落地存储。那么为何Kafka并未像传统的消息队列那样很是害怕磁盘，劲量缓存而不触碰磁盘？Kafka为何选择了将全部消息都落地存储？下面我将经过讲解其存储组织方式及存储格式，为你们进行一一揭秘。

存储的组织方式

这个就是当前Kafka的存储组织方式，咱们能够看到Topic，其实只是逻辑概念，并不对应任何物理实体，为了实现Topic的水平扩展，Kafka会对其进行分区。Partition则以目录形式进行展示，同时Partition中具体的数据还未进行分片存储。这样在生产时，就能快速的找到最新的分配直接追加到文件末尾，能够看到Kafka在生产中充分利用了磁盘的顺序写，极大的提升了生产的吞吐能力。同时进行分片存储，还有一个好处就是咱们能够很是方便的经过删除老的分片实现过时消息的删除。同时为了方便消费，Kafka在分片的命名上也采用了必定的技巧，分片的命名采用了其包含的第一条消息的offset进行格式化这样，在消费数据时，能够很是方便的经过二分查找定位到消息所在的文件分片。同时为了实现分片内快速定位，Kafka也会对每一个数据分片创建两个稀疏索引文件，经过索引文件，采用二分查找能够很是快速的定位了指定消息在数据分片中的位置，进而进行消费。经过讲解咱们能够看到Kafka的整个生产消费其实都是顺序读写，充分利用了磁盘顺序读写能力。其次，Kafka的消费，采用了二级二分查找，其查找性能仅仅依赖一个分片的索引大小，不会受整个系统数据量的影响。

Kafka处理的最基本单位是消息，那么Kafka的消息具体是什么格式？落地存储的消息又具体是什么格式？不用说这些都将极大的影响系统的性能，因此下面我也将会详细的介绍下Kafka的消息格式。

消息格式

为方便你们理解，这里我就以C代码的形式进行消息格式展现。Kafka消息实际上是采用的简单的二进制编码，网络字节序存储，故能够很是高效的进行编解码操做。同时，咱们能够看到整个Kafka消息头部很是的紧凑，仅仅只有30个字节左右，并且还包含了crc校验码用于对消息进行相关的校验。同时在Kafka中最为精妙的是，该消息的格式在生产系统端、网络传输中、Broker端，包括最终的文件存储中，都保持了消息格式的一致性。因此使得消息在整个系统的传输中，不须要有任何转码，效率奇高。固然为了提升整个系统的吞吐，Kafka这边实现了消息的批量生产消费。批量消息在Kafka中表现形式为，以二进制形式在内存中一个个排列起来。同时为了提升系统网络及磁盘的利用率，Kafka仍是实现了消息压缩，右边这个流程图则详细的说明了消息压缩的流程。能够看到，首先咱们把整个批量消息以一个总体进行压缩，生成一个新的二进制串。而后，把该值打包到一个新的消息的value字段中。能够看到Kafka很是巧妙的经过消息嵌套方式实现了消息的批量压缩，提升了总体压缩效率。同时该方式也保证了消息的格式的一致性。保持消息一致性就有如下好处:其一，咱们在整个消息流转中仅仅须要生产者进行一次压缩后，将该压缩消息发送到Broker端后，Broker端仅须要一次解压操做，用以进行消息校验，并进行消息offset设置，后就能直接把消息直接存储在文件中，不须要有Broker进行一次很是消耗性能的压缩操做。因此说即便采用的消息压缩，对于Broker端的消耗也很是低。同时因为保持了压缩消息格式的一致性，当有消费请求时，Broker不用进行任何解压及压缩操做，能够直接将消息以压缩的方式发送给消费者，由消费者负责解压，这样的话Broker在整个消费中也就不须要任何的解压及压缩的操做，能够极大的提升Broker端的性能。能够看到Kafka经过这种方式，很是简单的实现了端到端的数据压缩，把计算资源消耗分摊到生产系统和消费系统中。

Kafka高性能

因为时间缘由，讲到这里Kafka高性能的关键点也基本都涵盖了，固然Kafka团队为了其高性能仍是有不少巧妙的设计，这里因为时间缘由就不在一一赘述，固然这页PPT中则详细的列举了其高性能的关键点，你们下面有兴趣能够本身对着这些关键点本身仔细琢磨。

讲了这么多Kafka高性能的关键点，但到底其有着什么样的性能？为使你们对整个Kafka的性能有一个较为直观的认识，下面我也将给你们提出相关的性能测试数据。固然任何性能测试若是没有前置的测试条件则都是在空说，因此在给出数据前，先给一下测试的配置条件.1、测试场景是一个Broker单topic，多个partition。2、机器硬件配置是32核 64G内存,万兆网卡，同时挂载12块2T SATA盘，而且对SATA盘作了软RAID10。3、Broker版本上咱们选择是0.10.2.0。Broker配置方面，咱们选择的是每10万条消息或两秒进行一次刷盘。4、咱们使用社区Kafka的原生压测工具，并同时开启140客户进行压测，用于模拟必定的并发。固然我后面全部压测数据都是基于这个统一的配置，后面介绍时我就再也不相信叙述测试条件了。

经过下面的表格，咱们能够看到Kafka在小包的状况下轻松达到百万级别的qps，并且即便在1K的大包状况下也达到了几十万级别的qps，能够说整个Kafka性能仍是很是强悍的。但同时咱们也发现Kafka Broker在测试中，的CPU使用率，尤为是磁盘I/O使用率并不高，说明社区Kafka仍是有必定的优化空间。因此下面我就介绍一下咱们CKafka对社区Kafka的一些优化点。

Kafka性能优化

在这个章节里面，首先我会带领你们进一步的深刻了解一下整个 Broker端的架构，经过进一步了解他的架构，找出它可能的瓶颈点，而后在针对瓶颈点进行优化优化。紧接着我将会挑出几个具体的优化点进行详细的介绍。

当前架构剖析

在这里为了方便你们理解，咱们用一次真实的请求，通过的路径，来讲明Broker各个模块是怎么交互的。首先,当一个生产启动，他须要去和Broker进行链接，Broker端会有一个Accept线程模块进行链接监听用于创建新的链接，在链接创建后Accept会将网络链接轮询转发给给网络接收发送处理线程池中的一个线程处理，至此链接接入已经完成。下面将进入数据请求，这时候生产者发送的生产请求数据，将直接由网络收发处理线程进行处理，每当网络线程收到一个完整的包，并进完成解包操做后，就会将请求推送到请求队列，由后端核心处理线程进行真正的逻辑处理。后端核心I/O处理线程会竞争的从请求队列中拉取到生产请求任务后，首先，其会对相应的消息进行解析，建立相应的消息对象，而后消息对象进行一些合法性校验，并设置相应的offset，当完成这些后会将消息写入文件。固然写入完成后会检测未刷盘的消息个数是否达到刷盘要求，若是达到刷盘要求，该线程还会主动进行刷盘操做，最后把这个处理结果经过每一个网络处理线程的应答队列，返回给对应的网络处理线程，最后由网络线程进行打包并把结果返回给生产端，至此一个生产流程就以完成。

在这个流程中，咱们能够发现：1、在整个Kafka的架构中，仅仅只有一个请求队列，并且该队列还未进行任何无锁化优化，这样会致使网络处理线程池以及核心I/O处理线程产生激烈的锁竞争，从而有可能影响整个系统的并发性，进而影响到系统的性能。因此这个是咱们应该想到一个优化点。其二，咱们刚才讲到Kafka选择直接在核心处线程中直接进行磁盘刷盘，这样会致使堵塞整个核心流程，进而影响整个系统的性能。这也是咱们今天发现的须要优化的第二个一个优化点。其三，就是咱们发如今生产消息中会生成大量的消息对象，用于进行消息的合法性的校验。产生大量的消息对象，会对jvm的GC产生较大的影响，可能会成为系统性能的瓶颈点。固然咱们ckafka对社区kafka还作了不少其它方面的优化，这里有因为时间关系，主要集中这三点进行介绍。

锁优化

咱们初版的锁优化，经过架构图能够看到，实际上是很是简单的。咱们直接把broker端仅有的一个请求队列，替换成一个无锁请求队列，固然咱们也对全部的应答队列进行了无锁队列的替换优化。通过这一轮优化，咱们具体到达成一个什么效果？这个就是当前无锁队列的优化结果。经过对比咱们能够发现，通过无锁队列优化后，相对于社区版本Kafka，整个性能基本上保持了一致。但按照咱们以前的分析，按理说应该会有较大的性能提高才对，但为啥没有达到预期效果？

为一探究竟，咱们又对 Broker进行了更为详细的统计分析。经过统计分析后，咱们统计了请求次数，经过下面的统计图表，咱们发现无论是社区Kafka，仍是咱们优化的版本，即便在百万qps的消息状况下，生产请求个数都很是的少，都是在10w级别如下。讲到这里咱们明白了，正是因为开源Kafka这边采用了批量发送的方式，合并了大量的生产请求，使的整个Broker端的请求次数急剧的减小，请求量的减小就使得网络处理线程及核心处理线程间的锁争用减小，在当前请求量级的状况下锁争用不太会成为真个系统的瓶颈点，因此咱们的无锁队列没有达到理想的效果也是正常的。讲到这里，能够说咱们第一个优化实际上是不太成功的，可是优化道路老是漫长曲折的，一次不成功也正常也不会吓到咱们，咱们ckafka会持续不但的在优化道路上前行。

文件刷盘优化

下面咱们进行第二个优化点的介绍，异步刷盘优化。在异步刷盘优化方面，咱们ckafka专门增长了一组刷盘线程，专门用于磁盘刷盘，这样当核心线程发现须要有刷盘须要时，直接生成一个刷盘任务，并将刷盘任务经过无锁队列推送给刷盘线程，由其进行刷盘便可。这样的话咱们就能够实如今刷盘时不堵塞核心处理线程处理，会极大的提升一个系统的性能。固然通过这一轮的话后咱们到底有没有效果？具体咱们看一下下面的性能对比数据。

通过异步刷盘优化后，咱们能够看到，优化后的吞吐在小包状况下，较社区版本有4到5倍的性能提高，同时即便是在大包状况下也有一倍左右的性能提高（随着包的增大及partition的增多优化后的提高会成降低趋势）。同时咱们能够发如今咱们异步刷盘优化的测试过程当中，整个系统的I/O使用率已经很是搞了，基本都在90%以上了，能够说如今整个系统的瓶颈点应该就是磁盘I/O了，同时超过90%的I/O使用率，说明咱们已经榨干了系统磁盘的性能，也表示咱们后续的吞吐量优化空间已经不大了。那么这样是否是说咱们整个Kafka就没有任何的优化空间了？其实对于系统的优化则不只仅是包含了吞吐量的提高，咱们还能够从相同吞吐量下资源使用率方面进行相关的优化，因此ckafka对社区Kafka的优化并未止步于当前，因此咱们进一步进行了下一个GC方面的优化。咱们指望经过该优化不只能有吞吐方面的提高，更重要的是指望在相似的场景下，能够更好的减小资源的使用率，进一步缩减成本。

GC优化

在GC优化方面，主要是社区Kafka在对生产消息进行校验时会针对每条消息生成一个消息对象，致使产生大量的消息对象，ckafka经过优化，采用直接在ByteBuffer二进制数据上进行消息校验，这样在整个消息校验中就不会生成任何消息对象，减小大量的消息对象的生成，则会下降对jvm GC的压力，进而提升系统的性能。经过对比优化先后的性能数据，咱们能够看到它起到必定效果的。咱们能够看到优化后整个GC的耗时占比的已经低于2.5%，能够说GC已经不会成为系统的瓶颈点了。咱们看一下社区开源Kakfa这边的GC耗时，在较多的partition较小的消息下，直接能够达到10%的消耗。经过咱们的GC优化后，能够看到整个GC耗时方面的话，有1.5%到7%的性能的提升。一样咱们能够看到，在吞吐量差很少的状况下，咱们整个系CPU消耗较交社区版的CPU有关5%到10%的下降，因此能够确定的说GC优化有效的下降了系统CPU资源的消耗，起到必定的效果。最后咱们发现整个GC优化先后系统中I/O基本上已经达到顶点，已经成为系统的瓶颈点，因此GC优化就和前面预测的一致并未有吞吐量大幅的提高，主要集中在下降系统资源的消耗，对于前端客户端来讲则是必定幅度上下降系统的延迟。

至此因为时间缘由，Kafka的性能优化的介绍已经完毕。但为了更加方便你们直观的理解，这一页PPT则贴出了最终的优化对比效果。咱们来看看最终优化后的效果，能够看出咱们最终完整版优化，在小包状况下有4到5倍的性能提高，即便在1K的大包状况下，也有一倍左右的性能提高(固然随着partition的增长及消息大小的增长，优化效果呈必定的降低趋势)。同时咱们能够发现整个系统的I/O已是成为系统的瓶颈点。也为咱们后面系统硬件选择方面提供一个参考，可能咱们后面会经过挂载更多的磁盘，进一步提升系统的吞吐压榨系统的性能，进一步平衡CPU及磁盘的配比消耗，固然经过选择更合适的硬件作到CPU、磁盘、网络之间合适的配比实现资源利用的更大化。

下面我讲一下咱们在CKafka运营中所发现一些问题，以及咱们针对这些问题的优化点，同时咱们指望社区Kafka可以采纳咱们ckafka在运营中发现并优化的一些关键点建议，让kafka可以更好的适应生产条件。

其一，当前社区Kafka还没法采用pipe方式进行消费，这样就致使出现如下几个问题：1、消费者的性能很是依赖于与Broker端的网络延迟，当消费者与Broker存在跨城区的时候，因为网络延迟的增大，会致使整个消费性能很是低下，这样就最终限制了Kafka的使用场景，使其不能很好的做用于跨城区数据同步，限制了其使用的场景。二，Kafka在副本复制的时复用了消费逻辑，一样走的也是消费者逻辑，这样也一样致使其没法使用pipe方式，最后致使了副本同步性能低下并且很是依赖于延迟，最终致使了整个Kafka集群不太可能进行一些跨区域的部署，限制了Kafka部署的灵活性，并且同时在压力较大的状况下，容易出现副本拉取的速度跟不上生产的速度致使ISR抖动影响系统性能。针对这个问题，其实在第二点，咱们这边已经作了优化，使得副本拉取已经能够进行pipe方式，后面即便须要作一些跨城区部署，其整个副本同步性能是可以达到要求的。可是在这里第一个问题咱们这里没法解决，由于咱们这边生为了兼容性社区版本Kafka，是让客户直接采用的是开源的SDK，致使了咱们这里还无法没办法优化。在这里我但愿社区Kafka，能够采纳相关的建议，实现消费者pipe方式，使得整个消费性能不在依赖于网络延迟，使得用户的使用上没有地域空间的一些限制。

其二，就是当前社区Kafka对消费为了性能方面的考虑，他在设计中是不支持低版本的消费者直接去消费高版本生产增产的消息，而当前Kafka发展到如今已经有三个消息版本，这样就致使了业务的在使用Kafka时，包括生产者及消费者的升级降级都是很是不友好的。固然这里咱们在进行云化的时候，咱们已经实现了对消息格式转换，已经实现了不一样版本消息混合存储在同一个文件中，已经实现了任意版本的生产以及任意版本的消费。这里咱们但愿社区Kafka可否试试放开相关的支持，由于毕竟在生产系统中，业务使用时兼容性是最重要的考量标准之一。并且即便是咱们如今的实现存在消息高低版本的转码，其实CPU如今仍是有富余的，也不是系统的瓶颈点，因此说我但愿社区这边可以采纳

讲到这里，其实个人分享也基本上完了。而后这是个人我的微信，你们若是有什么问题能够加个人微信。固然，如今咱们的CKafka团队也在大量的招人，你们有意向的话也能够联系咱们。

Q/A

Q：这里须要请教你一个问题，就是我看刚才看到一部刷盘优化的时候，发现CPU也是随着性能的提高上升了不少倍，这里是否是主要是由于优化过程当中你又作了一次拷贝？

A:没有，其实社区Kafka在内存拷贝方面仍是有一些优化的。唉，稍等一下，社区Kafka在整个消息流转中，好比生产消息时，他从网络层开始会生成一个ByteBuffer用于存储消息包，然后这个ByteBuffer会在整个系统中不断的扭转，它是不会有新的拷贝的，除非有一些消息须要有不一样方式的存储时，须要有转码的要求，他才会生成一个新的消息进行一次内存拷贝不然不会有屡次内存拷贝。而咱们这里在作异步刷盘优化时，实际上是不会有任何多于的内存拷贝的，咱们的CPU使用有数倍的提升，主要仍是在与吞吐的提升，能够看到咱们系统在小包状况下有4 ~ 5倍的性能提高，这样提高，会致使更多的网络操做，更多的打包解包，更多的系统I/O固然最终就会致使更多的cpu，固然就会须要更多的CPU消耗。这么多消耗的叠加固然照成CPU使用率数倍的提升也是很正常的。

Q:我有个问题想问一下你刚才以前PPT也有说就是说在系统量很大的状况下，副本的拉取速率没法跟上生产的速率，对这个的话咱们测试或者是说线上其实也会碰到副本拉取跟不上生产速度，并且会影响致使其它节点也跟不上，照成一种雪崩效应。而后我想问一下你这边的解决办法，你刚才说有解决办法，我想问一下大家这边是采用哪一种解决办法？

A: 社区Kafka副本拉取不上最主要的缘由，是由于采用了消费方式，但消费方式又不支持pipe方式消费。其实Kafka的副本拉取是同步方式，发送一个副本拉取请求后等到应答后再次发送一次同步拉取请求，没法使用pipe流水线方式，这样的同步方式Broker的网络延迟会成为整个副本同步的关键点，而且在压力大的状况下整个Kakfa的broker端出来延迟会达到秒及，这样会致使整个副本拉取性能不足，不足的真正缘由就是拉取请求次数不够，若是咱们采用pipe方式增大拉取请求次数，天然也就增大了副本同步的性能。

Q:大家还有没有就是说更具体一点的解决方式？

主要是咱们这边的话，副本的同步采用了一个新的协议，使的副本拉取请求能够采用pipe方式增大请求次数进而提升副本同步速度。其实，社区Kafka副本拉取跟不上的真正缘由是应为请求都是同步的，延迟正大致使请求量减小，请求量的减小最终致使副本性能降低致使没法跟上，因此咱们所要作的就是加大副本同步请求个数，就能够从根本上解决问题，咱们这里采用的就是pipe方式，用于增大请求次数解决副本没法跟上的问题。这实际上是最核心的，也是最简单一个解决方案了。

Q: 请问一下就是说我刚才看到有一个异步落盘的优化，问一下就是说你这里公布的数据都是没有时延信息的，我不知道就是说这个有话会不会致使业务时延增长。

A: 由于测试中客户端比较多，统计上加上时延就会致使更加的杂乱，故这里统计数据并未有展现出来，其实咱们测试统计中采用异步刷盘后这个时延效果其实更好。由于采用异步刷盘后在整个请求中不会堵塞任何核心流程，只用把刷盘任务推送到队列，就能够直接返回给前端客户端了。可是若是你不使用异步刷盘直接在核心流程中进行刷盘的话，会堵塞核心流程的，并且每次刷盘耗时实际上是很是大的，常常会到达400毫秒左右的延迟，因此延迟会更大。采用异步刷盘后，通过咱们测试，即便在七八百MB的最高吞吐下，咱们这边整个延迟是保持得很是好，整个测试的平均延迟是在15毫秒到30毫秒之间。然而在社区Kafka环境下，其延迟实际上是在200毫秒左右。

Q: 我就问，若是异步落盘的时候，它到期还没刷到盘，这个不须要等到刷盘完成后才返回给客户吗？会不会致使未刷盘时消息丢失？

A: 这个其实和Kafka的应用场景有关了，当前社区Kafka也不是每条消息都刷盘，其实刷盘也是经过配置一个消息间隔数或间隔时间进行的，这样其实社区Kafka这边在系统掉电的状况下，是还真的无法保证这个消息不丢失。Kafka应用场景通常也不是在用在彻底不须要消息丢失的场景，而是主要用于一些日志采集等实时性要求比较高，吞吐要求比较高的场景，Kafka这里为了吞吐这边其实仍是选择了牺牲必定的消息的可靠性的。固然针对咱们这个异步刷盘，当前的第一步优化比较简单，咱们直接把任务推送到刷盘人群队列，就返回给客户端成功，的确会致使一部分消息在系统掉电下致使丢失。当前为了切合Kafka的应用场景，采用了优先吞吐的方式，固然，咱们后面还会根据须要看看，是否须要实现真正刷盘后在返回给用户成功。其实实现这个也比较简单，咱们选择挂起生产请求，直到刷盘线程真正刷盘后，在返回给客户成功便可。但这样的话你刚才也说了可能会致使的延迟增大，由于你必需要等它真正的刷盘完成，这个可能须要你本身根据应用形态采用而不一样的方式，实现一个高吞吐及高可靠的一个取舍了。

Q：你好，问个问题就是两个问题，第一个问题是关于数落盘的，由于刚才也提到说Kafka里面的数据不必定是可靠的，而后想问一下腾讯在这边对数据可靠性是有作了什么优化和方案这样。

A：一方面，从硬件方面，其实咱们这里全部的存储磁盘，都采用了RAID10的方式，这样即便有少许的磁盘的损坏，对咱们来讲的话是不会有数据丢失的风险的。另外一方面，ckafka和社区kafka同样均可以经过多副本的方式，加上必定合理的配置，能够保证在机器损坏时，数据不丢失。再次，在实现上咱们ckafka也作到了定时定量进行主动刷盘能够下降机器因为意外掉电致使的数据丢失。因此相对应社区kafka ckafka从硬件及软件上都有更高的数据可靠性保证。

Q:而后第二个问题，刚才说到说跨城区的副本同步就有个问题，如今腾讯这边的部署是跨城区部署的吗？

A:当前ckafka的部署采用的是同城区，同zone部署的，可是咱们ckafka是能够实现跨城区部署的，当前没提供这种部署方式，最主要的缘由是当前使用社区Kafka sdk的消费者性能强依赖于与Broker之间网络延迟。若是咱们进行跨地域部署的话，那么客户端的消费性能是得不到保障的，由于不通地域之间的网络延迟每每都在几十毫秒，甚至上百毫秒，这样使得整个消费性能降低很是严重没法知足业务的需求。固然若是社区Kafka SDK可以采用咱们上面的建议实现消费者pipe方式消费，那么进行跨地域部署将不会有任何问题。

Q：OK带来另一个问题，就是我觉的若是真的出现意外状况，好比像天津大爆炸案，致使整个腾讯的天津机房都炸掉了，大家这里的话有没有考虑过这种迁移计划？

A:其实咱们ckafka是在各个地域都部署的有相关的集群，用户能够经过在不一样地域购买不一样的实例，一方面实现就近接入，另外一方面实现异地容灾，保证程序的可用性。固然用户也能够经过，咱们提供的Kafka的一些同步工具，进行数据在不一样地域间同步，用于实现地域级别的容灾。

Q:对于业务来讲，若是他使用同步工具那么会不会对业务照成更大的成本？业务是否须要改造相关的程序用以实现跨城区访问？

A:对业务使用方来讲，能够直接使用一些开源的工具及方法，用户是不须要有任何的更改就能实现跨地域访问，社区Kafka的生态及工具仍是比较完善的你们能够多去社区上逛逛总能找到适合本身的工具。

更多详细资料，请戳下面的连接：
kafka-高性能揭秘及优化.pdf

问答
Kafka的基于关键/值对的消息传递的目的是什么？
相关阅读
饶军：Apache Kafka的过去，如今，和将来
杨原：腾讯云Kafka自动化运营实践
陈新宇：CKafka在人脸识别PASS中的应用

此文已由做者受权腾讯云+社区发布，原文连接：https://cloud.tencent.com/dev...