1.引言
创新互联建站长期为近千家客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为耒阳企业提供专业的成都网站设计、做网站、
成都外贸网站建设公司，
耒阳网站改版等技术服务。拥有10多年丰富建站经验和众多成功案例,为您定制开发。
最近接触到一个APP流量分析的项目，类似于友盟。涉及到几个C端（客户端）高并发的接口，这几个接口主要用于C端数据的提交。在没有任何缓冲的情况下，一个接口涉及到5张表的提交。压测的结果很不理想，主要瓶颈就在与RDS的交互。
一台双核，16G机子，单实例，jdbc大连接数100，吞吐量竟然只有50TPS。
能想到的改造方案就是引入一层缓冲，让C端接口不与RDS直接交互，很自然就想到了rabbitmq,但是rabbitmq对分布式的支持比较一般，我们的数据体量也比较大，所以我们借鉴了友盟，引入了kafka,Kafka是一种高吞吐量的分布式发布订阅消息系统，起初在不做任何kafka优化的时候，简单地将C端提交的数据直接send到单节点kafka,就这样，我们的吞吐量达到了100TPS.还是有点小惊喜的。
最近一段时间研究了一下kafka,对一些参数进行调整，目前接口的吞吐量已经达到220TPS,写这篇文章主要想记录一下自己优化和部署经历。
2.kafka简介
kafka的结构图
这张图很好的诠释了kafka的结构，但是遗漏了一点，就是group的概念，我这里补充一下，一个组可以包含多个consumer对多个topic进行消费，但是不同组的消费都是独立的。
也就是说同一个topic的同一条消息可以被不同组的consumer消费。
我这里的主要的优化途径就是将kafka集群化，多partition化，使其并发度更高。
集群化都很好理解，那什么是多partition？
partition是topic的一个概念，即对topic进行分组，不同partition之间的消费相互独立，并且有序。并且一个partiton只能被一个消费者消费，所以咯，假如topic只有一个partition的话，那么消费者实例不能大于一个，那实例再多也没用，受限于kafka的partition。
上面都是讲消费，其实send操作也是一样的，要保证有序必然要等上一个发送ack之后，下一个发送才能进行，如果只有一个partition，那send之后的ack的等待时间必然会阻塞下面一次send,设计多个partition之后，可以同时往多个partition发送消息，自然吞吐量也就上去。
3.kafka集群的搭建以及参数配置
集群搭建
准备两台机子，然后去官网（http://kafka.apache.org/downloads）下载一个包。通过scp到服务器上，解压进入config目录，编辑server.config.
第一台机子配置（172.18.240.36）：
broker.id=0 每台服务器的broker.id都不能相同
#hostname
host.name=172.18.240.36
#在log.retention.hours=168 下面新增下面三项
message.max.byte=5242880
default.replication.factor=2
replica.fetch.max.bytes=5242880
#设置zookeeper的连接端口
zookeeper.connect=172.18.240.36:4001
#默认partition数
num.partitions=2
本文题目：kafka生产实践(详解)-创新互联
路径分享：
http://cdkjz.cn/article/dcohph.html
