实际业务问题
在实际的业务中，因业务方要求，每天从三方拉取一定100W用户的三方数据，具体就是 提供uid，然后每天进行离线跑批。前期是部署多个jar实例，然后将名单拆分成多分，然后python脚本读取uid，然后调用java接口。但是因为调用量上不去。
后来就进行优化了一版本，通过将用户写入到kafka中，然后异步消费，同时将分区设置为12个大大提升了性能。
刚开始想一下子直接写入上百万的用户信息，Kafka会不会吃不消，后来发现其实是多虑了。
所以结合一个场景 来聊聊如何做一个集群部署方案。
亿级流量电商 设计
电商系统中，每日首页的点击其实是非常频繁的，如果说针对一个千万级别用户的APP，每日首页可能有上亿的点击。如果一个用户生成10条数据。那就是10亿数据。
根据二八原则，其实流量高峰期，一般都是中午或者指定时间端（假设在12到4点之间）。也就是有8亿数据。
每小时：接近6W条消息。但是为了应对可能出现的峰值，5/6倍左右。
操作系统
实际的生产一定是使用linux。主要在于IO模型、数据网络传输率、社区支持度。
Linux系统调用select函数属于IO多路复用模型。实现就是epoll，可以获取更高的IO性能。
Kafka需要大量的磁盘读写，可以通过零拷贝。避免从磁盘到用户态，用户态到网络缓冲区的写入。
磁盘
Kafka是顺序读写文件的，所以采用普通机械硬盘就可以。
磁盘容量，按照上面的一天10亿数据，如果是两个副本，那就是20亿数据。数据默认保留一周的话，那就是140亿。一条消息是1KB。那么就是140 0000 0000 KB / 1024 / 1024 / 1024 = 13TB。如果是三台broker的话，那么一台就需要5TB。
当然我们需要考虑新增消息、消息留存时间、平均消息大小、是否压缩、副本等
带宽
对于Kafka来说，其实带宽比较容易成为瓶颈。需要结合业务峰值，比如针对一般的千兆网卡来说，1S大概在100多MB，那么如果一小时处理1TB的数据，就需要几十台服务处理。
