Kafka-1 初识消息引擎系统
消息引擎系统 Kafka
Kafka 这类系统在国外的名字叫 Messaging System，直译的话为消息系统。消息系统片面强调了消息主题的作用，而忽视了这类系统引以为傲的消息传递属性，就像引擎一样具备某种能量转换传输的能力，所以翻译为消息引擎反倒更加贴切。
消息引擎系统 Kafka 主流的称呼一般是"消息队列"、"消息中间件"，消息队列总给人一种不明确的暗示，仿佛 Kafka 是利用队列的方式进行构建的；而消息中间件的说法又让人不太清楚这个中间件是做什么的。
官方对于此类系统的定义是：消息引擎系统是一组规范，企业利用这组规范在不同系统之间传递语意准确的消息，实现松耦合的异步式数据传递。
最基础的消息系统其实就是：A发送消息给系统，B从系统中读取A发送的消息。
- 消息引擎系统传输的对象是消息；
- 如何传输消息属于消息引擎设计机制的一部分；
如果你了解 RPC，相必对消息传输也有自己的理解。RPC 的发展也对消息的传输协议进行了推动，从前期的普通二级制、到易于理解的 xml、json，再发展成强调性能的 Protocol Buffer、Thrift、Hession2，这些都是很酷的办法。Kafka 选择的是纯二进制的字节序列，当然消息还是结构化的，只是在使用之前都要将其转换成二进制的字节序列。
Kafka 与 JMS
常见的消息传输模型有两种：
- 点对点模型：也叫消息队列模型，即 A 发送的消息只能被 B 接收，其他系统都不能读取 A 发送的消息。例如我们平时找客服的呼入电话只会被一位客服人员处理。
- 发布 / 订阅模型：该模型有一个主题（Topic） 的概念，发送方被称为发布者（Publisher），接收方称为订阅者（Subscriber）。和点对点模型不同的是，这个模型中可以有多个发布者向某主题发送消息，而订阅者也可能存在多个，它们都能接收到相同主题的消息。
Kafka 同时支持这两种模型。JMS 是 Java Message Service，它也是支持上面这两种消息引擎模型的。严格来说它并非传输协议而仅仅是一组 API 罢了。不过可能是 JMS 太有名气以至于很多主流消息引擎系统都支持 JMS 规范，比如 ActiveMQ、RabbitMQ、IBM 的 WebSphere MQ 和 Apache Kafka。
消息引擎系统可以做什么
异步处理
工作中遇到的异步场景还是很多的，举个例子，新用户注册成功后需要给他的邮箱发送一封欢迎邮件或新手礼包，发送邮件的操作其实不需要放在注册接口中同步处理，因为这会影响注册接口的性能。定时任务虽然也可以解决这个问题，但是如何控制定时任务的执行频率也是一个值得讨论的事情。我们可以在注册成功后发送一个消息到消息引擎系统，邮件系统收到这个消息后处理发送欢迎邮件的逻辑。
在秒杀场景中，能否抢到商品一般只取决于所有流程中的几个关键步骤，例如是否锁定了库存，生成了订单。至于在有效期内是否支付成功，发送邮件通知用户锁定成功等都可以利用消息引擎系统来异步实现。
流量控制
"削峰填谷"这四个字比消息引擎系统更要广为人知。
所谓的"削峰填谷"就是指缓冲上下游瞬时突发流量，使其更平滑。特别是对于那种发送能力很强的上游系统，如果没有消息引擎的保护，"脆弱"的下游系统可能会直接被压垮导致全链路服务"雪崩"。但是，一旦有了消息引擎，它能够有效地对抗上游的流量冲击，真正做到将上游的"峰"填满到"谷"中，避免了流量的震荡。
服务解耦
消息引擎系统的另一大好处在于发送方和接收方的松耦合，这也在一定程度上简化了应用的开发，减少了系统间不必要的交互。
在上游服务完成了自己的工作后，完全不需要手动去调用下游服务，而只是向 Kafka 中对应主题发送一条消息，各个下游服务订阅 Kafka 中对应主题的消息并进行处理，在需求变动例如不再需要某下游服务时我们只需要取消订阅即可，完全不需要改动上游服务的代码。
Kafka 中的那些术语
基本概念
在 Kafka 中，发布订阅的对象是主题（Topic），可以为每个业务、每个应用甚至是每类数据都创建专属的主题。消息被称为 Record。
Kafka 的服务器端由被称为 Broker 的服务进程构成，即一个 Kafka 集群由多个 Broker 组成，Broker 负责接收和处理客户端发送过来的请求，以及对消息进行持久化。
向主题发布消息的客户端应用程序称为生产者（Producer），生产者程序通常持续不断地向一个或多个主题发送消息，而订阅这些主题消息的客户端应用程序就被称为消费者（Consumer）。和生产者类似，消费者也能够同时订阅多个主题的消息。生产者和消费者统称为客户端（Clients）。
一般为了提升消费端的吞吐量，会有多个消费者共同组成一个消费者组（Consumer Group）来进行消费，主题中的每个分区只会被组内的一个消费者实例消费，这里的消费者实例可以是运行消费者应用的进程，也可以是一个线程，它们都称为一个消费者实例（Consumer Instance）。
Kafka 如何实现高可用
一方面我们在搭建集群时会将不同的服务端进程部署在不同的服务器上，这样即使某个机器宕机，其他机器上的服务也依然可以对外提供服务。
另一方面就是备份机制（Replication），备份的思想很简单，就是把相同的数据拷贝到多台机器上，而这些相同的数据拷贝在 Kafka 中被称为副本（Replica），K8S中也有这个概念。
Kafka 定义了两类副本：领导者副本（Leader Replica）和追随者副本（Follower Replica）。前者对外提供服务，这里的对外指的是与客户端程序进行交互；而后者只是被动地追随领导者副本而已，不能与外界进行交互。生产者总是向领导者副本写消息；而消费者总是从领导者副本读消息。至于追随者副本，它只做一件事：向领导者副本发送请求，请求领导者把最新生产的消息发给它，这样它能保持与领导者的同步。
为了避免单个 Topic 下的数据过大，Topic 进行了分区（Partitioning）。每个分区是一组有序的消息日志。生产者生产的每条消息只会被发送到一个分区中，也就是说如果向一个双分区的主题发送一条消息，这条消息要么在分区 0 中，要么在分区 1 中（分区序号从 0 递增）。
副本就是针对分区而言的：每个分区下可以配置若干个副本，其中只能有 1 个领导者副本和 N-1 个追随者副本。生产者向分区写入消息，每条消息在分区中的位置信息由一个叫位移（Offset）的数据来表征。分区位移总是从 0 开始，假设一个生产者向一个空分区写入了 10 条消息，那么这 10 条消息的位移依次是 0、1、2、...、9。
重平衡
假设消费者组内某个实例挂掉了，Kafka 能够自动检测到，然后把这个 Failed 实例之前负责的分区转移给其他活着的消费者。这个过程就是 Kafka 中大名鼎鼎的"重平衡"（Rebalance）。
每个消费者在消费消息的过程中必然需要有个字段记录它当前消费到了分区的哪个位置上，这个字段就是消费者位移（Consumer Offset）。消息分区内的每个消息也会有一个位移，标识该消息在分区的哪个位置，这个被称为消息位移（Offset）。
持久化
Kafka 使用消息日志（Log）来保存数据，一个日志就是磁盘上一个只能追加写（Append-only）消息的物理文件。因为只能追加写入，故避免了缓慢的随机 I/O 操作，改为性能较好的顺序 I/O 写操作，这也是实现 Kafka 高吞吐量特性的一个重要手段。不过如果你不停地向一个日志写入消息，最终也会耗尽所有的磁盘空间，因此 Kafka 必然要定期地删除消息以回收磁盘。怎么删除呢？简单来说就是通过日志段（Log Segment）机制。在 Kafka 底层，一个日志又近一步细分成多个日志段，消息被追加写到当前最新的日志段中，当写满了一个日志段后，Kafka 会自动切分出一个新的日志段，并将老的日志段封存起来。Kafka 在后台还有定时任务会定期地检查老的日志段是否能够被删除，从而实现回收磁盘空间的目的。
基于以上内容，可以分析出 Kafka 的三层架构：
- 第一层是 Topic 主题，每个主题可以配置 M 个分区，每个分区又可以配置 N 个副本。
- 第二层是分区层，每个分区的 N 个副本中只有一个能充当领导者，对外提供服务，其余 N-1 个副本只做数据冗余使用。
- 第三层是消息层，每个分区包含若干个消息，每条消息的位移从 0 开始，依次递增。
注意**客户端程序只跟分区领导者副本交互！**