发展史&线上部署因素
在这里插入图片描述
诞生背景
领英公司小故事
领英公司作为一家大型互联网企业,
复杂的系统,繁杂的业务场景
必然要求有一个大一统的数据管道。
在此之前。。。。
-
为了收集业务系统和应用的性能指标
-
起初:自制系统追踪监控,相比开源方案,高度匹配业务。但是,基于轮询(polling) 需要指定时间间隔。。。系统要高度定制,实现匹配各个业务系统,人工维护成本太高
-
收集用户操作行为
-
后来自研离线批处理的系统(基于xml),用于收集用户行为,但是无法实时处理。 Google大神(谁谁谁自己去查)讲,流处理只要实现两个点,就可以完全替代离线批处理。一个是正确性。一个是提供时间推导工具。
基于上述自研的一套多套东西需要统一的背景前提,kafka就被设计出来啦
设计目的:
作为基础设施,数据总线承上启下
- 为生产端和消费端提供简单api
- 降低网络传输和磁盘开销
- 高伸缩
开源历史&版本变迁
2010年kafka正式开源
2011.7-2012.10 kafka在Apache孵化成功
新旧producer
详细内容可查看producer介绍
相比之下
- 发送线程一拆为二,用户主线程和Sender I/O 职责分离。
- 异步发送,callback反馈
- batching
- 避免数据倾斜,默认分区轮询分发合理
- 基于java selector网络,结合Future特性实现优雅健壮的生命周期管理
旧版本
- 同步发送,吞吐性能差/异步选项可能丢消息
- API简陋。不推荐使用
新旧consumer
详细内容可查看consumer介绍
新版本consumer
- 消费位移offset不再依赖zk,数据量大且频繁时的zk读写瓶颈解除
- 单线程epoll理念,替代多线程管理。(心跳线程+消费线程替代杂乱的多线程)
- 剔除zk依赖,消费者组管理由选举的coordinator进行。
旧版本consumer
scala实现的
性能其实没那么不堪
- 高阶消费者 high-level (类似新版的消费者组)
- low-level consumer ,单消费者独立工作。灵活在于便于第三方集成,不灵活在于不提供组管理(负载均衡故障转移)
版本选择
- Kafka Stream 要求 0.10.0.0之后的版本
- Kafka Security要求 0.9.0.0之后的
- 只作为MQ,主备要求 0.8.x之后的
- 根据consumer确定版本,比如spark或者storm的kafka是第三方研发的,要求对应版本的kafka
线上部署因素
考虑因素 | 选型 | 优劣 | 选择 |
---|---|---|---|
操作系统 | Linux | 底层IO模型:epoll 网络传输:零拷贝 | ☑️ ☑️ ☑️ |
磁盘规划 | ssd | $贵 但是肯定好啊 | |
hdd:raid | 磁盘阵列 负载均衡 镜像天然冗余50% | ☑️ | |
hdd: jbod | jbod廉价但任意 坏 broker宕机 无负载均衡,简单轮询 | 性价比☑️ |
考虑因素 简略列举方向
- 容量规划
- 消息增量
- 留存时间
- 平均消息大小
- 副本数
- 是否开启压缩
- 内存规划
- 页缓存尽量多分配
- 不需要设置过大的堆内存给broker, 朝生夕灭
- 页缓存至少要超过一个日志段(见broker日志介绍)
- cpu规划
- 非计算密集型,只需要追求多核而不是高频
- 如果启用消息压缩需要考虑cpu消耗
- 宽带规划:
- 尽量使用高速网络,考虑到网络丢包和突发流量。70% 再/3。
- 举例子
- 千兆 1gb.s*0.7/3 ->240Mb/s(每一台)
- 假设1t数据处理量/h =>即293MB 的秒级数据量,即293*8=2336M b. 大概需要10台broker。考虑replica的话则是 10 ✖️replica_num
- 参考数值
- 24核cpu
- 32g内存
- 1t磁盘 7200转sas 两块
- 千兆带宽
- ulimit -n 1000000
- Socket buffer 64k至少
By mori.wang 看看就好,运维可能更懂=-=
vipshop.fcs
2019 年夏