kafka-大数据存储的基础理解_kafka 数据存储

目测通信:

1.狼来的故事

观察者模式

观察者模式（Observer），又叫发布-订阅模式（Publish/Subscribe）

定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到 通知并自动更新。

一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。

现实生活中的应用场景京东到货通知

生产者消费者模式

传统模式

生产者直接将消息传递给指定的消费者

耦合性特别高，当生产者或者消费者发生变化，都需要重写业务逻辑生产者消费者模式

https://v.qq.com/x/page/s326188g3q6.html

生产者消费者模式:

通过一个容器来解决生产者和消费者的强耦合问题。生产者和消费者彼此之间不直接通讯， 而通过阻塞队列来进行通讯

缓冲区

消息系统:

无非就是推和拉,传统的就是推送数据,如果对方处理不过来就会造成堵塞(受制于性能和效率)

拉数据就是看自己能处理数据量,按照自己的能力依次取数据

Kafka简介

Kafka 是一个分布式的基于发布/订阅模式的消息队列（Message Queue），主要应用于大数据实时处理领域。
1

官网：http://kafka.apache.org/

Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。

设计目标

以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能。

高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输。每秒就是10w

支持Kafka
Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输。同时支持离线数据处理和实时数据处理。

支持在线水平扩展

Kafka的优点

解耦：

在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息系统在处理过程中间插入了一个
隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处 理过程，只要确保它们遵守同样的接口约束。

冗余

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

扩展性

因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过
程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。

灵活性&峰值处理能力

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

可恢复性

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

顺序保证

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

缓冲

在任何重要的系统中，都会有需要不同的处理时间的元素。例如，加载一张图片比应用过滤器花费更少
的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行———写入队列的处理会尽可能的快速。 该缓冲有助于控制和优化数据流经过系统的速度。

异步通信

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

Kafka系统架构

1） **Producer ：**消息生产者，就是向 kafka broker 发消息的客户端；

2） **Consumer ：**消息消费者，向 kafka broker 取消息的客户端；

3） **Consumer Group （CG）：**消费者组，由多个 consumer 组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

4） **Broker ：**一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker

可以容纳多个topic。

5） **Topic ：**可以理解为一个队列，生产者和消费者面向的都是一个 topic；可以理解为数据库表名

6） Partition：为了实现扩展性，一个非常大的 topic 可以分布到多个broker（即服务器）上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列；不同的Partition不能保证数据的一致

为了性能考虑，如果topic内的消息只存于一个broker，那这个broker会成为瓶颈，无法做到水平扩展。所以把topic内的数据分布到整个集群就是一个自然而然的设计方式。Partition的引入就是解决水平扩展问题的一个方案

7**）** Replica**：**副本，为保证集群中的某个节点发生故障时，该节点上的 partition 数据不丢失，

且kafka 仍然能够继续工作，kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本，一个 leader和若干个 follower。

8） leader**：**每个分区单(多)个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对

象都是 leader。

9） follower**：**每个分区单(多)个副本中的“从”，实时从 leader 中同步数据，保持和 leader 数据的同步。leader 发生故障时，某个 follower 会成为新的 follower。

10)offset

1.如果在消费kafka的数据过程中，一直没有提交offset，那么在此程序运行的过程中它不会重复消费。但是如果重启之后，就会重复消费之前没有提交offset的数据。

2.比如消息有20条，当消费了10条后服务down机了，重新启动后就会从第11条开始消费，那么kafka是如何知道要从第11条开始消费的呢？这就是kafka中维护了一个offset值，那么这篇文章就讲一下如何根据offset值来找到对应的Message消息。

iotdb:

Apache IoTDB 始于清华大学软件学院。IoTDB
是一个用于管理大量时间序列数据的数据库，采用列式存储、数据编码、预计算和索引技术。它具有类似 SQL
的接口，可以在每个节点每秒写入数百万个数据点，并且经过优化，可以在几秒钟内获得超过数万亿个数据点的查询结果。它还可以轻松地与 Apache
Hadoop MapReduce 和 Apache Spark 集成以进行分析。

Zookeeper

简单讲，ZooKeeper用于分布式系统的协调，Kafka使用ZooKeeper也是基于相同的原因。ZooKeeper主要用来协调Kafka的各个broker(节点)，不仅可以实现broker的负载均衡，而且当增加了broker或者某个broker故障了，ZooKeeper将会通知生产者和消费者，这样可以保证整个系统正常运转。一句话,负责调节各个节点的关系