彩世界平台-彩世界时时app-彩世界开奖app苹果下载

热门关键词: 彩世界平台,彩世界时时app,彩世界开奖app苹果下载

您的位置:彩世界平台 > 活动会议 > 【彩世界平台】Kafka性能优化之坎坷路(2),kafka性

【彩世界平台】Kafka性能优化之坎坷路(2),kafka性

发布时间:2019-09-04 22:42编辑:活动会议浏览(193)

    Kafka性能优化之坎坷路(2),kafka性能优化

    接上一篇:

    题外话:
     上一篇简单说了一下自己对kafka的一些基础理解,以及c++中如何利用librdkafka来实现我们自己的业务需求。这一篇就来研究研究一些另类玩法,跟代码无关,用到的技术也不算新,但是令我感到意外的是,竟然没有人这么使用过,实践过。。。
     我挺难受的,这么一些通用且实用,而且通过很简单的操作就能提升数倍性能的方法,竟然甚少人去使用他们,甚至闻所未闻。忽然觉得中国这个IT环境里,怎么才能造就出伟大的程序员,公司注重的是利益,领导注重的是结果,不懂技术的人做领导,懂技术的人被领导,面试靠张嘴,工作靠开会,晋升靠资历,找工作靠学历。。。
     百分之99的项目,“先出一个版本,后面再考虑优化”“这个需求很简单,怎么实现我不管,明天我就要”,然而。。永远没有时间梳理,也无暇思考。项目永远很急,程序员永远在加班。。。以前的代码永远要靠下一任调bug。。。

    扯远了,回归正题吧。

    一.Kafka环境搭建
     网上有很多环境搭建的教程示例,看了一下,几乎全是千篇一律,都是相互转过来转过去,没有考虑到实际应用场景,也不考虑性能到底怎么样,也不考虑为何要这么搭,反正大家都是按这个套路来的,甚至我想找一篇搭建5个节点集群的都找不到。
     实际生产环境中,我们的kafka是搭建在服务器上的,我们都知道每台服务器搭建一个节点,多个节点组成一个集群。我们也知道kafka的性能瓶颈是在网络IO和磁盘读写速度上。
    正常情况下这么搭建当然是没问题的,而且kafka本身是为短消息而设计的,但是在绝大多数应用场景中,我们不得不实时传输图片这种大消息,假设我们要搭建一个支持日吞吐量4000万数据的集群,每条消息1M,
    我们来算一下:
     假设每个节点带宽是1000Mbps,可传输的字节数就1000/8=125M, 如果要支持每秒钟处理500条数据,那需要一个多大的集群呢?
    好的,500条*1M=500M, 500M/125M=4。 也就是4个节点的集群。没毛病吧老铁?
    没毛病么?毛病很大啊。我们算的这500M仅仅是数据吞吐量的带宽,但是吞吐量吞吐量,有吞也有吐啊。
    最简单的1份生产1份消费,各需要占掉其中一半的带宽,那我们要达到每秒钟生产500条消费500条,最少就需要1000M字节的带宽。
    这只是最理想的环境,实际应用中,必然不止一个用户要从kafka中消费数据,假设有3个用户要从集群中消费数据,还要支持每秒500条,这就意味着我这个集群的吞吐总量要达到每秒钟2000M字节,网络io比特率要满足每秒钟20000Mbps,如果每个节点采用千兆网卡,那意味着我需要一个由20台服务器组成的集群。一台服务器保守点配置一般的5万块钱一台,那就需要100万成本。
    这明显不对啊,kafka不是号称吞吐量宇宙第一的么,怎么会要靠堆积服务器的数量来满足仅仅是每秒处理500条数据的需求呢?
    这其中一定有问题,我要去找官方要个说法去,这跟你们吹出来的完全不符合啊,逗我呢吧?
    求带麻袋,我们再仔细回过头来想一想,问题出在哪呢,我们的计算也没问题,这还是算的最最理想的情况下,实际的生产环境可能更差。不对,一定有问题。

    仔细屡了又屡,真的没问题,我们公司就是这么用的啊,我们公司也是这么用的啊,没毛病吧老铁?
    没毛病么?毛病很大啊。通过上面的计算我们很显然会得出一个强有力而且官方可验证的结论,限制kafka性能的只能是网络带宽不够大。有没有办法解决呢?换万兆带宽?整个都换成万兆,那不得了,成本又翻了一倍,200万成本。

    好吧,接下来就是我们如何解决这个网络瓶颈的实践之路了:
        既然我们的瓶颈是在网络上,网络的瓶颈又是在网卡上,把千兆网卡换万兆网卡又不现实,那就只剩一条路了,加多块网卡。OK,一般的服务器都支持4网口+1管理口,先来插上四根网线,配置四个ip地址。没毛病,然后我们就想了,既然都有四块网卡,每块网卡又有独立的ip地址了,那我们是不是可以在一台机器上搭建4个kafka节点,每个节点绑定一块网卡呢,来试试吧,很激动。。。按照教程,一步一步,摩擦摩擦,biu的一。。。。纳尼??竟然起不来??难道我配置出问题了?检查一遍,给我起。。。检查两遍,给我起。。。检查三遍。。。百度谷歌,检查四遍。。。什么鬼???kafka难道不支持在一台机器上开多个进程?不对啊,不是还有在一台机器上搭建伪集群的教程摆在那呢,那说明不是kafka的问题。然后又是一顿查,一顿乱试,终于。。我们检验出了真相:在同一台机器上起多个kafka需要配置端口号不一样,而且新版kafka逐渐废弃了host.name和port这两个配置项,所有相关的配置,只需要配置listeners即可。
    再全部删掉重新来过,配网卡ip,配listeners,给我起!哈哈哈,终于起来了,而且可以正常生产消费数据了,我真是太厉害了,这么难的问题竟然被我搞定了,经过这么多努力,我们终于可以实现一块网卡对应一个kafka节点的伟大愿望了,还有谁??  然而。。。俗话说的好。。。不要高兴的太早。。。太早。。早。。

    来吧,让我们看一看你的网络IO瓶颈能不能达到4000Mbps吧,手指飞快的输入一串代码:sar -n DEV 1  
    当当当。。随着生产线程数的增多,网络io很快达到1000Mbps了,我要再加10个生产! sar -n DEV 1 当当当。。。什么?网络io竟然还是1000Mbps,不对不对,怎么肥四?抓个包看一看,四个ip分别建立tcp链接并开始交互数据,没问题啊,再仔细一瞅,我去,为啥所有ip指向的都是同一个mac地址,这不科学啊,是在逗我吧?我不信,肯定是我哪里配置错了,肯定是我心不够虔诚,肯定是我启动的方式不对。。。我不信,我不信。。。我不信。。。让我们再试一遍。。两遍。。。三遍。。。
    求带麻袋,所有网卡ip都指向了一个mac地址,是不是说需要手动配置网卡的路由信息,让每个网卡都通过自己的路由来转发数据,查资料,看教程,看man手册,配置路由。。让我们再虔诚的试一次。。。试两次。。。试三次。。。不玩了。。我要回家,我想妈妈。。。

    静下心来再想想:我们现在可以确认的是,在一台机器上搭建集群是可行的,只需配置端口号不一样即可,每个kafka节点绑定一块网卡的方式不可行,即使把套接字绑定到一个特定网卡的ip上,数据包离开主机时会首先经过路由表,路由表会寻找最低成本的网络接口(任意静态的接口)进行发送,我们配置的四块网卡具有相同的成本,因为四块网卡是在同一个子网内(即同一个网段),因此传输率不会超过单张网卡的传输率,如果要解决这个问题,那么可行的途径是手动配置路由表信息,而且要保证四块网卡的ip位于不同的网段上,并要确保不同的网段是可以连通的。

    好吧,实际应用中我们是被分配ip的那一个,而不是可以任意分配网段的那一个,显然这种方式也不可行,但是起码我们总结出了一套可行方案不是么。

    我们花了大量的时间研究kafka跟网卡之间的关系,但忽然回过头来想,发现我们不知不觉中绕了一个大弯。归根结底,我们是要解决网络带宽的问题,结果反而把自己绕到跟kafka的关联上了,既然在一台机器上可以搭建伪集群,那么为什么不把这台机器的所有网卡做一个绑定呢?

    从Centos7开始使用team模式,链路聚合的方式进行多网卡绑定,让我们来试一试吧:
    详细说明请参考官方文档:

    要明确的是,用于绑定的网卡,不应该配置任何静态的IP地址,进行绑定之前,需要将所有网卡恢复到初始化状态。而且一台服务器只能有一个网关。
    我们需要的是增加带宽模式的绑定,至于其它模式,请自行研究,通过NetworkManager来配置一下:

    1. 创建team1,并选择模式:
      命令:nmcli connection add con-name team1 type team ifname team1 config '{"device": "team1", "runner": {"name": "loadbalance","tx_hash": ["eth", "ipv4", "ipv6"],"tx_balancer": {"name": "basic"}}}'
    1. 添加网卡进行绑定(本机一共四块网卡)
      命令:nmcli connection add con-name team1-port1 type team-slave ifname enp2s0f0 master team1
      nmcli connection add con-name team1-port2 type team-slave ifname enp2s0f1 master team1
      nmcli connection add con-name team1-port3 type team-slave ifname enp2s0f2 master team1
      nmcli connection add con-name team1-port4 type team-slave ifname enp2s0f3 master team1
    1. 给绑定后的虚拟网卡设置IP地址和网关
      命令:nmcli connection modify team1 ipv4.addresses 192.20.25.100/24 ipv4.gateway 192.20.25.254 ipv4.method manual
      备注:ipv4.addresses 192.20.25.100/24这里是四块网卡聚合成一块网卡的ip地址和子网掩码缩写。
      ipv4.gateway 192.20.25.254这里是网卡的网关配置。
    1. 启动team1
      命令:nmcli connection up team1 

    5.重启网络
    命令:systemctl restart network

    1. 查看状态
      命令:teamdctl team1 state
      备注:这里应该显示了4块网卡的信息。
    1. 列出team1的端口
      命令:teamnl team1 ports
      备注:这里应该显示了4块网卡的信息。

    其余的操作:nmcli device disconnect  enp2s0f0 (禁用其中的一块)
    nmcli device connect enp2s0f0(启用其中的一块)
    ip link set down enp2s0f0 (关闭掉其中的一块进行测试)

    1. 查看网络
      命令:ip add
      备注:这里就可以显示出team1的信息(ip和网关等信息)。

    至此,配置多网卡链路聚合结束。

    万分期待中,我们在其之上搭建了一个kafka伪集群,开始测试。。。开10个生产!
    当当当。。。网络IO达到1000Mbps,2000Mbs,3000Mbps,3600Mbps...天呐,竟然成功了。。。而且带宽损失率竟然不超过百分之10.。。

    我们成长在一个幸运的时代,学习进步的成本如此之小,

    我们成长在一个不幸的时代,学习进步的成本如此之大。

    参考

    kafka 技术分享
    如何确定Kafka的分区数,key和consumer线程数,以及不消费问题解决
    kafka性能参数和压力测试揭秘
    kafka producer线程与吞吐量

    1.partition数量配置

    partition数量由topic的并发决定,并发少则1个分区就可以,并发越高,分区数越多,可以提高吞吐量。

    创建topic时指定topic数量
    bin/kafka-topics.sh --create --zookeeper 10.25.58.35:2181 --replication-factor 3 --partitions 3 --topic test8

    2.日志保留策略设置

    当kafka broker的被写入海量消息后,会生成很多数据文件,占用大量磁盘空间,kafka默认是保留7天,建议根据磁盘情况配置,避免磁盘撑爆。

    log.retention.hours=72

    段文件配置1GB,有利于快速回收磁盘空间,重启kafka加载也会加快(如果文件过小,则文件数量比较多,kafka启动时是单线程扫描目录(log.dir)下所有数据文件)

    log.segment.bytes=1073741824

    3.文件刷盘策略

    为了大幅度提高producer写入吞吐量,需要定期批量写文件。建议配置:

    每当producer写入10000条消息时,刷数据到磁盘
    log.flush.interval.messages=10000

    每间隔1秒钟时间,刷数据到磁盘
    log.flush.interval.ms=1000

    4.网络和io操作线程配置优化

    一般num.network.threads主要处理网络io,读写缓冲区数据,基本没有io等待,配置线程数量为cpu核数加1.

    broker处理消息的最大线程数
    num.network.threads=xxx

    num.io.threads主要进行磁盘io操作,高峰期可能有些io等待,因此配置需要大些。配置线程数量为cpu核数2倍,最大不超过3倍.

    broker处理磁盘IO的线程数
    num.io.threads=xxx

    加入队列的最大请求数,超过该值,network thread阻塞

    queued.max.requests=5000

    server使用的send buffer大小。

    socket.send.buffer.bytes=1024000

    server使用的recive buffer大小。

    socket.receive.buffer.bytes=1024000

    5.异步提交(kafka.javaapi.producer)

    采用同步:1000条8s;
    采用异步:100条或3s异步写入,速度提升为1w条2s(ProducerConfig)

    request.required.acks=0  
    producer.type=async     
    ##在异步模式下,一个batch发送的消息数量。producer会等待直到要发送的消息数量达到这个值,之后才会发送。但如果消息数量不够,达到queue.buffer.max.ms时也会直接发送。       
    batch.num.messages=100  
    ##默认值:200,当使用异步模式时,缓冲数据的最大时间。例如设为100的话,会每隔100毫秒把所有的消息批量发送。这会提高吞吐量,但是会增加消息的到达延时
    queue.buffering.max.ms=100  
    ##默认值:5000,在异步模式下,producer端允许buffer的最大消息数量,如果producer无法尽快将消息发送给broker,从而导致消息在producer端大量沉积,如果消息的条数达到此配置值,将会导致producer端阻塞或者消息被抛弃。
    queue.buffering.max.messages=1000 ##发送队列缓冲长度
    ##默认值:10000,当消息在producer端沉积的条数达到 queue.buffering.max.meesages 时,阻塞一定时间后,队列仍然没有enqueue(producer仍然没有发送出任何消息)。此时producer可以继续阻塞或者将消息抛弃,此timeout值用于控制阻塞的时间,如果值为-1(默认值)则 无阻塞超时限制,消息不会被抛弃;如果值为0 则立即清空队列,消息被抛弃。
    queue.enqueue.timeout.ms=100     
    compression.codec=gzip
    

    本文由彩世界平台发布于活动会议,转载请注明出处:【彩世界平台】Kafka性能优化之坎坷路(2),kafka性

    关键词: