本文参考闫锁鹏老师在2019DAMS上海站关于Kafka在360的商业化实践分享。

关于作者:近10年基础架构与大数据开发经验,2013年加入360商业化 团队,负责消息队列系统,消息落地系统,实时计算平台等基础架构 开发与运维。同时涉及微服务架构,监控系统等基础设施,致力于为 商业化团队提供稳定高效的基础服务。

文章大纲

  • Why kafka

  • 360商业化kafka现状

  • kafka client框架

  • 数据高可用

  • 负载均衡
  • Authorization and ACLs Quota机制

  • 跨IDC数据同步

  • 监控告警
  • Tools
  • 线上问题与解决

Why Kafka

对比了以下几个消息队列,我们最终选择了 Kafka 做我们的消息中间件。

数据可靠性 延迟 单机吞吐 社区活跃度 客户端
ActiveMQ / 万级 不太活跃 支持全面
RabbitMQ 微秒 万级 活跃 支持全面
Kafka 毫秒 十万级 活跃 支持全面
RocktMQ 毫秒 十万级 有待加强 有待提升

Kafka 好在哪?

  • hight performance : sendfile + pagecage 实现零拷贝。数据写入按照 apendfile 的方式,这样普通的磁盘也可以实现很大的吞吐。
  • high avaliable : replica + isr
  • fault tolerance : controler 集群级别管理和 coordinator: 业务级别管理,这两个角色是由集群中某一个 Broker 担任,如果这个 Broker 出现故障,会选举出另一个 Broker 来担任这两个角色。有一种去中心化的思想在里面。
  • CAP trade-off(权衡):高一致性或高可用可配置。要么 CP 要么 AP, 支持 topic 级别的配置。
  • consumers groups : 可独立重复 消费、可回放。可以根据 offset 开始消费。

kafak 架构简单一览

image.png

360 kafka 集群现状

  • 千亿级日志量,PB级数据量
  • 集群规模: 100+ 万兆网卡机器
  • topic最大峰值60w
  • qps 集群峰值500w qps

物理机配置

  • cpu: 24
  • network: 10Gb/s
  • mem: 128GB
  • disk: HDD 4TB*12 JBOD/RAID10

kafka版本1.1.1 (0.11+ recommend )

image.png

数据生产端:kafka-clients / flume / logstash
数据消费端:Spark/ Flink / Strom / hamal / ES

其中 hamal 是团队单独开发的一个 ETL 框架,目的是只需要消费一次 kafka , 可以把数据从kafka落入到hive、hdfs等不同的应用场景中。开源的框架:kafka connector 等也可以实现,但是不能满足我们需求。

kafka client 框架

首先我们为什么要做这个东西?

设计原则:极端情况下可用, 网络或集群异常 框架处理所有细节,业务接口简单,减少业务犯错可能
比如:网络异常的时候,先把数据存放在本地磁盘,等网络恢复的时候再发送。

LogProducer Framework at least once语义
LogConsumer Framework at least once语义

exactly once语义: 业务需实现rollback逻辑

image.png

image.png

把消费线程和处理线程分开,分开配置。同时 blocking queue 起到了反压的效果。

数据高可用

replica + isr 是远远不够的,replica rack aware (机架感知)

image.png

这样我们可以容忍两个机架的宕机。

负载均衡

image.png

image.png

基于虚拟节点的一致性hash

  • 添加移除节点仅需迁移很小部分数据
  • 通过权重设置支持不同性能机器加入集群(虚拟节点数量作为权重)
  • replica rack aware

基于disk rebalance与leader负载 kafka支持版本1.1.0+

Authorization and ACLs

鉴权、授权和ACLs的方案:
1、白名单机制(360在用)
工单流程管理合法topics, consumers, 定期监测非法topics, consumer group 并做deny处理

2、基于用户鉴权,授权机制(官网提供的)

  • 基于SSL/SASL 鉴权

  • 需要客户端设置支持

  • 会有一定的性能损耗

Quota(配额) 机制

两种配额策略:

  • 限制带宽
  • 限制请求速率

三个业务优先级:高、中、低
可批量对某优先级的业务升降机操作。

跨IDC数据同步

  • 基于mirrormaker
  • IDC间数据只同步一份
  • 所有业务只做本IDC读写
  • 基于mesos + marathon paas化,提高服务SLA

监控告警

  • jmx exporter + prometheus + grafana
  • kafka manager
  • burrow
  • wonder

Tools

  • deploy tool: ansible-playbook

  • migration tool

  • rebalance tool
  • offset reset tool

线上问题解决

磁盘故障检测:
smartctl -a /dev/sda(PASSED && 197 Current_Pending_Sector)
bootstrap.server性能瓶颈 : vip bind
consumer重启不消费:
https://issues.apache.org/jira/browse/KAFKA-5413
升级到0.11+版本 使用kafka-offset-reset工具做group迁移