地址 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, 尊重生态, 改进生态. 很多建议和经验放到小公司也可以得到借鉴.
来源: https://yq.aliyun.com/articles/702452