目录
前言：
1 .由来
2 .特点
3 .使用场景
4 .两种模式
1.Kafka名词解释
2.Kafka的历史由来
版本号
3.Kafka术语
前言： 1.为什么要使用来源消息队列？
自从有了系统间的通信需求，消息队列就自然而然地产生了。
在计算机科学中，消息队列(英文： Message queue )是进程间通信或同一进程的不同线程之间的通信方式，软件存储列用于处理一系列输入，通常消息队列提供异步通信协议。 每个存储列中的记录都包含详细说明，如发生时间、输入设备类型和特定输入参数。 这意味着消息的发送方和接收方不需要与消息队列同时交互。 消息将一直存储在队列中，直到收件人恢复。
2 .特征去耦：
允许你独立扩展或修改两边的处理流程，确保它们遵守相同的接口约束。
冗馀：
消息队列通过将数据持久化直到数据完全处理，避免了数据丢失的风险。 在许多消息队列中使用的“插入-检索-删除”范式要求处理系统在从队列中删除消息之前明确表示消息已经处理，以便在使用数据之前安全地存储。
可扩展性：
因为消息队列隔离了您的处理过程，所以增加消息入队和处理频率很容易。 只需要另外增加处理流程就可以了。
灵活性和高峰处理能力：
即使访问量急剧增加，APP应用程序也必须继续正常工作，但这种突发流量并不常见。 以能够应对这样的峰值访问为基准，随时等待投入资源无疑是很大的浪费。 消息队列使关键组件能够承受突发访问压力，而不会因突发过载要求而完全崩溃。
可恢复性：
系统的某些组件发生故障不会影响整个系统。 由于消息队列会降低进程之间的耦合度，因此即使处理消息的进程挂起，加入队列的消息也会在系统恢复后处理。
顺序保证：
在许多使用场景中，数据处理的顺序很重要。 大多数消息队列原本都是排序的，以确保按特定顺序处理数据。 (Kafka保证一个Partition内消息的有序性)
缓冲：
控制和优化数据流通过系统的速度，有助于解决生产消息和消费消息处理速度不一致的情况。
异步通信：
在许多情况下，用户不需要立即处理消息。 消息队列提供异步处理机制，允许用户对消息进行排队，但并不立即处理。 只要想在队列中输入消息就可以，必要时处理。
3 .使用场景服务解除绑定：
下游系统可能只需要当前系统的子集来适应不断变化的下游系统。 当前系统不断修改和调整与这些下游系统的接口，系统之间的耦合太紧密。 引入消息队列后，当当前系统发生更改时，消息将发送到消息队列中的主题，所有下游系统都可以订阅主题，从而使每个下游系统实时获取完整的订单数据。
异步处理：
以秒杀为例，风险控制-库存锁定-生成订单-邮件通知-更新统计数据
限流峰值/流量控制
设计坚固的程序具有自我保护的能力。 也就是说，在巨大的要求下，应该能够在自己的能力范围内处理尽可能多的要求，拒绝不能处理的要求，保证自己正常工作。 它使用消息队列将网关和后端服务隔离开来，目的是流量控制和保护后端服务。
le="text-align:center;">
消息驱动的系统
系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者(可能有多个)负责对消息进行处理；(分工处理(各自对应相应的队列)，灵活应用(收到就处理/定时处理))
4.两种模式点对点：
系统 A 发送的消息只能被系统 B 接收，其他任何系统都不能读取 A 发送的消息。日常生活的例子比如电话客服就属于这种模型：同一个客户呼入电话只能被一位客服人员处理，第二个客服人员不能为该客户服务。
发布/订阅模型
这个模型可能存在多个发布者向相同的主题发送消息，而订阅者也可能存在多个，它们都能接收到相同主题的消息。生活中的报纸订阅就是一种典型的发布 / 订阅模型。
任何一门技术的出现，都是为了解决现有技术的不足 1.Kafka名词解释kafka是一个分布式流处理平台。
类似一个消息系统，读写流式的数据
编写可扩展的流处理应用程序，用于实时事件响应的场景
安全的将流式的数据存储在一个分布式，有副本备份，容错的集群
2.Kafka历史由来Kafka从何而来?我们为什么要开发Kafka? Kafka到底是什么? Kafka 最初是 LinkedIn 的一个内部基础设施系统。我们发现虽然有很多数据库和系统可以用来存储数据，但在我们的架构里，刚好缺一个可以帮助处理持续数据流的组件。在开发Kafka之前，我们实验了各种现成的解决方案，从消息系统到日志聚合系统，再到ETL工具，它们都无法满足我们的需求。 最后，我们决定从头开发一个系统。我们不想只是开发一个能够存储数据的系统，比如传统的关系型数据库、键值存储引擎、搜索引擎或缓存系统，我们希望能够把数据看成是持续变化和不断增长的流，并基于这样的想法构建出一个数据系统。事实上，是一个数据架构。 这个想法实现后比我们最初预想的适用性更广。Kafka 一开始被用在社交网络的实时应用和数据流当中，而现在已经成为下一代数据架构的基础。大型零售商正在基于持续数据流改造他们的基础业务流程，汽车公司正在从互联网汽车那里收集和处理实时数据流，银行也在重新思考基于 Kafka 改造他们的基础。
它可以用于两大类别的应用:
构造实时流数据管道，它可以在系统或应用之间可靠地获取数据。 (相当于message queue)
构建实时流式应用程序，对这些流数据进行转换或者影响。 (就是流处理，通过kafka stream topic和topic之间内部进行变化)
版本号 版本号备注0.7上古版本，提供了最基础的消息队列功能0.8引入了副本机制，成为了一个真正意义上完备的分布式高可靠消息队列解决方案0.8.2新版本 Producer API，即需要指定 Broker 地址的 Producer0.9增加了基础的安全认证 / 权限，Java 重写了新版本消费者 API0.10.0.0引入了 Kafka Streams0.11.0.0提供幂等性 Producer API 以及事务（Transaction） API，对 Kafka 消息格式做了重构。1.0Kafka Streams 的各种改进2.0Kafka Streams 的各种改进3.Kafka术语消息：Record。这里的消息就是指 Kafka 处理的主要对象。
服务：Broker。一个 Kafka 集群由多个 Broker 组成，Broker 负责接收和处理客户端发送过来的请求，以及对消息进行持久化。
主题：Topic。主题是承载消息的逻辑容器，在实际使用中多用来区分具体的业务。
分区：Partition。一个有序不变的消息序列。每个主题下可以有多个分区。
消息位移：Offset。表示分区中每条消息的位置信息，是一个单调递增且不变的值。
副本：Replica。Kafka 中同一条消息能够被拷贝到多个地方以提供数据冗余，这些地方就是所谓的副本。副本还分为领导者副本和cxdzt副本，各自有不同的角色划分。副本是在分区层级下的，即每个分区可配置多个副本实现高可用。
生产者：Producer。向主题发布新消息的应用程序。
消费者：Consumer。从主题订阅新消息的应用程序。
消费者位移：Consumer Offset。表征消费者消费进度，每个消费者都有自己的消费者位移。
消费者组：Consumer Group。多个消费者实例共同组成的一个组，同时消费多个分区以实现高吞吐。
重平衡：Rebalance。消费者组内某个消费者实例挂掉后，其他消费者实例自动重新分配订阅主题分区的过程。Rebalance 是 Kafka 消费者端实现高可用的重要手段。
4.下一节预告 Kafka为何如此高效，为何那么快推荐阅读 深入浅出kafka原理-1-初识只作乍见之欢深入浅出kafka原理-2-Kafka为何那么快（高效）深入浅出kafka原理-3-高效文件存储设计特点深入浅出kafka原理-4-kafka网络机制原理