kafka真实环境部署规划（转载）

kafka真实环境部署规划

1. 操做系统选型

由于kafka服务端代码是Scala语言开发的，所以属于JVM系的大数据框架，目前部署最多的3类操做系统主要由Linux ，OS X 和Windows,可是部署在Linux数量最多，为何呢？由于I/O模型的使用和数据网络传输效率两点。

• 第一：Kafka新版本的Clients在设计底层网络库时采用了Java的Select模型，而在Linux实现机制是epoll,感兴趣的读者能够查询一下epoll和select的区别，明确一点就是：kafka跑在Linux上效率更高，由于epoll取消了轮询机制，换成了回调机制，当底层链接socket数较多时，能够避免CPU的时间浪费。
• 第二：网络传输效率上。kafka须要经过网络和磁盘进行数据传输，而大部分操做系统都是经过Java的FileChannel.transferTo方法实现，而Linux操做系统则会调用sendFile系统调用，也即零拷贝（Zero Copy 技术），避免了数据在内核地址空间和用户程序空间进行重复拷贝。

2. 磁盘类型规划

• 机械磁盘（HDD） 通常机械磁盘寻道时间是毫秒级的，如有大量随机I/O，则将会出现指数级的延迟，可是kafka是顺序读写的，所以对于机械磁盘的性能也是不弱的，因此，基于成本问题能够考虑。
• 固态硬盘（SSD） 读写速度可观，没有成本问题能够考虑。
• JBOD (Just Bunch Of Disks ) 经济实惠的方案，对数据安全级别不是很是很是高的状况下能够采用，建议用户在Broker服务器上设置多个日志路径，每一个路径挂载在不一样磁盘上，能够极大提高并发的日志写入速度。
• RAID 磁盘阵列 常见的RAID是RAID10，或者称为（RAID 1+0） 这种磁盘阵列结合了磁盘镜像和磁盘带化技术来保护数据，由于使用了磁盘镜像技术，使用率只有50%，注意，LinkedIn公司采用的就是RAID做为存储来提供服务的。那么弊端在什么地方呢？若是Kafka副本数量设置为3，那么实际上数据将存在6倍的冗余数据，利用率实在过低。所以，LinkedIn正在计划更改方案为JBOD.

3. 磁盘容量规划

咱们公司物联网平台天天大约可以产生一亿条消息，假设副本replica设置为2 （其实咱们设置为3），数据留存时间为1周，平均每条上报事件消息为1K左右，那么天天产生的消息总量为：1亿 乘 2 乘 1K 除以 1000 除以 1000 =200G磁盘。预留10%的磁盘空间，为210G。一周大约为1.5T。采用压缩，平均压缩比为0.5，总体磁盘容量为0.75T。 关联因素主要有：

• 新增消息数
• 副本数
• 是否启用压缩
• 消息大小
• 消息保留时间

4. 内存容量规划

kafka对于内存的使用，并不过多依赖JVM 内存,而是更多的依赖操做系统的页缓存，consumer若命中页缓存，则不用消耗物理I/O操做。通常状况下，java堆内存的使用属于朝生夕灭的，很快会被GC,通常状况下，不会超过6G，对于16G内存的机器，文件系统page cache 能够达到10-14GB。

• 怎么设计page cache，能够设置为单个日志段文件大小，若日志段为10G,那么页缓存应该至少设计为10G以上。
• 堆内存最好不要超过6G。

5. CPU选择规划

kafka不属于计算密集型系统，所以CPU核数够多就能够，而没必要追求时钟频率，所以核数选择最好大于8。

6. 网络带宽决定Broker数量

带宽主要有1Gb/s 和10 Gb/s 。咱们能够称为千兆位网络和万兆位网络。举例以下： 咱们的物联网系统一天每小时都要处理1Tb的数据，咱们选择1Gb/b带宽，那么须要选择多少机器呢？

• 假设网络带宽kafka专用，且分配给kafka服务器70%带宽，那么单台Borker带宽就是710Mb/s，可是万一出现突发流量问题，很容易把网卡打满，所以在下降1/3,也即240Mb/s。由于1小时处理1TTB数据，每秒须要处理292MB,1MB=8Mb，也就是2336Mb数据，那么一小时处理1TB数据至少须要2336/240=10台Broker数据。冗余设计，最终能够定为20台机器。

