-
解耦
-
冗余
-
扩展性
-
灵活性&峰值处理能力
-
可恢复性
- 系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
-
顺序保证
- 在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。Kafka保证一个Partition内的消息的有序性。
-
缓冲
- 在任何重要的系统中，都会有需要不同的处理时间的元素。例如，加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行——写入队列的处理会尽可能的快速。该缓冲有助于控制和优化数据流经过系统的速度。
-
异步通信
- 很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。
- 定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并自动更新。
- 一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。
- 通过一个容器来解决生产者和消费者的强耦合问题。生产者和消费者彼此之间不直接通讯，而通过阻塞队列来进行通讯
-
解耦
- 假设生产者和消费者分别是两个类。如果让生产者直接调用消费者的某个方法，那么生产者对于消费者就会产生依赖
-
支持并发
- 生产者直接调用消费者的某个方法过程中函数调用是同步的，万一消费者处理数据很慢，生产者就会白白糟蹋大好时光
-
支持忙闲不均
- 缓冲区还有另一个好处。如果制造数据的速度时快时慢，缓冲区的好处就体现出来了。
- 当数据制造快的时候，消费者来不及处理，未处理的数据可以暂时存在缓冲区中。
- 等生产者的制造速度慢下来，消费者再慢慢处理掉。
-
关联到业务对象
- 数据单元必须关联到某种业务对象
-
完整性
- 就是在传输过程中，要保证该数据单元的完整
-
独立性
- 就是各个数据单元之间没有互相依赖
- 某个数据单元传输失败不应该影响已经完成传输的单元；也不应该影响尚未传输的单元。
-
颗粒度
- 数据单元需要关联到某种业务对象。那么数据单元和业务对象应该处于的关系（一对一？一对多）
- 如果颗粒度过小会增加数据传输的次数
- 如果颗粒度过大会增加单个数据传输的时间，影响后期消费
-
在点对点消息系统中，消息持久化到一个队列中。此时，将有一个或多个消费者消费队列中的数据。但是一条消息只能被消费一次。
-
当一个消费者消费了队列中的某条数据之后，该条数据则从消息队列中删除。
-
该模式即使有多个消费者同时消费数据，也能保证数据处理的顺序。
-
基于推送模型的消息系统，由消息代理记录消费状态。
- 消息代理将消息推送(push)到消费者后，标记这条消息为已经被消费，但是这种方式无法很好地保证消费的处理语义。
- 在发布-订阅消息系统中，消息被持久化到一个topic中。
- 消费者可以订阅一个或多个topic，消费者可以消费该topic中所有的数据，同一条数据可以被多个消费者消费，数据被消费后不会立马删除。
- 在发布-订阅消息系统中，消息的生产者称为发布者，消费者称为订阅者。
- Kafka 采取拉取模型(Poll)，由自己控制消费速度，消费者可以按照任意的偏移量进行消费。
- Kafka集群包含一个或多个服务器，服务器节点称为broker
- 每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。
- 类似于数据库的table或者ES的Index
- 物理上不同Topic的消息分开存储
- 逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）
- topic中的数据分割为一个或多个partition
- 每个partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责数据的读写的
partition。
- Follower跟随Leader，所有写请求都通过Leader路由，数据变更会广播给所有Follower，Follower与Leader保持数据同步。
- 如果Leader失效，则从Follower中选举出一个新的Leader。
- 当Follower挂掉、卡住或者同步太慢，leader会把这个follower从“in sync replicas”（ISR）列表中删除，重新创建一个Follower。
-
数据存放在partition中可能会丢失，所以需要备份，我们将分区的分为Leader(1)和Follower(N)
- Leader负责写入和读取数据
- Follower只负责备份
- 保证了数据的一致性
-
备份数设置为N，表示主+备=N
- 生产者即数据的发布者，该角色将消息发布到Kafka的topic中。
- broker接收到生产者发送的消息后，broker将该消息追加到当前用于追加数据的segment文件中。
- 生产者发送的消息，存储到一个partition中，生产者也可以指定数据存储的partition。
- 消费者可以从broker中读取数据。消费者可以消费多个topic中的数据。
- 每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。
- 将多个消费者集中到一起去处理某一个Topic的数据，可以更快的提高数据的消费能力
- 整个消费者组共享一组偏移量(防止数据被重复读取)，因为一个Topic有多个分区
- 可以唯一的标识一条消息
- 偏移量决定读取数据的位置，不会有线程安全的问题，消费者通过偏移量来决定下次读取的消息
- 消息被消费之后，并不被马上删除，这样多个业务就可以重复使用kafka的消息
- 我们某一个业务也可以通过修改偏移量达到重新读取消息的目的,偏移量由用户控制
- 消息最终还是会被删除的，默认生命周期为1周（7*24小时）
- kafka 通过 zookeeper 来存储集群的 meta 信息。
- 主备切换
- 首先主题为单位，除以消费者数量，结果为消费者的平均分配数量，如果有余数n的话，前n个消费者多分配一个
-
轮询（适合单个主题）
- 相对均衡，差值为1，多个主题会造成混乱
- 均匀第一
- 不变第二
-
生产端offset
- Kafka接收到生产者发送的消息实际上是以日志文件的形式保存在对应分区的磁盘上。每条消息都有一个offset值来表示它在分区中的位置。每次写入都是追加到文件的末尾
-
消费端offset
- 消费者在消费时，也维护一个offset，表示消费到分区中的某个消息所在的位置。
- 表示下次继续消费时应该从哪开始
- 新版本默认将偏移量存放到_consumer_oddsets主题中，可以手动或者自动提交数据，自动是5秒钟
-
checkpoint的offset
-
Consumer重置Offset
-
幂等，就是指多接口的多次调用所产生的结果和只调用一次是一致的。没有幂等性的情况下就会重复发送数据
-
producer id
- 每个新的生产者实例在初始化的时候都会被分配一个PID，这个PID对用户而言是完全透明的。
-
sequence number(sn)
- 对于每个PID，消息发送到的每一个分区都有对应的序列号，这些序列号从0开始单调递增。生产者每发送一条消息就会将对应的序列号的值加1。
-
判断
- 如果SN_new = SN_old + 1时，broker才会接收它。
- 如果SN_new< SN_old + 1，那么说明消息被重复写入，broker可以直接将其丢弃。
- 如果SN_new> SN_old + 1，那么说明中间有数据尚未写入，出现了乱序，暗示可能有消息丢失，这个异常是一个严重的异常。
- 解决幂等性不能跨partition运作的问题事务提供了多个partition写入的原子性
- 即写入多个Partition要么全部成功，要么全部失败，不会出现部分成功部分失败这种情况。
-
保证生产者发送的信息可以到达Partition
-
0
- 不需要Leader返回ACK，效率高，不安全，最多一条
-
1
- 需要Leader返回ACK，效率一般高，一般安全，最少一条
-
-1
- 需要Leader+Follower返回ACK，效率低，很安全，最少一条
-
-
HW
- 最高水平线，所有副本的最小LEO
-
LEO
- 每个副本最大的Offset
-
Follower故障
- Follower 发生故障后会被临时踢出 ISR 集合，待该 Follower 恢复后，Follower 会 读取本地磁盘记录的上次的 HW，并将 log 文件高于 HW 的部分截取掉，从 HW 开始向 Leader 进行同步数据 *** 作。
- 等该 Follower 的 LEO 大于等于该 Partition 的 HW，即 Follower 追上 Leader 后，就可以重新加入 ISR 了
-
Leader故障
-
Leader 发生故障后，会从 ISR 中选出一个新的 Leader，之后，为保证多个副本之间的数据一
致性，其余的 Follower 会先将各自的 log 文件高于 HW 的部分截掉，然后从新的 Leader 同
步数据。 -
注意：这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。
-
- ISR(在同步队列)
- OSR（离开同步队列）
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）