前言:

1.由来

为什么使用消息队列？

从系统之间有通信需求开始，就自然产生了消息队列。

在计算机科学中，消息队列（英语：Message queue）是一种进程间通信或同一进程的不同线程间的通信方式，软件的贮列用来处理一系列的输入，通常是来自用户。消息队列提供了异步的通信协议，每一个贮列中的纪录包含详细说明的资料，包含发生的时间，输入设备的种类，以及特定的输入参数，也就是说：消息的发送者和接收者不需要同时与消息队列交互。消息会保存在队列中，直到接收者取回它。

2.特点

解耦：

允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
冗余：

消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
扩展性：

因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。
灵活性及峰值处理能力：

在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
可恢复性：

系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
顺序保证：

在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。（Kafka 保证一个 Partition 内的消息的有序性）
缓冲：

有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。
异步通信：

很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

3.使用场景

服务解耦：

下游系统可能只需要当前系统的一个子集，应对不断增加变化的下游系统，当前系统不停地修改调试与这些下游系统的接口，系统间耦合过于紧密。引入消息队列后，当前系统变化时发送一条消息到消息队列的一个主题中，所有下游系统都订阅主题，这样每个下游系统都可以获得一份实时完整的订单数据。
异步处理：

以秒杀为例：风险控制->库存锁定->生成订单->短信通知->更新统计数据

限流削峰/流量控制

一个设计健壮的程序有自我保护的能力，也就是说，它应该可以在海量的请求下，还能在自身能力范围内尽可能多地处理请求，拒绝处理不了的请求并且保证自身运行正常。使用消息队列隔离网关和后端服务，以达到流量控制和保护后端服务的目的。
消息驱动的系统

系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者(可能有多个)负责对消息进行处理；(分工处理(各自对应相应的队列)，灵活应用(收到就处理/定时处理))

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 地址的 Producer
0.9	增加了基础的安全认证 / 权限，Java 重写了新版本消费者 API
0.10.0.0	引入了 Kafka Streams
0.11.0.0	提供幂等性 Producer API 以及事务（Transaction） API，对 Kafka 消息格式做了重构。
1.0	Kafka Streams 的各种改进
2.0	Kafka Streams 的各种改进

3.Kafka术语

消息：Record。这里的消息就是指 Kafka 处理的主要对象。
服务：Broker。一个 Kafka 集群由多个 Broker 组成，Broker 负责接收和处理客户端发送过来的请求，以及对消息进行持久化。
主题：Topic。主题是承载消息的逻辑容器，在实际使用中多用来区分具体的业务。
分区：Partition。一个有序不变的消息序列。每个主题下可以有多个分区。
消息位移：Offset。表示分区中每条消息的位置信息，是一个单调递增且不变的值。
副本：Replica。Kafka 中同一条消息能够被拷贝到多个地方以提供数据冗余，这些地方就是所谓的副本。副本还分为领导者副本和追随者副本，各自有不同的角色划分。副本是在分区层级下的，即每个分区可配置多个副本实现高可用。
生产者：Producer。向主题发布新消息的应用程序。
消费者：Consumer。从主题订阅新消息的应用程序。
消费者位移：Consumer Offset。表征消费者消费进度，每个消费者都有自己的消费者位移。
消费者组：Consumer Group。多个消费者实例共同组成的一个组，同时消费多个分区以实现高吞吐。
重平衡：Rebalance。消费者组内某个消费者实例挂掉后，其他消费者实例自动重新分配订阅主题分区的过程。Rebalance 是 Kafka 消费者端实现高可用的重要手段。

4.下一节预告

Kafka为何如此高效，为何那么快

深入浅出kafka原理-1-初识只作乍见之欢

前言:

1.由来

2.特点

3.使用场景

4.两种模式

任何一门技术的出现，都是为了解决现有技术的不足

1.Kafka名词解释

2.Kafka历史由来

版本号

3.Kafka术语

4.下一节预告

推荐阅读

深入浅出kafka原理-1-初识只作乍见之欢相关推荐

最新文章

热门文章