金山企业型网站建设,网站项目签约,宁波seo网络优化哪家好,做网站的是什么文章目录 1、RabbitMQ1.1 RabbitMQ-如何保证消息不丢失1.2 RabbitMQ消息的重复消费问题如何解决的1.3 RabbitMQ中死信交换机 ? (RabbitMQ延迟队列有了解过嘛)1.4 RabbitMQ如果有100万消息堆积在MQ , 如何解决(消息堆积怎么解决)1.5 RabbitMQ的高可用机制有了解过嘛 2、Kafka2.… 文章目录 1、RabbitMQ1.1 RabbitMQ-如何保证消息不丢失1.2 RabbitMQ消息的重复消费问题如何解决的1.3 RabbitMQ中死信交换机 ? (RabbitMQ延迟队列有了解过嘛)1.4 RabbitMQ如果有100万消息堆积在MQ , 如何解决(消息堆积怎么解决)1.5 RabbitMQ的高可用机制有了解过嘛 2、Kafka2.1 Kafka是如何保证消息不丢失2.2 Kafka中消息的重复消费问题如何解决的2.3 Kafka是如何保证消费的顺序性2.4 Kafka的高可用机制有了解过嘛2.5 解释一下复制机制中的ISR2.6 Kafka数据清理机制了解过嘛2.7 Kafka中实现高性能的设计有了解过嘛 1、RabbitMQ
1.1 RabbitMQ-如何保证消息不丢失
开启生产者确认机制确保生产者的消息能到达队列开启持久化功能确保消息未消费前在队列中不会丢失开启消费者确认机制为auto由spring确认消息处理成功后完成ack开启消费者失败重试机制多次重试失败后将消息投递到异常交换机交由人工处理
首先需要知道消息会在什么地方会丢失 消息从生产者发送到消费者消费的整个流程都可能丢失消息 生产者确认机制生产者阶段
RabbitMQ提供了publisher confirm机制来避免消息发送到MQ过程中丢失。消息发送到MQ以后会返回一个结果给发送者表示消息是否处理成功 消息失败之后如何处理呢 回调方法即时重发 记录日志 保存到数据库然后定时重发成功发送后即刻删除表中的数据 消息持久化mq阶段
MQ默认是内存存储消息开启持久化功能可以确保缓存在MQ中的消息不丢失。 在配置 MQ的时候对交换机、队列可以设置持久化
消费者确认
RabbitMQ支持消费者确认机制即消费者处理消息后可以向MQ发送ack回执MQ收到ack回执后才会删除该消息。而SpringAMQP则允许配置三种确认模式 manual手动ack需要在业务代码结束后调用api发送ack。auto自动ack由spring监测listener代码是否出现异常没有异常则返回ack抛出异常则返回nacknone关闭ackMQ假定消费者获取消息后会成功处理因此消息投递后立即被删除 我们可以利用Spring的retry机制在消费者出现异常时利用本地重试设置重试次数当次数达到了以后如果消息依然失败将消息投递到异常交换机交由人工处理 1.2 RabbitMQ消息的重复消费问题如何解决的
首先要知道为什么会重复消费 如果在消费者消费完消息之后要给mq发送ack确认消息的时候突然因为网络抖动或者消费者宕机了使得消息没有被确认消费就不会再mq中剔除造成别的消费者也能拿到消息然后消费 解决办法有两种 每条消息设置一个唯一的标识id效率高 每次消费者消费的时候都要检查数据库里面是否已经有了这个数据根据唯一标识id有代表消费过了就不让消费 幂等方案【 redis分布式锁、数据库锁悲观锁、乐观锁 】枷锁效率不高 1.3 RabbitMQ中死信交换机 ? (RabbitMQ延迟队列有了解过嘛)
延迟队列进入队列的消息会被延迟消费的队列 场景超时订单、限时优惠、定时发布
延迟队列就是由死信交换机TTL生存时间组成的
死信交换机 当一个队列中的消息满足下列情况之一时可以成为死信dead letter
消费者使用basic.reject或 basic.nack声明消费失败并且消息的requeue参数设置为false消息是一个过期消息超时无人消费要投递的队列消息堆积满了最早的消息可能成为死信
如果该队列配置了dead-letter-exchange属性指定了一个交换机那么队列中的死信就会投递到这个交换机中而这个交换机称为死信交换机Dead Letter Exchange简称DLX。 TTL TTL也就是Time-To-Live。如果一个队列中的消息TTL结束仍未消费则会变为死信ttl超时分为两种情况
消息所在的队列设置了存活时间消息本身设置了存活时间 延迟队列插件
DelayExchange的本质还是官方的三种交换机只是添加了延迟功能。因此使用时只需要声明一个交换机交换机的类型可以是任意类型然后设定delayed属性为true即可。 1.4 RabbitMQ如果有100万消息堆积在MQ , 如何解决(消息堆积怎么解决)
解决消息堆积有三种种思路
增加更多消费者提高消费速度在消费者内开启线程池加快消息处理速度扩大队列容积提高堆积上限采用惰性队列 在声明队列的时候可以设置属性x-queue-mode为lazy即为惰性队列 基于磁盘存储消息上限高 性能比较稳定但基于磁盘存储受限于磁盘IO时效性会降低 为什么会出现消息堆积无非就是消费速度赶上不消费速度 就会导致队列中的消息堆积直到队列存储消息达到上限。之后发送的消息就会成为死信可能会被丢弃 惰性队列 惰性队列的特征如下
接收到消息后直接存入磁盘而非内存消费者要消费消息时才会从磁盘中读取并加载到内存支持数百万条的消息存储 1.5 RabbitMQ的高可用机制有了解过嘛
高可用无非就是做集群一个节点宕机了别的节点还能使用使得数据不被丢失
普通集群(不推荐
会在集群的各个节点间共享部分数据包括交换机、队列元信息。不包含队列中的消息。当访问集群某节点时如果队列不在该节点会从数据所在节点传递到当前节点并返回队列所在节点宕机队列中的消息就会丢失 镜像集群也会造成数据丢失 镜像集群本质是主从模式具备下面的特征
交换机、队列、队列中的消息会在各个mq的镜像节点之间同步备份。创建队列的节点被称为该队列的主节点备份到的其它节点叫做该队列的镜像节点。一个队列的主节点可能是另一个队列的镜像节点所有操作都是主节点完成然后同步给镜像节点主宕机后镜像节点会替代成新的主 若主节点还没给镜像节点同步就宕机了还是会造成数据丢失 仲裁队列
仲裁队列仲裁队列是3.8版本以后才有的新功能用来替代镜像队列具备下列特征
与镜像队列一样都是主从模式支持主从数据同步使用非常简单没有复杂的配置主从同步基于Raft协议强一致 2、Kafka
2.1 Kafka是如何保证消息不丢失
需要从三个层面去解决这个问题
生产者发送消息到Brocker丢失 设置异步发送发送失败使用回调进行记录或重发 失败重试参数配置可以设置重试次数 消息在Brocker中存储丢失 发送确认acks选择all让所有的副本都参与保存数据后确认 消费者从Brocker接收消息丢失 关闭自动提交偏移量开启手动提交偏移量 提交方式最好是同步异步提交 首先得知道消息在传递过程中经历过哪些阶段 所以在生产者、kafka的Brocker、消费者都会出现消息丢失现象
生产者发送消息到Brocker丢失 解决办法1、异步发送发送失败记录日志。2、开启失败重试 消息在Brocker中存储丢失 解决办法就是Brocker收到消息之后给生产者发送一个ack确认告诉生产者消息接收到了至于这个消息是leader发还是leader和follower一起发取决于ack的参数值 像acksall 就需要所有的追随者follower都同步消息了才会给生产者发送ack确认效率就很慢一般设置ack1由leader发送确认消息就行了
消费者从Brocker接收消息丢失 消费者消费消息是根据分区中的偏移量来按位消费的 消费者默认是自动按期提交已经消费的偏移量默认是每隔5s提交一次 如果出现重平衡的情况可能会重复消费或丢失数据 正常消费 重平衡 会导致消息丢失或者消息重读 消息重读 若此刻consumer2消费消息之后还没有将偏移量更新同步到分区当中突然宕机了此刻consumer1会继承consumer2的分区继续跟着原来的偏移量消费此刻就会造成重复消费。 消息丢失 也就是提交偏移量和实际消费的消息有偏差本来要消费3个结果只消费了1个然后偏移量也提交到了3然后突然宕机了这个时候别的消费者继承分区之后会从3之后开始消费这时候2,3位置的消息就丢失了 解决办法就是把自动设置偏移量设置为手动 禁用自动提交偏移量改为手动 同步提交 异步提交 同步异步组合提交 幂等方案根据全局唯一id来判断重复提交或者加分布式锁 例如 2.2 Kafka中消息的重复消费问题如何解决的
参考2.1重平衡消息重读
关闭自动提交偏移量开启手动提交偏移量提交方式最好是同步异步提交幂等方案 2.3 Kafka是如何保证消费的顺序性
问题原因 一个topic的数据可能存储在不同的分区中每个分区都有一个按照顺序的存储的偏移量如果消费者关联了多个分区不能保证顺序性 解决方案
topic分区中消息只能由消费者组中的唯一一个消费者处理所以消息肯定是按照先后顺序进行处理的。但是它也仅仅是保证Topic的一个分区顺序处理不能保证跨分区的消息先后处理顺序。 所以如果你想要顺序的处理Topic的所有消息那就只提供一个分区。 发送消息时指定分区号 主要发送消息时按照相同的业务设置相同的key 首先得知道kafka默认是不确保消费的顺序性的因为一个消费者可能负责几个分区而消费者又是根据偏移量来消费的不同分区的偏移量自然是不同的
假设用户先充值再转账那么必须先充值才能去转账这样就要保证消费的顺序性
转账和充值消息在不同分区 转账和充值消息在同一分区 这样就能保证转账操作一定是在充值动作的后面执行也就保证了消费的顺序性 可以直接指定分区或者根据key的hashCode来计算分区位置保证需要顺序消费的信息在同一分区 2.4 Kafka的高可用机制有了解过嘛
集群 一个kafka集群由多个broker实例组成即使某一台宕机也不耽误其他broker继续对外提供服务 复制机制 一个topic有多个分区每个分区有多个副本有一个leader其余的是follower副本存储在不同的broker中所有的分区副本的内容是都是相同的如果leader发生故障时会自动将其中一个follower提升为leader保证了系统的容错性、高可用性 集群模式 Kafka 的服务器端由被称为 Broker 的服务进程构成即一个 Kafka 集群由多个 Broker 组成这样如果集群中某一台机器宕机其他机器上的 Broker 也依然能够对外提供服务。这其实就是 Kafka 提供高可用的手段之一 分区备份机制 主负责读写从只负责当做副本在主宕机了就上去当主 一个topic有多个分区每个分区有多个副本其中有一个leader其余的是follower副本存储在不同的broker中所有的分区副本的内容是都是相同的如果leader发生故障时会自动将其中一个follower提升为leader 其实里面的follower从节点也分为两种一种ISR节点同步复制一种普通副本节点异步复制 参考本文 2.6 2.5 解释一下复制机制中的ISR
ISRin-sync replica需要同步复制保存的follower
如果leader失效后需要选出新的leader选举的原则如下
第一选举时优先从ISR中选定因为这个列表中follower的数据是与leader同步的第二如果ISR列表中的follower都不行了就只能从其他follower中选取 所以ISR类型的节点设置也需要根据实际设置太多影响效率太少当主节点宕机可能会出现不够用 ISR-follower和主节点复制是同步的数据完整性强普通follower是异步复制完成的数据的完整性肯定不如ISR-follower若都设置为ISR节点虽然数据完整性强同步必然导致阻塞所以只有在ISR节点不够用的情况下才会去考虑拿普通的节点来充当为主节点 2.6 Kafka数据清理机制了解过嘛
Kafka存储结构 Kafka中topic的数据存储在分区上分区如果文件过大会分段存储segment每个分段都在磁盘上以索引(xxxx.index)和日志文件(xxxx.log)的形式存储分段的好处是第一能够减少单个文件内容的大小查找数据方便第二方便kafka进行日志清理。 日志的清理策略有两个 根据消息的保留时间当消息保存的时间超过了指定的时间就会触发清理默认是168小时 7天根据topic存储的数据大小当topic所占的日志文件大小大于一定的阈值默认1G则开始删除最久的消息。默认关闭 首先得知道kafka的数据存储结构 为什么分段 删除无用文件方便提高磁盘利用率 查找数据便捷
文件的命令基本上都是按照偏移量来命名的查找方便
数据清理机制
List item 2.7 Kafka中实现高性能的设计有了解过嘛 消息分区不受单台服务器的限制可以不受限的处理更多的数据 顺序读写磁盘顺序读写提升读写效率 页缓存把磁盘中的数据缓存到内存中把对磁盘的访问变为对内存的访问访问内存自然比直接访问磁盘快 零拷贝减少上下文切换及数据拷贝 消息压缩减少磁盘IO和网络IO 分批发送将消息打包批量发送减少网络开销
顺序读写磁盘顺序读写提升读写效率 零拷贝减少上下文切换及数据拷贝关键 一般的消费者去消费的过程包含4次拷贝因为消费者和生产者一般不处于一个服务器需要由网卡转发给别的服务器的消费者 零拷贝就省略了从页缓存取出数据由kafka交给网卡转发给消费者而是直接由页缓存把数据交给网卡再转交给消费者
既减少了用户态和内核态的切换上下文切换也减少了IO拷贝带来的开销 更新中
参考来自黑马程序员
