通信原理和认识kafka
一、异步通信原理
1.观察者模式
- 观察者模式，又叫发布订阅模式
- 定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并自动更新。
- 一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知
2.生产者消费者模式
-
传统模式：
-
生产者直接将消息传递给指定的消费者
-
耦合性特别高，当生产者或者消费者发生变化，都需要重写业务逻辑
-
生产者消费者模式：
-
通过一个容器来解决生产者和消费者的强耦合问题。生产者和消费者彼此之间不直接通讯，而通过阻塞队列来进行通讯
- 数据传递流程：
- 生产者消费者模式，即N个线程进行生产，同时N个线程进行消费，两种角色通过内存缓冲区进行通信
- 生产者负责向缓冲区里面添加数据单元
- 消费者负责从缓冲区里面取出数据单元，一般遵循先进先出的原则
3.缓冲区
-
解耦：
-
假设生产者和消费者分别是两个类。如果让生产者直接调用消费者的某个方法，那么生产者对于消费者就会产生依赖
-
支持并发：
-
生产者直接调用消费者的某个方法过程中函数调用时同步的
-
万一消费者处理数据很慢，生产者就会浪费
-
支持忙闲不均：
-
缓冲区还有另一个好处。制造数据的速度时快时慢，缓冲区的好处就体现出来了。
-
当数据制造快的时候，消费者来不及处理，未处理的数据可以暂时存在缓冲区中
-
等生产者的制造速度慢下来，消费者再慢慢处理掉
4.数据单元
-
关联到业务对象：
-
数据单元必须关联到某种业务对象
-
完整性：
-
就是在传输过程中，要保证该数据单元的完整
-
独立性：
-
就是各个数据单元之间没有互相依赖
-
某个数据单元传输失败不应该影响已经完成传输的单元，也不应该影响未传输的单元
-
颗粒度：
-
数据单元需要关联到某种业务对象。数据单元和业务对象应该处于的关系（一对一或者一对多）
-
如果颗粒度过小会增加数据传输的次数
-
如果颗粒度过大会增加单个数据传输的时间，影响后期消费
二、消息系统原理
一个消息系统负责将数据从一个应用传递到另外一个应用，应用只需关注于数据，无需关注数据在两个或多个应用间是如何传递的。
1.点对点消息传递
- 在点对点消息系统中，消息持久化到一个队列中。此时，将有一个或多个消费者消费队列中的数据。但是一条消息只能被消费一次。
- 当一个消费者消费了队列中的某条数据之后，该条数据则从消息队列中删除。
- 该模式即使有多个消费者同时消费数据，也能保证数据处理的顺序
- 基于推送模型的消息系统，由消息代理记录消费状态。消息代理将消息推送（push）到消费者后，标记这条消息为已经被消费，但是这种方式无法很好地保证消费的处理语义
2.发布订阅消息传递
- 在发布订阅消息系统中，消息被持久化到一个topic中
- 消费者可以订阅一个或多个topic，消费者可以消费该topic中所有的数据，同一条数据可以被多个消费者消费，数据被消费后不会立马删除
- 在发布订阅消息系统中，消息的生产者称为发布者，消费者成为订阅者
- kafka采取拉取模型，由自己控制消费速度，以及消费的进度，消费者可以按照任意的偏移量进行消费。
三、Kafka简介
- kafka是由Apache软件基金会开发的一个开源处理平台，由scala和java编写。kafka是一种高吞吐量的分布式发布订阅消息系统，可以处理消费者在网站中的所有动作流数据。
1.kafka的优点
- 解耦
- 冗余
- 扩展性
- 灵活性和峰值处理能力
- 可恢复性
- 顺序保证
- 缓冲
- 异步通信
2.kafka系统架构
2.1 Broker
- kafka集群包含一个或多个服务器，服务器节点称为broker
2.2 Topic
- 每条发布到kafka集群的消息都有一个类别，这个类别被称为Topic
- 类似于数据库的表明或者ES的Index
- 物理上不同Topic的消息分开存储
- 逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需制定消息的Topic即可生产或者消费数据而不必关心数据存于何处
2.3 Partition
- topic中的数据分割为一个或多个partition
- 每个topic至少有一个partition，当生产者产生数据的时候，根据分配策略，选择分区，然后将消息追加到指定的分区的末尾（队列）
- 每条消息都会有一个自增的编号，标识顺序，用于标识消息的偏移量
- 每个partition中的数据使用多个segment文件存储
- partition中的数据是有序的，不同partition间的数据丢失了数据的顺序
- 如果topic有多个partition，消费数据就不能保证数据的顺序，严格保证消息的消费顺序的场景下，需要将partition数目设为1
2.4 Leader
- 每个partition有多个副本，其中有仅有一个作为leader，leader是当前负责数据的读写的partition
2.5 Follower
- Follower跟随Leader，所有写请求都通过Leader路由，数据变更会广播给所有Follower，Follower与Leader保持数据同步
- 如果Leader失效，则从Follower中选举出一个新的Leader
- 当Follower挂掉、卡住或者同步太慢，Leader会把这个follower从"in sync replicas"(ISR)列表中删除，重新创建一个Follower
2.6 replication
- 数据会存放到topic的partition中，但是有可能分区会损坏
- 需要对分区的数据进行备份
- 将分区分为Leader（1）和Follower（N），Leader负责写入和读取数据，Follower只负责备份，保证了数据的一致性
- 备份数设置为N，表示主+备=N
2.7 producer
- 生产者即数据的发布者，该角色将消息发布到kafka的topic中
- broker接收到生产者发送的消息后，broker将该消息追加到当前用于追加数据的segment文件中
- 生产者发送的消息，存储到一个partition中，生产者也可以指定数据存储的partition
2.8 consumer
- 消费者可以从broker中读取数据，消费者可以消费多个topic中的数据
- kafka提供了两套consumer API：high-level consumer API提供了一个从kafka消费数据的高层抽象，而SimpleConsumer API则需要开发人员更多地关注细节
2.9 Consumer Group
- 每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不能指定group name则属于默认的group）
- 将多个消费者集中到一起去处理某一个Topic的数据，可以更快的提高数据的消费能力
- 整个消费者组共享一组偏移量（防止数据被重复读取），因为一个Topic有多个分区
2.10 offset偏移量：
- 可以唯一的标识一条消息
- 偏移量决定读取数据的位置，不会有线程安全的问题，消费者通过偏移量来决定下次读取的消息
- 消息被消费之后，并不被马上删除，这样多个业务就可以重复使用kafka的消息
- 某一个业务也可以通过修改偏移量达到重新读取消息的目的，偏移量由用户控制
- 消息最终还是会被删除的，默认生命周期为1周