最近接触到一个应用程序流量分析的项目,类似于友盟,涉及到几个C端(客户端)高并发的接口,这几个接口主要用于C端数据的提交。在没有任何缓冲的情况下,一个接口涉及到5张表的提交。压测的结果很不理想,主要瓶颈就在与RDS的交互。
一台双核,16 g机子,单实例,jdbc最大连接数100年,吞吐量竟然只有50个tps。
能想到的改造方案就是引入一层缓冲,让C端接口不与RDS直接交互,很自然就想到了rabbitmq,但是rabbitmq对分布式的支持比较一般,我们的数据体量也比较大,所以我们借鉴了友盟,引入了卡夫卡,卡夫卡是一种高吞吐量的分布式发布订阅消息系统,起初在不做任何卡夫卡优化的时候,简单地将C端提交的数据直接发送到单节点卡夫卡,就这样,我们的吞吐量达到100 tps了。还是有点小惊喜的。
最近一段时间研究了一下卡夫卡,对一些参数进行调整,目前接口的吞吐量已经达到220 tps,写这篇文章主要想记录一下自己优化和部署经历。
<强>
这张图很好的诠释了卡夫卡的结构,但是遗漏了一点,就是集团的概念,我这里补充一下,一个组可以包含多个消费者对多个话题进行消费,但是不同组的消费都是独立的。
也就是说同一个主题的同一条消息可以被不同组的消费者消费。
集群化都很好理解,那什么是多分区?
分区是主题的一个概念,即对话题进行分组,不同分区之间的消费相互独立,并且有序,并且一个partiton只能被一个消费者消费,所以咯,假如主题只有一个分区的话,那么消费者实例不能大于一个,那实例再多也没的用,受限于卡夫卡的分区。
上面都是讲消费,其实送操作也是一样的,要保证有序必然要等上一个发送ack之后,下一个发送才能进行,如果只有一个分区,那送之后的ack的等待时间必然会阻塞下面一次发送,设计多个分区之后,可以同时往多个分区发送消息,自然吞吐量也就上去。
<强>
准备两台机子,然后去官网(http://kafka.apache.org/downloads)下载一个包。通过scp到服务器上,解压进入配置目录、编辑server.config。
第一台机子配置(172.18.240.36):
第二台机子配置(172.18.240.62):
代理。id=1每台服务器的代理。id都不能相同
新增或者修改成以上配置。
对了,在此之前请先安装动物园管理员,如果你用的是管理员集群的话,zookeeper.connect可以填写多个,中间用逗号隔开。
然后启动
测试一下:
在第一台机子上开启一个制作人
在第二台机子上开启一个消费者
第一台机子发送一条消息
第二台机子立马收到消息
这样卡夫卡的集群部署就完成了。就下来我们来看看,java的客户端代码如何编写。
