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

Leader Balance：这是一种快速且成本低的负载 Balance 方法，因为 Kafka 只有 Leader 提供读写，所以通过 Leader 切换是可以达到负载切换的效果的，由于只是 Leader 切换不涉及数据同步，因此这个代价是比较小的。

Disk Rebalance：这个 Feature 需要 Kafka1.1.0 版本之后才支持，Kafka 提供了一些脚本和 API 可以做 Balance 操作, 其本质也是生成 Replica Plan 然后做 Reassign。

鉴权、授权和 ACL 方案

如果是新集群比较推荐基于 SASL 的 SCRAM 方案，实施起来比较简单。

如果老集群想中途施行鉴权授权机制会比较困难，需要推各个业务去修改配置，同时切换的过程也很容易出问题。

下面介绍下我们实现的一个白名单机制来解决老集群的问题，首先将老业务加入到白名单中，让新业务通过工单流程来申请 Topics 和 Consumers 两种资源权限并加到白名单里，定期监测非法(没有走工单)Topics，Consumers 资源。

同时将这些资源都 Deny 掉，这样就收紧了 Topics 和 Consumer 读写权限的口子，同时原有业务不会有任何影响。

Quota 机制

Quota 主要是为了解决多个业务间资源抢占问题。Quota 类型有两种：

一种是限制网络带宽。

一种是限制请求速率(限制 CPU)。

我们对业务做了三个优先级设置：高，中，低优先级，高优先级不做限制，中优先级可容忍 lag，低优先级极端情况可停掉，通过工具可以批量限制某个优先级的所有业务，可以确保高优先级业务及集群的安全。

跨 IDC 的数据同步

首先我们为什么要做跨 IDC 的数据同步?没做这个同步之前业务可能对数据的读写没有一个 IDC 的概念，所以很容易就会有跨 IDC 的读写，多个业务还可能有重复 Consume 和 Produce。

这就造成跨 IDC 网络的极大浪费， 加上跨 IDC 的网络并不稳定，有时候会有一些异常，业务也不一定能很好处理。

为了解决以上问题，我们统一做了跨 IDC 的数据同步服务，首先我们约定业务只能做本 IDC 的读写，不允许做跨 IDC 的读写，如果有跨 IDC 的数据需求，要向我们申请，通过 Mirrormaker 去同步一份过来。

这样做有两个好处：

一是屏蔽了异常对业务的影响。

二是节省了 IDC 之间的带宽(我们通过同步机制能保证这份数据只传输一份)。

我们还基于 Marathon/Mesos 对这个服务做了 Pass 化，提高了服务的 SLA。

监控告警

我们的监控警告平台如下：

基于 Jmx exporter+Promehteus+Grafana 来做图表展示，在每个 Broker 上面部署 Jmx exporter，Prometheus 会去 Pull 这些数据，最后通过 Grafana 来展示。

基于 Kafka Manager 做瞬态指标的监控。

基于 Burrow 做 Consumer lag 的监控。

基于 Wonder 来做告警，这个是 360 内部实现的一个组件，类似 Zabbix。

（编辑：源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!