kafka集群规划

kafka的集群规划主要需要考虑以下几个方面：

• 操作系统：最好选择Lunix系统，因Linux提供的epoll模型使用的是I/O多路复用+信号驱动I/O的结合；且Linux可以实现零拷贝技术，而Windows需要JDK1.8之后才支持零拷贝技术。
• 磁盘规划：普通的JBOD（Just Bunch Of Disks）和SSD的选择，Kafka是对磁盘的顺序访问，所有减少了磁盘寻道道开销，很大程度上抵消了SSD带来的优势，而且JBOD磁盘的容量大、价格低又是另一优势。Kafka从框架层面就支持了副本机制，所以不再需要磁盘阵列来实现冗余，如果再以磁盘阵列的话，对于空间来讲也是一种浪费。
• 磁盘容量：
  在磁盘规划的过程中，需要结合以下几点进行考量：
  1、新增消息数
  2、消息留存时间
  3、平均消息大小
  4、副本数
  5、是否启用压缩
  如：client每天产生1亿条消息，每条消息保存两份并保留一周时间，平均每条消息的大小是1KB，那么我们需要为Kafka规划多大的磁盘空间呢？
  每天产生的消息会占用：1亿 * 2 * 1KB / 1000 / 1000 = 200GB
  最好预留10%的磁盘空间给其他数据文件（索引文件等）的存储，10GB。
  那么整体磁盘规划就应该210 * 7 = 1.5T。这是在消息无压缩的情况下，如果消息启用压缩，假设压缩比为0.5，那么整体磁盘的容量就是0.75TB。
• 内存规划：Kafka大量使用了操作系统的页缓存，反而堆内存中并没有使用太多，一般堆内存最好不要超过6GB，而页缓存应该提供在10GB以上的内存空间，总之对于内存规划的建议如下：
  尽量分配更多的内存给操作系统的page cache。
  不要为broker设置过大的堆内存，最好不要超过6GB。
  page cache大小至少大于一个日志段堆大小。
• CPU规划：
  使用多核系统，CPU核数最好大于8
  如果使用Kafka 0.10.0.0之前的版本或client端与broker端消息版本不一致（若无闲事配置，这种情况多半由client和broker版本不一致造成），且考虑多配置一些资源已防止消息解压缩操作消耗过多CPU。
• 带宽规划：
  尽量使用高速网络。
  根据自身网络条件和带宽来评估Kafka集群机器数量。
  避免使用跨机房网络。
  如：假设用户网络环境中的带宽是1GB/s，用户的业务目标是每天用1小时来处理1TB的业务消息，那么在这种情况下Kafka到底需要多少台机器呢？
  预估计算：网络带宽是1GB/s，假设分配的机器为Kafka专属使用且为Kafka分配70%的带宽资源（考虑到机器上还有其他的进程使用网络且网卡通常不能用满，超过一定阈值可能出现网络丢包情况，因此70%的设定是合理的），那么kafka每台broker的带宽就是1GB/s * 0.7 = 710MB/s。
  但事实上这是Kafka所使用的最高带宽，用户不能奢望Kafka集群平时就一直使用如此多的带宽，毕竟万一碰上突发流量，会极容易把网卡“打满”，因此在70%的基础上，一般再截取1/3，即710 / 3 = 240MB/s。
  如果要在1小时内处理1TB的业务消息，也就是每秒2336MB数据，那么至少需要2336/240 = 10台机器。若副本数量是2，那么这个数字还需要再翻1倍。即20台。