本文共 3188 字，大约阅读时间需要 10 分钟。

消息引擎的作用：削峰填谷，即平衡系统上下游的流量；

消息引擎传输的对象是消息；

如何传输消息属于消息引擎设计的一部分；

1.消息引擎的传输模型

• 点对点模型：即消息队列模型。就是说系统A发送的消息只能被系统B接收，其他任何系统都不能读取到A发送的消息；
• 发布/订阅模型：以主题Topic的形式来发布消息，该模型下发布者Publisher 和 订阅者Subscriber的关系为 N对M，即 该模型下可以有多个发布者，也可以有多个订阅者；

2.Kafka术语

1. 主题（Topic）：Kafka中发布订阅的对象，每个业务、每个应用甚至每类数据都可以创建专属的主题
2. 客户端:
   a. 生产者（Producer） ：向主题发布消息的客户端应用程序，可持续向多个主题发送消息；
   b. 消费者（Consumer） ：订阅这些主题的客户端，可同时订阅多个主题；
   生产者和消费者实例可以同时运行多个
3. 服务端：由被称为Broker的服务进程构成，一个kafka集群由多个broker组成；
4. Broker：负责接收和处理客户端发送过来的请求，以及对消息进行持久化；
5. kafka高可用机制：
   a. broker运行在不同的机器上，当一台出现故障时，其他broker依然可以对外提供服务；
   b. 备份机制（Replication），把相同的数据拷贝到多台机器上作为副本；
6. 副本（Replica）：生产者总是向领导者副本写消息；而消费者总是从领导者副本读消息；对于追随者副本：向领导者副本发送请求，请求领导者把最新生产的消息发送给他，让他与领导者保持一致；
   a. 领导者副本（Leader Replica） ：对外提供服务，即与客户端程序进行交互；
   b. 追随者副本（Follower Replica） : 被动追随领导者副本，不与外界发生交互；
7. 分区（Partition）：将主题划分为多个块，每个块是一组有序的消息日志；每个块即为一个分区；生产者生产的每条消息只会被发送到一个分区；分区编号从0开始；每个分区有若干个副本；生产者向分区写入消息，每条消息在分区中的位置信息由一个叫做位移（Offset）的数据来表征，从0开始
8. 消费者组：Consumer Group。多个消费者实例共同组成一个组，同时消费多个分区以实现高吞吐；
9. 重平衡：消费者组内某个消费者实例挂掉后，其他消费者实例自动重新分配订阅主题分区的过程。Rebalance是kafka消费者端实现高可用的重要手段；
   简单展示上述概念的示意图：
   

3.kafka介绍

kafka在设计之初就旨在提供三个方面的特性：

• 提供一套API实现生产者和消费者；
• 降低网络传输和磁盘存储开销；
• 实现高伸缩性架构；

kafka是一个消息引擎系统，也是一个分布式流处理平台；

• 更容易实现端到端的正确性（Correctness）：流处理要最终替代它的“兄弟”批处理需要具备两点核心优势：要实现正确性和提供能够推导时间的工具。实现正确性是流处理能够匹敌批处理的基石。 正确性一直是批处理的强项，而实现正确性的基石则是要求框架能提供精确一次处理语义，即处理一条消息有且只有一次机会能够影响系统状态。目前主流的大数据流处理框架都宣称实现了精确一次处理语义，但这是有限定条件的，即它们只能实现框架内的精确一次处理语义，无法实现端到端的。
• 对于流式计算的定位：官网上明确标识 Kafka Streams 是一个用于搭建实时流处理的客户端库而非是一个完整的功能系统。这就是说，你不能期望着 Kafka 提供类似于集群调度、弹性部署等开箱即用的运维特性，你需要自己选择适合的工具或系统来帮助 Kafka 流处理应用实现这些功能。 对于中小型企业，轻量级的平台体系更节省成本；

4.kafka线上部署考量

操作系统

Kafka是由Scala和Java编写而成，编译后源代码就是普通的.class文件；目前常见操作系统有3种：Linux、Windows和macOS; 考虑到操作系统与Kafka的适配性，Linux系统比其他两种更适合部署Kafka，主要原因有：

• I/O模型的使用
  主流的 I/O 模型通常有 5 种类型：阻塞式 I/O、非阻塞式 I/O、I/O 多路复用、信号驱动 I/O 和异步 I/O。每种 I/O 模型都有各自典型的使用场景，比如 Java 中 Socket 对象的阻塞模式和非阻塞模式就对应于前两种模型；而 Linux 中的系统调用 select 函数就属于 I/O 多路复用模型；大名鼎鼎的 epoll 系统调用则介于第三种和第四种模型之间；至于第五种模型，其实很少有 Linux 系统支持，反而是 Windows 系统提供了一个叫 IOCP 线程模型属于这一种。
  实际上 Kafka 客户端底层使用了 Java 的 selector，selector 在 Linux 上的实现机制是 epoll，而在 Windows 平台上的实现机制是 select。
  因此在这一点上将 Kafka 部署在 Linux 上是有优势的，因为能够获得更高效的 I/O 性能。
• 数据网络传输效率
  Kafka 生产和消费的消息都是通过网络传输的，而消息保存在磁盘。故 Kafka 需要在磁盘和网络间进行大量数据传输。 Linux的零拷贝（Zero Copy）技术使得数据在磁盘和网络进行传输时避免昂贵的内核态数据拷贝从而实现快速地数据传输。而在 Windows 平台上必须要等到 Java 8 的 60 更新版本才能“享受”到这个福利。一句话总结一下，在 Linux 部署 Kafka 能够享受到零拷贝技术所带来的快速数据传输特性。
• 社区支持度
  社区目前对 Windows 平台上发现的 Kafka Bug 不做任何承诺。虽然口头上依然保证尽力去解决，但根据我的经验，Windows 上的 Bug 一般是不会修复的。
  因此，Windows 平台上部署 Kafka 只适合于个人测试或用于功能验证，千万不要应用于生产环境。

磁盘

kafka使用磁盘的方式为顺序读写操作，一定程度上规避了机械磁盘随机读写操作慢的劣势；因此采用SSD的性价比并不高；

• 如果追求性价比，可以不搭建RAID，使用普通磁盘组成存储空间即可；
• 使用机械磁盘完全能够胜任kafka线上环境；

磁盘容量

磁盘容量规划，需要考量的因素有：

• 新增消息数
• 消息存留时间
• 平均消息大小
• 备份数
• 是否启用压缩，以及压缩算法比率

带宽

• 网络带宽很容易成为kafka这种数据传输框架的瓶颈；
• 宽带主要有两种：1Gbps的千兆网络和10Gbps的万兆网络，通常都是用的千兆网络：
• 宽带资源规划，实质是kafka服务器数量规划的问题；
• 带宽1Gbps是指美妙处理1Gb的数据；通常情况在千兆环境下仅能假设kafka使用到70%的带宽资源，因为其他应用或进程也需要占用一部分；根据实际使用经验，超过70%的阈值就有网络丢包的可能；也就是单台kafka服务器最多也就是最多能使用大约700Mb的带宽资源。但通常还要再额外预留出2/3的资源，即单台服务器使用带宽越240Mbps，需要提示的是，这里的 2/3 其实是相当保守的，你可以结合你自己机器的使用情况酌情减少此值。
  因此，如果一小时处理1TB数据的话，一秒需要处理2336Mb数据，除以 240，约等于 10 台服务器。如果消息还需要额外复制两份，那么总的服务器台数还要乘以 3，即 30 台。

总结：