kafka的线上部署

操作系统

linux的优势

• IO模型的使用

io模型的类型：

阻塞IO，非阻塞IO，IO多路复用，信号驱动IO，异步IO，每种IO模型都有各自典型的使用场景，比如java中socket对象的阻塞模式和非阻塞模式，对应于前两种模型，linux中的系统调用select函数属于IO多路复用，epoll系统调用则介于第三种和第四中模型中间

kafka客户端底层使用了java的selector，selector在linux的实现机制是epoll，在windows平台上的实现机制是select

• 数据网络传输效率

kafka生产消费的消息都是通过网络传输的，而消息保存在磁盘，所以kafka需要在磁盘和网路间进行大量数据传输，linux支持零拷贝技术，当数据在磁盘和网络进行传输是避免昂贵的内核态数据拷贝

• 社区支持度

磁盘

kafka大量使用磁盘，但是使用的方式是顺序读写操作，在一定程度上规避了机械磁盘最大的劣势

kafka自己实现了冗余机制来提高高可靠性，另一方面通过分区的概念，也能在软件层面自行实现负载均衡，所以RAID的优势就没那么明显了

磁盘容量

假如：每天 1 亿条 1KB 大小的消息，保存两份且留存两周的时间，那么总的空间大小就等于 1 亿 * 1KB * 2 / 1000 / 1000 = 200GB。一般情况下 Kafka 集群除了消息数据还有其他类型的数据，比如索引数据等，故我们再为这些数据预留出 10% 的磁盘空间，因此总的存储容量就是 220GB。既然要保存两周，那么整体容量即为 220GB * 14，大约 3TB 左右。Kafka 支持数据的压缩，假设压缩比是 0.75，那么最后你需要规划的存储空间就是 0.75 * 3 = 2.25TB。

考虑因素：

• 新增消息数
• 消息留存时间
• 平均消息大小
• 备份数
• 是否启用压缩带宽

带宽

假设：1 小时内处理 1TB 的业务数据，假设带宽是1Gbps的千兆网卡

由于带宽是 1Gbps，即每秒处理 1Gb 的数据，假设每台 Kafka 服务器都是安装在专属的机器上，也就是说每台 Kafka 机器上没有混部其他服务，毕竟真实环境中不建议这么做。通常情况下你只能假设 Kafka 会用到 70% 的带宽资源，因为总要为其他应用或进程留一些资源。

根据实际使用经验，超过 70% 的阈值就有网络丢包的可能性了，故 70% 的设定是一个比较合理的值，也就是说单台 Kafka 服务器最多也就能使用大约 700Mb 的带宽资源。

这只是它能使用的最大带宽资源，你不能让 Kafka 服务器常规性使用这么多资源，故通常要再额外预留出 2/3 的资源，即单台服务器使用带宽 700Mb / 3 ≈ 240Mbps

有了 240Mbps，我们就可以计算 1 小时内处理 1TB 数据所需的服务器数量了。根据这个目标，我们每秒需要处理 2336Mb 的数据，除以 240，约等于 10 台服务器。如果消息还需要额外复制两份，那么总的服务器台数还要乘以 3，即 30 台

kafka相关的重要集群参数配置

Broker端参数

存储信息：

• log.dirs：指定broker需要使用的若干个文件目录路径，已逗号分隔，最好保证这些目录挂载在不同的磁盘

分盘部署的好处：

1 提升读写性能，多块磁盘读写比单块有更高的吞吐量

2 实现故障转移，在kafka1.1版本以前，只要kafka broker使用的任何一块磁盘挂掉了，整个Broker进程会关闭，从1.1后。坏掉的磁盘的数据会自动转移到其他正常的磁盘上，而且broker还能正常工作

zk相关：

• zookeeeper.connect

如果有两套kafka集群连接同一个zk集群，假如这两套kafka集群分别叫kafka1和kafka2,那应该配置为：

zookeeeper.connect:zk1:2181,zk2:2181,zk3:2181/kafka1,zk1:2181,zk2:2181,zk3:2181/kafka2

broker连接相关：

• listerners：告诉外部连接者要通过什么协议访问指定主机名和端口开放的 Kafka 服务
• advertised.listeners：和 listeners 相比多了个 advertised。Advertised 的含义表示宣称的、公布的，就是说这组监听器是 Broker 用于对外发布的

监听器格式：协议，主机，端口号

eg:listeners=PLAINTEXT://localhost:9092,SASL_PLAINTEXT://localhost:9093

PLAINTEXT表示明文传输

Topic管理：

• auto.create.topics.enable：是否允许自动创建topic
• unclean.leader.election.enable：是否允许Unclean Leader选举
• auto.leader.rebalance.enable： 是否允许定期进行leader选举

注意：

关于Unclean选举： 当leader副本挂了的时候，并不是所有副本都有资格竞争leader，只有保存数据比较多的那些副本才有资格竞选，落后进度太多的副本没资格做这件事，当该参数设为false时，就会坚决不能让落后太多的副本竞选Leader，这样做的后果是这个分区不可用，因为没有leader，反之如果是true，kafka允许从那些跑得慢的副本中选一个出来当Leader。这样做的后果是数据有可能会丢失。该参数值默认是false

auto.leader.rebalance.enable如果设为true，那么在满足一定的条件之后， 即使LeaderA表现比较号，也可能会被强制换成LeaderB,建议生产环境将该参数设置为false

数据留存：

• log.retention.{hours|minutes|ms}：这是个“三兄弟”，都是控制一条消息数据被保存多长时间。从优先级上来说 ms 设置最高、minutes 次之、hours 最低。
• log.retention.bytes：指定broker为消息保存的总磁盘容量大小，默认值为-1,表明没有限制
• message.max.bytes：控制 Broker 能够接收的最大消息大小。默认1000012，不到1MB

Topic级别参数：topic 级别参数会覆盖全局 Broker 参数的值，而每个 Topic 都能设置自己的参数值，这就是所谓的 Topic 级别参数。

• retention.ms：规定了该 Topic 消息被保存的时长。默认是 7 天，即该 Topic 只保存最近 7 天的消息。一旦设置了这个值，它会覆盖掉 Broker 端的全局参数值。
• retention.bytes：规定了要为该 Topic 预留多大的磁盘空间。和全局参数作用相似，这个值通常在多租户的 Kafka 集群中会有用武之地。当前默认值是 -1，表示可以无限使用磁盘空间。
• max.message.bytes。它决定了 Kafka Broker 能够正常接收该 Topic 的最大消息大小

topic 级别参数的设置方式：

• 创建topic时进行设置

bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --topic transaction --partitions 1 --replication-factor 1 --config retention.ms=15552000000 --config max.message.bytes=5242880

• 修改topic时设置

bin/kafka-configs.sh --zookeeper localhost:2181 --entity-type topics --entity-name transaction --alter --add-config max.message.bytes=10485760

Jvm参数:

• KAFKA_HEAP_OPTS：指定堆大，通用建议是6GB
• KAFKA_JVM_PERFORMANCE_OPTS：指定 GC 参数。使用java8,可以手动设置G1收集器，比CMS出色，主要体现在更少的Full GC

export KAFKA_HEAP_OPTS=--Xms6g  --Xmx6g
export KAFKA_JVM_PERFORMANCE_OPTS= -server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+ExplicitGCInvokesConcurrent -Djava.awt.headless=true
bin/kafka-server-start.sh config/server.properties

操作系统参数:

• 文件描述符限制
• 文件系统类型
• Swappiness
• 提交时间：稍微调大Flush落盘时间