文章大纲

• Kafka为何选择
• 360商业化Kafka现状
• Kafka客户端框架
• 数据高可用性
• 负载均衡
• 授权与访问控制列表
• 配额机制
• 跨数据中心数据同步
• 监控报警
• 工具
• 线上问题及解决方案

为什么选择Kafka？

在比较了几个消息队列后，我们最终决定采用Kafka作为消息中间件。以下是选择Kafka的主要原因：

• 可靠性：Kafka具有高可靠性和低延迟，适合处理大规模数据。
• 社区活跃度：Kafka拥有活跃的社区支持和丰富的文档资源。
• 吞吐量：Kafka的吞吐量远高于其他消息队列，可以处理每秒数百万的消息。

Kafka的优势

• 高性能：通过零拷贝技术实现高效的数据传输，普通磁盘也能达到很高的吞吐量。
• 高可用性：通过副本和ISR机制确保数据的高可用性。
• 容错能力：通过Controller和Coordinator的角色管理，实现了去中心化的容错机制。
• CAP权衡：支持Topic级别的配置，可以选择高一致性或高可用性。
• 消费者组：支持独立重复消费和回溯消费，方便灵活地管理消息消费。

360商业化Kafka现状

• 数据量：每天处理数千亿条日志，存储PB级数据。
• 集群规模：集群包含超过100台万兆网卡服务器。
• 峰值性能：每秒处理500万条请求。
• 硬件配置：每台服务器配备24核CPU，10Gb/s网络带宽，128GB内存，4TB硬盘。
• Kafka版本：使用1.1.1版本（推荐使用0.11+版本）。

数据消费端

• 生产者：使用kafka-clients、Flume和Logstash等工具。
• 消费者：使用Spark、Flink、Storm、Hama和Elasticsearch等工具。

Kafka客户端框架

• 设计原则：在极端情况下仍能正常工作，网络或集群异常时由框架自动处理所有细节。
• 示例：当网络出现问题时，数据将暂时保存在本地磁盘，待网络恢复正常后再发送出去。
• 语义保证：LogProducer和LogConsumer框架均支持至少一次的语义保证。

数据高可用性

• 副本与ISR：虽然副本和ISR机制已经很强大，但还不够。
• 机架感知：通过机架感知技术，即使有两个机架出现故障，也能保证数据的高可用性。

负载均衡

• 一致性哈希：使用基于虚拟节点的一致性哈希算法，添加或移除节点时只需迁移少量数据。
• 磁盘再平衡：通过Leader负载均衡，支持Kafka版本1.1.0+。

授权与访问控制列表

• 白名单机制：使用白名单机制管理合法主题和消费者组，定期监测非法主题和消费者组。
• 用户鉴权与授权：基于SSL/SASL进行鉴权，需要客户端设置支持，但会带来一定的功能损耗。

配额机制

• 带宽限制：限制特定业务的带宽使用。
• 请求速率限制：限制特定业务的请求速率。
• 优先级管理：根据业务优先级（高、中、低）进行带宽和请求速率的管理。

跨数据中心数据同步

• 基于MirrorMaker：通过MirrorMaker进行数据中心间的同步。
• 只读写当前数据中心：确保数据只在当前数据中心内读写。
• PaaS化服务：通过Mesos+Marathon进行PaaS化服务，提高服务的SLA。

监控报警

• 监控工具：使用JMX Exporter、Prometheus和Grafana进行监控。
• 管理工具：使用Kafka Manager和Burrow进行管理。
• 报警工具：使用Wonder进行报警。

工具

• 部署工具：使用Ansible-playbook进行部署。
• 迁移工具：使用Rebalance Tool进行迁移。
• 重置工具：使用Offset Reset Tool进行重置。

线上问题及解决方案

• 磁盘故障检测：使用smartctl工具进行磁盘故障检测。
• 功能瓶颈：解决VIP绑定问题。
• 消费者重启不消费：升级到0.11+版本，并使用kafka-offset-reset工具进行组迁移。

希望以上内容对你有所帮助，欢迎关注、分享。