Kafka最佳实践

 

1、硬件考量

1.一、内存

不建议为kafka分配超过5g的heap，由于会消耗28-30g的文件系统缓存，而是考虑为kafka的读写预留充足的buffer。Buffer大小的快速计算方法是平均磁盘写入数量的30倍。推荐使用64GB及以上内存的服务器，低于32GB内存的机器可能会拔苗助长，致使不断依赖堆积机器来应付需求增加。（咱们在生产环境使用的机器是64G内存的，但也看到LinkedIn用了大量28G内存的服务器。）

1.二、CPU

kafka不算是CPU消耗型服务，在主频和CPU核数之间，选择后者，将会得到多核带来的更好的并发处理性能。

1.三、磁盘

毋庸置疑，RAID是优先推荐的，它在底层实现了物理磁盘的负载均衡和冗余，虽然会牺牲一些磁盘空间和写入性能。更进一步，咱们推荐在配置中使用多目录，每一个目录挂在在不一样的磁盘（或者RAID）上。须要注意的是，NAS是不可取的，不管供应商如何吹嘘他们的NAS的卓越性能。另外，咱们常常看到用户咨询kafka是否必定要采用SSD，答案是没有必要。

1.4网络

分布式系统中，网络的速度和可靠性异常重要，千兆甚至万兆网络如今应该成为数据中心的标配。避免kafka集群出现跨数据中心的状况，更要避免有很大的物理空间跨度，尤为中国还有诡异的联通电信问题。kafka集群中各个节点地位均等，一旦由于延时致使分布式集群不稳定，排错尤为困难。

1.五、文件系统

ext4是最佳选择。

1.六、其它

在硬件愈来愈强大和云计算如火如荼的今天，你须要在超高配置的服务器和IaaS供应商的数百个虚拟机之间作取舍。咱们建议使用中等配置的服务器，由于集群规模越大，单台超高配置的服务器运行的节点越多，集群稳定性随之降低，复杂度则会上升。

2、JVM的考虑

对于java应用，jvm和gc是绕不过去的坎。实践代表，官方JDK1.7u51会是一个不错的选择，配合以G1来作垃圾回收。推荐配置可参考：

-Xms4g -Xmx4g -XX:PermSize=48m -XX:MaxPermSize=48m -XX:+UseG1GC-XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35

注：kafka版本更新会带来变化。请随时关注。咱们如今的版本是kafka_2.11-0.8.2.1

3、File descriptors

kafka会使用大量文件和网络socket，因此，咱们须要把file descriptors的默认配置改成100000。修改方法以下：

#vi /etc/sysctl.conf

fs.file-max = 32000

#vi /etc/security/limits.conf

yourusersoftnofile10000

youruserhardnofile30000

4、关键配置项解读

尽管默认配置已经很不错，但出于性能和实际集群部署状况，咱们仍是须要讲解一些重要的配置项。除此以外，若是对某个默认参数存在质疑，在详细了解改参数的做用前，建议采用默认配置。

4.一、zookeeper.connect

必配参数，建议在kafka集群的天天机器都配置全部zk。

4.二、broker.id

必配参数。集群节点的标示符，不得重复。取值范围0~n。

4.三、log.dirs

建议参照文章前面描述的磁盘配置，不要使用默认的“/tmp/kafka-logs”

4.四、advertised.host.name

注册到zk供用户使用的主机名。内网环境一般无需配置，而IaaS通常须要配置为公网地址。默认为“host.name”，能够经过java.net.InetAddress.getCanonicalHostName()接口获取该值。

4.五、advertised.port

注册到zk供用户使用的服务端口，一般在IaaS环境须要额外配置。

4.六、num.partitions

自动建立topic的默认partition数量。默认是1，为了得到更好的性能，建议修改成更大。最优取值参考后文。

4.七、default.replication.factor

自动建立topic的默认副本数量，官方建议修改成2；但一般一个副本就足够了。

4.八、min.insync.replicas

ISR提交生成者请求的最小副本数。

4.九、unclean.leader.election.enable

是否容许不具有ISR资格的replicas选举为leader做为不得已的措施，甚至不惜牺牲部分数据。默认容许。建议容许。数据异常重要的状况例外。

4.十、controlled.shutdown.enable

在kafka收到stop命令或者异常终止时，容许自动同步数据。建议开启。

5、动态调整配置

大部分kafka配置是写死在properties文件里的。然而，许多关于topic的参数咱们能够动态调配，kafka-topic.sh工具提供了该功能，更改将一直生效直到服务器重启。能够调整的参数以下：

unclean.leader.election.enable：不严格的leader选举，有助于集群健壮，可是存在数据丢失风险。

min.insync.replicas：若是同步状态的副本小于该值，服务器将再也不接受request.required.acks为-1或all的写入请求。

max.message.bytes：单条消息的最大长度。若是修改了该值，那么replica.fetch.max.bytes和消费者的fetch.message.max.bytes也要跟着修改。

cleanup.policy：生命周期终结数据的处理，默认删除。

flush.messages：强制刷新写入的最大缓存消息数。

flust.ms：强制刷新写入的最大等待时长。

还有segment.bytes、segment.ms、retention.bytes、retention.ms和segment.jitter.ms。详见官方解释。

6、性能优化技巧

6.一、配置合适的partitons数量。

这彷佛是kafka新手必问得问题。首先，咱们必须理解，partiton是kafka的并行单元。从producer和broker的视角看，向不一样的partition写入是彻底并行的；而对于consumer，并发数彻底取决于partition的数量，即，若是consumer数量大于partition数量，则必有consumer闲置。因此，咱们能够认为kafka的吞吐与partition时线性关系。partition的数量要根据吞吐来推断，假定p表明生产者写入单个partition的最大吞吐，c表明消费者从单个partition消费的最大吞吐，咱们的目标吞吐是t，那么partition的数量应该是t/p和t/c中较大的那一个。实际状况中，p的影响因素有批处理的规模，压缩算法，确认机制和副本数等，然而，屡次benchmark的结果代表，单个partition的最大写入吞吐在10MB/sec左右；c的影响因素是逻辑算法，须要在不一样场景下实测得出。

这个结论彷佛太书生气和不实用。咱们一般建议partition的数量必定要大于等于消费者的数量来实现最大并发。官方曾测试过1万个partition的状况，因此不须要太担忧partition过多的问题。下面的知识会有助于读者在生产环境作出最佳的选择：

a、一个partition就是一个存储kafka-log的目录。

b、一个partition只能寄宿在一个broker上。

c、单个partition是能够实现消息的顺序写入的。

d、单个partition只能被单个消费者进程消费，与该消费者所属于的消费组无关。这样作，有助于实现顺序消费。

e、单个消费者进程可同时消费多个partition，即partition限制了消费端的并发能力。

f、partition越多则file和memory消耗越大，要在服务器承受服务器设置。

g、每一个partition信息都存在全部的zk节点中。

h、partition越多则失败选举耗时越长。

k、offset是对每一个partition而言的，partition越多，查询offset就越耗时。

i、partition的数量是能够动态增长的（只能加不能减）。

咱们建议的作法是，若是是3个broker的集群，有5个消费者，那么建议partition的数量是15，也就是broker和consumer数量的最小公倍数。固然，也能够是一个大于消费者的broker数量的倍数，好比6或者9，还请读者自行根据实际环境裁定。

 

本文摘自：http://www.jianshu.com/p/8689901720fd