注册公司制作网站,营销型网站有哪些功能,wordpress迁移需要重新安装,企业展示型网站怎么建一. 消息中间件kafka
(1)基本概念 (2) 生产者
生产者将消息发送到topic中去#xff0c;同时负责选择将message发送到topic的哪一个partition中。通过round-robin做简单的负载均衡。也可以根据消息中的某一个关键字来进行区分。通常第二种方式使用的更多。
(3)消费者
消费模… 一. 消息中间件kafka
(1)基本概念 (2) 生产者
生产者将消息发送到topic中去同时负责选择将message发送到topic的哪一个partition中。通过round-robin做简单的负载均衡。也可以根据消息中的某一个关键字来进行区分。通常第二种方式使用的更多。
(3)消费者
消费模式
传统的消息传递模式有2种队列( queue) 和publish-subscribe
queue模式多个consumer从服务器中读取数据消息只会到达一个consumer。publish-subscribe模式消息会被广播给所有的consumer。
Kafka基于这2种模式提供了一种consumer的抽象概念consumer group。
queue模式所有的consumer都位于同一个consumer group 下。publish-subscribe模式所有的consumer都有着自己唯一的consumer group。
消费顺序
一个partition同一个时刻在一个consumer group中只能有一个consumer instance在消费从而保证消费顺序。consumer group中的consumer instance的数量不能比一个Topic中的partition的数量多否则多出来的consumer消费不到消息。Kafka只在partition的范围内保证消息消费的局部顺序性不能在同一个topic中的多个partition中保证总的消费顺序性。如果有在总体上保证消费顺序的需求那么我们可以通过将topic的partition数量设置为1将consumer group中的consumer instance数量也设置为1但是这样会影响性能所以kafka的顺序消费很少用。
(4)rebalance
rebalance就是说如果消费组里的消费者数量有变化或消费的分区数有变化kafka会重新分配消费者消费分区的关系。比如consumer group中某个消费者挂了此时会自动把分配给他的分区交给其他的消费者如果他又重启了那么又会把一些分区重新交还给他。
如下情况可能会触发消费者rebalance
消费组里的consumer增加或减少了动态给topic增加了分区消费组订阅了更多的topic
rebalance过程中消费者无法从kafka消费消息这对kafka的TPS会有影响如果kafka集群内节点较多比如数百个那重平衡可能会耗时极多所以应尽量避免在系统高峰期的重平衡发生。
消费者Rebalance分区分配策略 主要有三种rebalance的策略range、round-robin、sticky。 Kafka 提供了消费者客户端参数partition.assignment.strategy 来设置消费者与订阅主题之间的分区分配策略。默认情况为range分配策略。
(5)应用场景
日志收集一个公司可以用Kafka收集各种服务的log通过kafka以统一接口服务的方式开放给各种consumer例如hadoop、Hbase、Solr等。
消息系统解耦和生产者和消费者、缓存消息等。
用户活动跟踪Kafka经常被用来记录web用户或者app用户的各种活动如浏览网页、搜索、点击等活动这些活动信息被各个服务器发布到kafka的topic中然后订阅者通过订阅这些topic来做实时的监控分析或者装载到hadoop、数据仓库中做离线分析和挖掘。
运营指标Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据生产各种操作的集中反馈比如报警和报告。
(6)高性能原因
磁盘顺序读写kafka消息不能修改以及不会从文件中间删除保证了磁盘顺序读kafka的消息写入文件都是追加在文件末尾不会写入文件中的某个位置(随机写)保证了磁盘顺序写。数据传输的零拷贝
(7)kafka副本的作用
副本机制Replication
又称为备份机制通常是指在分布式系中在多台机器中存储相同的数据进行备份的机制副本机制只要有3个好处。
提供数据冗余即使部分机器出现故障系统仍然可以提供服务增加了整体的可用性和数据持久化。提供高伸缩性支持横向扩展可以通过增加副本数来提供读性能。改善数据局部性允许将数据放入与用户地理位置相近的地方从而降低系统延时。但是kafka的副本机制只提供了第一个特点即提供数据冗余的特性。
在kafka中副本是有一个leader节点和多个follower节点组成leader节点负责接收消息和消费消息follower既不提供写服务也不提供读服务仅仅用于同步leader副本的消息。follower副本的唯一作用就是当leader副本出现问题时通过ZooKeeper 提供的监控功能能够实时感知到并立即开启新一轮的领导者选举从追随者副本中选一个作为新的领导者。 所谓的ISR集合就是指副本中的消息和leader副本的消息是同步的没有落后太多的其中集合中是包含leader副本自身的。
ISR集合的作用主要有两个方面
leader选举范围当leader部分挂掉后某个follower副本会被选为新的leader副本能够被选为leader副本的条件就是需要在ISR集合中当然这个是可以进行参数配置的broker有一个参数unclean.leader.election.enable 用来进行控制是否可以从非ISR集合中的副本选为leader节点。如果设置为true开启 Unclean 领导者选举可能会造成数据丢失但好处是它使得分区 Leader 副本一直存在不至于停止对外提供服务因此提升了高可用性。反之禁止 Unclean 领导者选举的好处在于维护了数据的一致性避免了消息丢失但牺牲了高可用性。这个就是CAP原理中C和A的取舍问题。
生产ack为-1发送写入的数据生产者发送消息后消息需要写入ISR集合中全部副本才算提交成功ISR集合中只有leader一个节点那么这个时候-1就退化为了1。 副本同步机制
在kafka中follower副本需要定期从leader部分中拉取消息在进行消息拉取时主要有两个概念需要弄清楚
高水位HW定义消息可见性即用来标识分区下的哪些消息是可以被消费者消费的只有在高水位以下的消息才能被消费者进行消费并且利用次机制来完成kafka副本的消息同步。
日志末端位移LEO即Log End Offset表示消息下一条消息写入的位置注意此时这条消息是未写入到kafka中的。在kafka中每个副本都有自己的高水位和LEO信息。 高水位更新机制
在kafka中leader副本所在的broker节点上会保存所有follower副本的LEO值。在leader副本所在broker节点上的follower副本值称之为远程副本Remote Replicakafka在运行过程中会不断更新Broker 1 上 Follower 副本的高水位和 LEO 值同时也会更新 Broker 0 上 Leader 副本的高水位和 LEO 以及所有远程副本的 LEO但它不会更新远程副本的高水位值。broker0保存远程副本的信息值就是为了leader副本来确定高水位值leader副本的HW就是整个分区的HW值。 每个值的更新时机
Broker1上的follower副本会从leader副本拉取消息写入到本地磁盘后会更新其LEO的值。Broker0上的leader副本接收到生产者发送的消息写入到本地磁盘后会更新其LEO的值。Follower副本从leader副本拉取消失时会告诉leader副本从哪个位置开始拉取消息。leader副本收到这个消息后会更新本机上对应的远程副本的LEO值。Follower副本成功更新LEO值后会比较其LEO值和Leader副本发过来的HW的值取两者的最小值来更新自己的HW值。当Leader副本更新完自身LEO值或者更新了远程副本的LEO值时然后比较Leader副本和所有远程部分的LEO值其最小值作为自己的HW值并进行更新。副本同步流程解析
在初始状态下所有值都为0 当生成者给主题发送消息后leader分区写入消息后leader的LEO变为1 此时follower过来拉取消息消息拉取成功将自身的LEO也更新为1此时每个副本的HW还是为0需要在下一次fetchOffset请求时更新对应的值 当follower再次拉取消息时follwoer副本请求拉取的值为1Leader 副本接收到此请求后更新远程副本 LEO 为 1然后更新 Leader 高水位为 1。做完这些之后它会将当前已更新过的高水位值 1 发送给 Follower 副本。Follower 副本接收到以后也将自己的高水位值更新成 1。 高水位存在的问题Leader 副本高水位更新和 Follower 副本高水位更新在时间上是存在错配的。这种错配是很多“数据丢失”或“数据不一致”问题的根源。为了防止这种问题社区在0.11版本之后引入了Leader Epoch 概念来规避因高水位更新错配导致的各种不一致问题。
数据丢失场景分析因为整个消息同步过程存在HW同步的一个延迟当A的HW为1B的HW为2值此时A还没同步到B的HW值时RelicaA发生宕机A重启后会根据之前的HW值保存在本地replication-offset-checkpoint中进行日志截断这时消息m2就会丢失刚好此时ReplicaB发送宕机ReplicaA被选为了Leader节点由于follower副本的HW不能比Leader的HW值高节点B在恢复后也会进行日志截取消息m2就会彻底丢失掉。 Leader Epoch
可以理解为Leader的版本由两部门组成
Epoch一个单调递增的版本号每当发送leader变更时就会增加小版本号的 Leader 被认为是过期 Leader不能再行使 Leader 权力。起始位移Start OffsetLeader 副本在该 Epoch 值上写入的首条消息的位移。举例说明假设有两个Leader EpochLeader Epoch0, 0 和 1, 120第一个Leader Epoch表示版本号为0Leader 从位移 0 开始保存消息在写了120条消息后发生了leader变更新的leader的版本号为1起始位移为120。
如何防止数据丢失此时如果A发生了宕机重启后并不会马上进行日志截取而是会向Leader发送一个OffsetsForLeaderEpochRequest请求那么此时Leader返回的是2此时该 LEO 值不比它自己的 LEO 值小而且缓存中也没有保存任何起始位移值 2 的 Epoch 条目因此 A 无需执行任何日志截断操作。 (8)kafka副本对性能的影响 (9)kafka与其他消息队列相比优势
出发点不一样kafka定位就是处理日志和大数据 在这些业务领域topic不会太多延迟问题自然也就没有。
数据存储结构是主要原因还有就是kafka只支持pull模式。而rocketmq有pull、push两种模式 (虽然这个push模式是假push)push模式延迟肯定是比pull模式延迟低。
push模式是基于pull模式的本地有个定时线程去pull broker的消息缓存到本地然后push到消费线程那边。
rabbit 的push模式 是真的push 所以 延迟最低的就是兔子。 兔子不支持分布式只支持主从模式 本身设计就是小而美的单机版。cpu消耗比kafka之类低多了。
1.是否支持延时消息
RocketMQ支持固定延时等级的延时消息等级可配置kafka不支持延时消息
2.消息过滤方式不同
RocketMQ执行过滤是在Broker端支持tag过滤及自定义过滤逻辑Kafka不支持Broker端的消息过滤需要在消费端自定义实现
3.消息失败是否支持重试
Kafka不支持重试 通过另外创建消息重试topic实现重试RocketMQ支持定时重试每次重试间隔逐渐增加
4.事务机制不同
两个消息中心的事务机制也有所不同。RocketMq通过二阶段提交和回查机制能够实现分布式场景下的事务两个系统进行处理同一业务流程交易时保证生产方处理和发送消息阶段两个动作要么同时成功要么同时失败。而Kafka则是保证生产者发送多条消息可以封装在一个事务中形成一个原子操作
kafka rocket mq对比【精选】rocketMq和kafka对比_kafka和rocketmq-CSDN博客
1. 使用场景Kafka适合日志处理RocketMQ适合业务处理
2. 性能Kafka吞吐量更高单机百万/秒RocketMQ单机10万/秒。 因为Kafka一个topic有很多partition代表很多目录每个目录下有很多segment每个代表一个消息文件而RocketMQ存储消息只有commitLog文件。所以Kafka可以并发写快于RocketMQ。但同样的当Topic增加Kafka分区文件增多文件刷盘时会竞争磁盘资源而导致效率降低。 同时生产者有一个发送消息的缓存队列客户端发送后放入缓存立刻返回成功。当缓存队列达到阈值才真正发送给broker此举合并了多次请求批量发送批量压缩减少网络IO但增大消息丢失风险
3. 特殊消息Kafka不支持定时事务消息等
4. 支持队列数Kafka超过64个队列partition性能下降严重而RocketMQ最高支持5万个队列 消息队列原理和选型Kafka、RocketMQ 、RabbitMQ 和 ActiveMQ - 知乎
(10)kafka如何确保不丢失消息
1.生产者环节丢失 生产者环节发送失败导致的丢失导致的原因可能是网络波动的原因或是kafka节点故障的原因
生产者发送消息的方式有两种 同步 与 异步 【解决方案】 采用异步推送消息的方式因为消息异步推送后会有一个回调函数根据回调函数的情况可以对消息进行补发 此外还可以设置消息重试次数
代码如下 2.Broker存储环节丢失 Broker存储环节kafka对此有一个发送确认机制acks; 结合考虑kafka集群的情况下 【解决方案】 acks发送确认机制有三种模式 默认acks1,只要集群leader节点收到消息就响应成功 acksall可以避免在极端情况下消息在存储环节出现问题但是要综合考虑其性能[不建议]
该处使用的url网络请求的数据。 刷盘机制分同步刷盘和异步刷盘
生产者消息发过来时只有持久化到磁盘存储端Broker才返回一个成功的ACK响应这就是同步刷盘。它保证消息不丢失但是影响了性能。 异步刷盘的话只要消息写入PageCache缓存就返回一个成功的ACK响应。这样提高了MQ的性能但是如果这时候机器断电了就会丢失消息。 Broker一般是集群部署的有master主节点和slave从节点。消息到Broker存储端只有主节点和从节点都写入成功才反馈成功的ack给生产者这就是同步复制它保证了消息不丢失但是降低了系统的吞吐量。与之对应的就是异步复制只要消息写入主节点成功就返回成功的ack它速度快但是会有性能问题。
在kafka中避免broker宕机可以设置多副本冗余的高可用机制
3.消费者环节丢失 该环节丢失原因 节点重平衡 和 偏移量自动提交导致的 【消费者节点重平衡】可以简单的理解为一个消费者组中有一个消费者挂了接着另一个消费者会接班之前的消费工作 【偏移量自动提交】每次poll数据之后消费者默认每隔5s就会提交一次已消费的偏移量 会导致一下情况 【重复消费】 消费者节点宕机之前还未来得及提交偏移量重平衡之后新分配的消费者按照之前的偏移量进行消费从而导致了重复消费 【消费丢失】消费者节点宕机之前提交了偏移量但是实际的消费偏移量还未到达提交的偏移量从而导致了消费丢失
【解决方案】 禁用自动提交偏移量改为手动 enable-auto-commit:false
代码如下 【扩展】为什么采用了 异步 同步的方式 因为 同步提交的时候消费端的程序会处于阻塞状态进而会影响系统数据的吞吐量 而 异步提交方式虽然解决了提交偏移量阻塞的问题但是是没有自动重试机制的会出现一定的风险 所以二者相组合使用进行互补 kafka消息丢失解决方案_勤天的博客-CSDN博客
【348期】面试官Kafka和RocketMQ有什么区别 - 知乎
https://zhuanlan.zhihu.com/p/423309452rocketmq 与 kafka 对比漫谈 - 简书
Spring Cloud十二消息中心篇-RocketMq与Kafka选型四 - 墨天轮
kafka和rocketmq区别对比_—Phoenix的博客-CSDN博客 Kafka基础原理 - 简书
美团面试官让我聊聊kafka的副本同步机制我忍不住哭了_wx646db0e245a37的技术博客_51CTO博客
kafka副本机制
浅析操作系统和Netty中的零拷贝机制
