地址 360大厦A座
花了一下午时间，总要有所收获，本人正在负责公司小kafka集群，所以对kafka相关课题比较关心，也有收获，Flink还未入坑，这里并没有Flink相关的收获。

美团

• 介绍了现状，Kafka集群在数据平台中的功能，通过介绍得知，其负责数据传输

  • 一类是日志数据，业务日志和用户行为，一类是DB数据，应该是二进制流。
  • 下游接入的是离线计算，实时计算，日志中心和OLAP。
  • 入流峰值，3千万/s

• 然后介绍了高吞吐方面的优化

  • 二次开发：Disk层面的Rebalance，解决了以下痛点：

    • broker分配依据是Partition数，不够精细，会产生数倾斜。
    • 新加入节点不会Rebalance
  • Flink实时入仓，这个没懂。
  • 硬件选型：与计算密集型混部，充分利用磁盘资源；JBOD最大化利用率；引入大CacheRaid卡，进一步增加缓存。
  • 新缓存架构探索：FlashCache.

• 最后介绍了超大集群：1000+broker，40kTopics

  • 由于controller的瓶颈问题，集群规模一般不超过200broker，比如京东。
  • 找到瓶颈，做了controller与broker分离，并集群化，提高其管理能力，解决大集群瓶颈问题。
  • 建立了region隔离机制。（看来大集群还是要分割）
  • 增加了SafeMode机制，中心节点不可用时集群仍能工作。
• 总结，目前阶段对我直接有用的（1）硬件选型和规划（2）普通集群瓶颈在哪，避免过大。

京东

• 现状：56个集群，broker1530，topic15699，分区460301

• 产品化：

  • 跨机房灾备：mirror maker同步数据，就近消费，跨机房容灾靠dns切换域名。
  • 读写分离：分别建立生产者集群和消费者集群，来解决消费者横向扩展问题和生产消费干扰的问题。（这个方案很新颖，是否合理呢？）
  • 安全认证改进：去keytab，去jaas，Keberos认证，增加域名认证。
  • 周边功能完善：集群管理、运维管理、权限管理、用户认证；监控，挤压监控、实时大屏；SDK封装、消息查询工具、样本提取过滤工具、运营报表

• 探索：

  • 性能测试，挖掘：crc32优化，服务端解压缩问题，v1和v2协议性能对比
  • 全链路域名化：对跨机房灾备，对用户访问透明有非常大的好处。
  • Kafka on K8S vs 与实时计算服务器混部
• 总结：觉得京东还是做了些有意义的工作，没有过度定制kafka，尊重生态，改进生态。很多建议和经验放到小公司也可以得到借鉴。