本文介绍了360公司在使用Kafka过程中遇到的问题，如跨IDC读写导致的带宽压力、客户端容错不足等，并分享了他们如何通过改造和优化，包括使用mirrormaker、二次封装客户端、一致性哈希分配副本等措施，提升Kafka的性能和数据可靠性。此外，还介绍了监控方案，如使用prometheus、grafana和自研组件wonder进行监控和告警。
业务问题跨IDC读写导致带宽压力大问题。多个业务还可能有重复consume和produce，造成跨IDC网络的极大浪费， 另外跨IDC网络并不稳定，经常遇到一些异常
业务直接使用官方裸客户端有困难，要进行二次封装异常情况会catch不全
使用好kafka对业务有较高要求
客户端容错不能完全cover住360场景要求。当网络或集群异常直至不可用性时，数据就会丢失
不支持exactly once语义，需要业务配合实现
......
数据高可用支持不足，如果分片的所有副本都分布在单个机架上，数据有丢失风险高
数据分片(partition)分布不均衡。如果集群节点数量远大于分区数，kafka默认分配算法会造成数据倾斜，某些节点分配多，一些分配很少硬件资源利用率低
集群内新老机器因配置差异负载不均衡。随着时间推移硬件快速发展，新加入的机器性能是老机器成几何倍数提高，如果平均分配，则负载不均衡，新机器吃不饱，老机器吃不了。
技术选型
360选型Kafka从下面几个维度考虑：社区活跃度、客户端支持、吞吐量、数据可靠性比较
从kafka架构设计亮点分析Kafka性能和吞吐都很高，通过sendfile和pagecache来实现zero copy机制，顺序读写的特性使得用普通磁盘就可以做到很大的吞吐，相对来说性价比比较高。
Kafka通过replica和isr机制来保证数据的高可用。
Kafka集群有两个管理角色：controller主要是做集群的管理；coordinator主要做业务级别的管理
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
