Kafka快速入门（六）——Kafka集群部署

一、Kafka集群部署方案规划
1、操作系统选择
通常，生产环境应该将Kafka集群部署在Linux操作系统上，原因如下：
（1）Kafka客户端底层使用了Java的selector，selector在Linux上的实现机制是epoll，而在Windows平台上的实现机制是select，因此Kafka部署在Linux上能够获得更高效的I/O性能。
（2）网络传输效率的差别。Kafka需要在磁盘和网络间进行大量数据传输，在Linux部署Kafka能够享受到零拷贝（Zero Copy）技术所带来的快速数据传输特性。
（3）社区的支持度。Apache Kafka社区目前对Windows平台上发现的Kafka Bug不做任何承诺。

2、磁盘
（1）Kafka实现了冗余机制来提供高可靠性，并通过分区机制在软件层面实现负载均衡，因此Kafka的磁盘存储可以不使用磁盘阵列（RAID），使用普通磁盘组成存储空间即可。
（2）使用机械磁盘能够胜任Kafka线上环境，但SSD显然性能更好。

3、磁盘容量
规划磁盘容量时需要考虑：新增消息数、消息留存时间、平均消息大小、备份数、是否启用压缩等因素。
假设公司业务每天需要向Kafka集群发送100000000条消息，每条消息保存两份以防止数据丢失，消息默认保存7天时间，消息的平均大小是1KB，Kafka的数据压缩比是0.75。
每天100000000条1KB大小的消息，保存两份，压缩比0.75，占用空间大小就等于150GB(1000000001KB2/1000/10000.75)，考虑到Kafka集群的索引数据等，需要预留出10%的磁盘空间，因此每天总存储容量是165GB。数据留存7天，因此规划磁盘容量为1155GB（165GB7）。

4、网络带宽
假设公司的机房环境是千兆网络，即1Gbps，业务需要在1小时内处理1TB的业务数据。假设Kafka Broker会用到70%的带宽资源，超过70%的阈值可能网络丢包，单台Kafka Broker最多能使用大约700Mb的带宽资源，但通常需要再额外为其它服务预留出2/3的资源，即Kafka Broker可以为Kafka服务分配带宽240Mbps（700Mb/3）。1小时处理1TB数据，则每秒需要处理2336Mb（102410248/3600）数据，除以240，约等于10台服务器。如果还需要额外复制两份，那么服务器台数还要乘以3，即30台。

二、Kafka集群参数配置
1、Broker端参数
Broker端参数也被称为静态参数（Static Configs），静态参数只能在Kafka的配置文件server.properties中进行设置，必须重启Broker进程才能生效。
log.dirs：指定Broker需要使用的若干个文件目录路径，没有默认值，必须指定。在生产环境中一定要为log.dirs配置多个路径，如果条件允许，需要保证目录被挂载到不同的物理磁盘上。优势在于，提升读写性能，多块物理磁盘同时读写数据具有更高的吞吐量；能够实现故障转移（Failover），Kafka 1.1版本引入Failover功能，坏掉磁盘上的数据会自动地转移到其它正常的磁盘上，而且Broker还能正常工作，基于Failover机制，Kafka可以舍弃RAID方案。
zookeeper.connect：CS格式参数，可以指定值为zk1:2181,zk2:2181,zk3:2181，不同Kafka集群可以指定：zk1:2181,zk2:2181,zk3:2181/kafka1，chroot只需要写一次。
listeners：设置内网访问Kafka服务的监听器。
advertised.listeners：设置外网访问Kafka服务的监听器。
auto.create.topics.enable：是否允许自动创建Topic。
unclean.leader.election.enable：是否允许Unclean Leader 选举。
auto.leader.rebalance.enable：是否允许定期进行Leader选举，生产环境中建议设置成false。
log.retention.{hours|minutes|ms}：控制一条消息数据被保存多长时间。优先级：ms设置最高、minutes次之、hours最低。
log.retention.bytes：指定Broker为消息保存的总磁盘容量大小。message.max.bytes：控制Broker能够接收的最大消息大小。