做者：凯新的技术社区
连接：https://juejin.im/post/5bd464...
来源：掘金
著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。

1. kafka生产者吞吐量测试指标

kafka-producer-perf-test :是kafka提供的测试Producer性能脚本，经过脚本，能够计算出Producer在一段时间内的平均延时和吞吐量。

1.1 kafka-producer-perf-test

在kafka安装目录下面执行以下命令,生产环境中尽可能让脚本运行较长的时间，才会有意义：

bin/kafka-producer-perf-test.sh --topic test --num-records 500000 --record-size 200 --througthput -1 --producer-props bootstrap.servers=bd-master:9092,bd-slave1=9092,bd-slave3=9092 acks=1

1.2 测试结果分析以下：

500000 records sent ,41963 records/sec (8.00 MB/sec),2362.85 ms/avg latency ,3513.00 ms max latency ,2792ms 50h ,3144ms 95th ,3364 ms 99h,3503ms 99.9th

看到上面的结果确定蒙了，看我细细讲来： kafka 的平均吞吐量是8.00 MB/sec ，即占用64Mb/s左右的带宽，平均每一秒发送41963条消息。平均延时为2362.85 ms，最大延时为3513.00 ms，95%的消息发送须要3144ms，99%的消息发送须要3364ms，99.9%的消息发送须要3503ms。

2. kafka消费者吞吐量指标说明：

2.1 kafka-consumer-perfs

咱们总共测试500万条数据量 bin/kafka-consumer-perfs-test.sh --broker-list bd-master:9092,bd-slave1=9092,bd-slave3=9092 --message-size 200 --messages 500000 --topic test

2.2 获得以下结果：

2018-10-28 9:39:02 95.4188 92.2313 500271 484289 看到上面的结果确定蒙了，看我细细讲来： 该环境下，1s内总共消费了95.4188MB消息，吞吐量为92.2313MB/s,也即736Mb/s。

做者：凯新的技术社区
连接：https://juejin.im/post/5bd50b...
来源：掘金
著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。

1. Producer核心工做流程

• Producer首先使用用户主线程将待发送的消息封装进一个ProducerRecord类实例中。
• 进行序列化后，发送给Partioner，由Partioner肯定目标分区后，发送到Producer程序中的一块内存缓冲区中。
• Producer的另外一个工做线程（即Sender线程），则负责实时地从该缓冲区中提取出准备好的消息封装到一个批次的内，统一发送给对应的broker中。

2. producer 主要参数设置

2.1 producer 参数acks 设置（无数据丢失）

在消息被认为是“已提交”以前，producer须要leader确认的produce请求的应答数。该参数用于控制消息的持久性，目前提供了3个取值：

acks = 0: 表示produce请求当即返回，不须要等待leader的任何确认。这种方案有最高的吞吐率，可是不保证消息是否真的发送成功。

acks = -1: 表示分区leader必须等待消息被成功写入到全部的ISR副本(同步副本)中才认为produce请求成功。这种方案提供最高的消息持久性保证，可是理论上吞吐率也是最差的。

acks = 1: 表示leader副本必须应答此produce请求并写入消息到本地日志，以后produce请求被认为成功。若是此时leader副本应答请求以后挂掉了，消息会丢失。这是个这种的方案，提供了不错的持久性保证和吞吐。

商业环境推荐：

若是要较高的持久性要求以及无数据丢失的需求，设置acks = -1。其余状况下设置acks = 1

2.2 producer参数 buffer.memory 设置（吞吐量）

该参数用于指定Producer端用于缓存消息的缓冲区大小，单位为字节，默认值为：33554432合计为32M。kafka采用的是异步发送的消息架构，prducer启动时会首先建立一块内存缓冲区用于保存待发送的消息，而后由一个专属线程负责从缓冲区读取消息进行真正的发送。

商业环境推荐：

