分享概要

1、消息队列选型

2、Kafka在360商业化的现状

3、Kafka client框架

4、数据高可用

5、负载均衡

6、鉴授权与ACL方案

7、Quota机制

8、跨IDC的数据同步

9、监控告警

10、线上问题及解决方案

一、消息队列选型

当时主要考虑以下几个维度：社区活跃度，客户端支持，吞吐量。对比几个系统下来，觉得Kafka比较符合我们的要求。现在有一个新的开源系统pulsar，我觉得也可以尝试一下。

1、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内存/4T12 HDD，值得说一下的是我们采用了万兆网卡加普通磁盘4T12的配置，测下来磁盘吞吐和网络吞吐是能够匹配上的， 再者考虑到我们的数据量比较大，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中。

我们实现了两个框架：LogProducer和LogConsumer。LogProducer支持at least once；LogConsumer支持at least once和exactly once两种语意，其中exactly once需要业务去实现rollback接口。
待续。。。。。。