每天处理千亿级日志量，Kafka是如何做到的?

之前为大家分享了不少 Kafka 原理解析类的干货，今天咱们一起来看看 360 基于 Kafka 千亿级数据量的深度实践!

图片来自 Pexels

本文主要围绕如下内容分享：

消息队列选型

Kafka 在 360 商业化的现状

Kafka Client 框架

数据高可用

负载均衡

鉴权、授权与 ACL 方案

Quota 机制

跨 IDC 的数据同步

监控告警

线上问题及解决方案

消息队列选型

当时主要考虑以下几个维度：

社区活跃度

客户端支持

吞吐量

对比几个系统下来，觉得 Kafka 比较符合我们的要求。现在有一个新的开源系统 Pulsar，我觉得也可以尝试一下。

Kafka 设计上的亮点如下：

Kafka 性能和吞吐都很高，通过 Sendfile 和 Pagecache 来实现 Zero Copy 机制，顺序读写的特性使得用普通磁盘就可以做到很大的吞吐，相对来说性价比比较高。

Kafka 通过 Replica 和 ISR 机制来保证数据的高可用。

Kafka 集群有两个管理角色：

Controller 主要是做集群的管理。

Coordinator 主要做业务级别的管理。

这两种角色都由 Kafka 里面的某个 Broker 来担任，这样 Failover 就很简单，只需要选一个 Broker 来替代即可。

从这个角度来说 Kafka 有一个去中心化的设计思想在里面， 但 Controller 本身也是一个瓶颈，可以类比于 Hadoop 的 Namenode。

CAP 理论相信大家都有了解过，分布式系统实现要么是 CP，要么是 AP。

Kafka 实现比较灵活，不同业务可以根据自身业务特点来对 Topic 级别做偏 CP 或偏 AP 的配置。

支持业务间独立重复消费，并且可以做回放。

这个是 Kafka 的简要架构，主要分为：

生产端

Broker 端

消费端

日志有三个层次：

第一个层次 Topic

第二个层次 Partition(每个 Partition 是一个并行度)

第三个层次 Replica(Replica 表示 Partition 的副本数)

Kafka 在 360 商业化的现状

目前集群有千亿级数据量，100 多台万兆机器，单 Topic 的最大峰值 60 万 QPS，集群的峰值大概在 500 万 QPS。

我们的物理机配置 24Core/10G 网卡/128G 内存/4T*12 HDD，值得说一下的是我们采用了万兆网卡加普通磁盘 4T*12 的配置，测下来磁盘吞吐和网络吞吐是能够匹配上的。

再者考虑到我们的数据量比较大，SSD 盘没有特别大的且成本比较高。

磁盘的组织结构我们用的是 JBOD，RAID10 也是很好的方案(磁盘成本会翻倍)。

我们目前的 Kafka 版本是 1.1.1，推荐大家部署 0.11 以上的版本会好一些，这个版本对协议做了很多优化，对于后续的 2.x 版本都是兼容的。

这个是我们 Kafka 上下游相关的组件，生产端主要是各种 Kafka Clients/实时服务/Flume/Logstash。

消费端分为实时，离线(ETL)，监控三部分。实时有 Spark/Flink/Storm 等主流框架, 离线部分我们基于 Flink 自研了一个统一落地框架 Hamal，从 Kafka 消费一遍数据就可以落地到多个下游系统(HDFS、Hbase、Redis等)，可以避免重复消费。

还有部分是监控的需求，我们把 ES/InfluxDB 相关的日志打到 Kafka，然后再消费出来通过 Grafana 展示，但目前我们已经切到 Prometheus 上了。

Kafka Client 框架

为什么要做这个框架呢?之前有很多的业务部门用裸 API 自己去实现 Kafka Client 的逻辑。

但是会有很多问题，有一些异常情况会 Catch 不全，我们做这个框架是想把所有的细节屏蔽掉，然后暴露出足够简单的接口。

这样可以减少业务犯错的可能性，我们要确保极端的情况下比如网络或集群异常时的可用性，如果网络或集群不可用，数据会先落到本地，等恢复的时候再从本地磁盘恢复到 Kafka 中。

（编辑：ASP站长网）