• 消息持续发送过程当中，当缓冲区被填满后，producer当即进入阻塞状态直到空闲内存被释放出来，这段时间不能超过max.blocks.ms设置的值，一旦超过，producer则会抛出TimeoutException 异常，由于Producer是线程安全的，若一直报TimeoutException，须要考虑调高buffer.memory 了。
• 用户在使用多个线程共享kafka producer时，很容易把 buffer.memory 打满。

2.3 producer参数 compression.type 设置（lZ4）

producer压缩器，目前支持none（不压缩），gzip，snappy和lz4。

商业环境推荐：

基于公司物联网平台，试验过目前lz4的效果最好。固然2016年8月，FaceBook开源了Ztandard。官网测试： Ztandard压缩率为2。8，snappy为2.091，LZ4 为2.101 。

2.4 producer参数 retries设置(注意消息乱序,EOS)

producer重试的次数设置。重试时producer会从新发送以前因为瞬时缘由出现失败的消息。瞬时失败的缘由可能包括：元数据信息失效、副本数量不足、超时、位移越界或未知分区等。假若设置了retries > 0，那么这些状况下producer会尝试重试。

商业环境推荐：

• producer还有个参数：max.in.flight.requests.per.connection。若是设置该参数大约1，那么设置retries就有可能形成发送消息的乱序。
• 版本为0.11.1.0的kafka已经支持"精确到一次的语义”，所以消息的重试不会形成消息的重复发送。

2.5 producer参数batch.size设置(吞吐量和延时性能)

producer都是按照batch进行发送的，所以batch大小的选择对于producer性能相当重要。producer会把发往同一分区的多条消息封装进一个batch中，当batch满了后，producer才会把消息发送出去。可是也不必定等到满了，这和另一个参数linger.ms有关。默认值为16K，合计为16384.

商业环境推荐：

• batch 越小，producer的吞吐量越低，越大，吞吐量越大。

2.6 producer参数linger.ms设置(吞吐量和延时性能)

producer是按照batch进行发送的，可是还要看linger.ms的值，默认是0，表示不作停留。这种状况下，可能有的batch中没有包含足够多的produce请求就被发送出去了，形成了大量的小batch，给网络IO带来的极大的压力。

商业环境推荐：

• 为了减小了网络IO，提高了总体的TPS。假设设置linger.ms=5，表示producer请求可能会延时5ms才会被发送。

2.7 producer参数max.in.flight.requests.per.connection设置(吞吐量和延时性能)

producer的IO线程在单个Socket链接上可以发送未应答produce请求的最大数量。增长此值应该能够增长IO线程的吞吐量，从而总体上提高producer的性能。不过就像以前说的若是开启了重试机制，那么设置该参数大于1的话有可能形成消息的乱序。

商业环境推荐：

• 默认值5是一个比较好的起始点,若是发现producer的瓶颈在IO线程，同时各个broker端负载不高，那么能够尝试适当增长该值.
• 过大增长该参数会形成producer的总体内存负担，同时还可能形成没必要要的锁竞争反而会下降TPS

做者：凯新的技术社区
连接：https://juejin.im/post/5bd51b...
来源：掘金
著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。

调整partiton

调整partition能够直接执行以下命令：

./kafka-topics.sh --alter --topic topicName --zookeeper $ZK_HOST_NODE --partitions partitionNum

注意替换topicName、$ZK_HOST_NODE和partitionNum三个参数。

调整replica factor

调整replica-factor须要先建立一个json描述文件replica.json，大体以下：

{
    "version": 1,
    "partitions": [
        {
            "topic": "topicName",
            "partition": 0,
            "replicas": [
,
 
            ]
        },
        {
            "topic": "topicName",
            "partition": 1,
            "replicas": [
,
 
            ]
        },
        {
            "topic": "topicName",
            "partition": 2,
            "replicas": [
,
 
            ]
        }
    ]
}

在描述文件中说明分区和副本所在broker的Id的映射。

然后在replica.json所在的位置执行以下命令：

$KAFKA_HOME/bin/kafka-reassign-partitions.sh --zookeeper $ZK_HOST_NODE  --reassignment-json-file replica.json --execute

另外，kafka-manager是个好东西，能够直接在界面上完成partiton数目的调整。惋惜不能调整replica-factor。

转载于:https://www.cnblogs.com/bigbe...