千亿级eBay平台的Kafka深度实践

比如上海数据中心比北京数据中心的 Kafka 早上一个月,那这个就肯定会有索引量偏移,所以我们就需要一个工具能够找到这个偏移量多大.好在后续版本 Kafka 就提升了一条索引机制在 Kafka 服务器里,但是我们在实现这个功能的时候,那个版本还没有出来.

4、Kafka性能优化

先说一下为什么 Kafka 有这么大的吞吐率和性能.

4.1 磁盘顺序读写

首先它是保证了磁盘顺序读写,因为我们知道磁盘顺序读写是很好的,只要你不引入文件读写.我们知道它这个特性之后,怎么样保证磁盘读写正常运行呢?我们不要让它的磁头经常跳,什么情况下磁头经常跳呢?

受到一个 Kafka 里节点太多了,不同文件切换的时候,就会引起顺序读写的方式.还有比如应用程序里,也会影响大数据读写的性能.如果要保证它是顺序读写的话,尽量避免刚才说的操作.

4.2 以Page Cache为中心的设计

还有一个是 Kafka 通过 Page Cache 保持很高的性能,对于 Kafka 端,如果你跟上的话,它永远是从内部读数据,不是从磁盘读数据.

因为现在操作系统里我们会有 Page ?Cache 来监控数据处理,我们在运维当中,发现对于 Page ?Cache 来说,千万不能有 Swap,一旦发生 Swap,节点的性能马上会下降.

如果你是基于云的,特别是基于公有云的,这是很麻烦的事情,你需要在 Hypervisor 上进行设置.我们在使用当中也发现了 NUMA 不平衡的问题,这个会导致其他虚拟机所在的 CPU 内存没有很好的运营起来,它在后续版本的 OpenStack 里,会让你在分配 CPU 的时候,强行 PIN 的操作.

除此之外 Linux 也对 Page Cache 有一些优化的设置.有人可能会问我写盘了异步的,如果数据来了之后,在数据真正写到盘子之前,我的也点宕掉怎么办?

Kafka 是除了在本节点之外,他会在其他节点上也有,它先进行保存,然后异步写盘过程才会把这个消息真正落到盘里面去.

4.3 Zero Copy

最后一点,Kafka 用到 linux 操作系统之后,Zero Copy 很简单,当我的磁盘来的时候,可以不用直接进用户内存,而是直接丢到网络端口去,这里不是优化的,我们一定要小心 Zero Copy 会失效.

我们做 Kafka 升级的时候,有可能数据格式会变,比如从0.9变到1.0,如果说你直接强行切过来的话,就会破坏 Kafka .

那怎么解决这个问题,其实在1.0升级的说明里有一个很复杂很详尽的说明,如果有人要做升级的话,一定要详细看清楚这些说明.

同时另外一个导致 Zero Copy 失效就是可能引入 SSL/TLS,这个怎么处理呢?那你只能权衡一下安全性和性能.

4.4 ?Kafka性能优化-其他参数调整

另外还有一些其他参数也可以对 Kafka 进行优化,有一个是 File ?Descriptor 一定要很大.

包括在高吞吐率节点上,一定要增加 Max ?socket ?buffer ?size.权衡 unclean.leader.electionbenable,增加 fetch 线程数量 num.replica.fetchers,处理 leader 选举 outo.leaderrebalance.enoble.

原文来自微信公众号：高效运维

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!