杏坛网站建设,建材网站建设公司,影视怎么建设网站,时装 wordpress参考资料 RabbitMQ官方网站RabbitMQ官方文档噼咔噼咔-动力节点教程 文章目录 十一、队列Queue的消息属性11.1 具体属性11.2 自动删除11.2 自定义参数11.2.1 **Message TTL** 消息存活时间11.2.2 **Auto expire** 队列自动到期时间11.2.3 **Overflow behaviour** 溢出行为11.2.4… 参考资料 RabbitMQ官方网站RabbitMQ官方文档噼咔噼咔-动力节点教程 文章目录 十一、队列Queue的消息属性11.1 具体属性11.2 自动删除11.2 自定义参数11.2.1 **Message TTL** 消息存活时间11.2.2 **Auto expire** 队列自动到期时间11.2.3 **Overflow behaviour** 溢出行为11.2.4 **Single active consumer**单一消费者模式11.2.5 **Dead letter exchange**死信交换机和 **Dead letter routing key**死信路由key11.2.6 Max length队列最大信息数 和Max length bytes 队列磁盘大小11.2.7 **Maximum priority**最高优先级11.2.8 Lazy mode懒模式11.2.9 **Master locator**主定位器 十二、消息的可靠性投递12.1 概念理解12.2 如何提高消息的可靠性12.2.1 消息发送时的确认模式12.2.2 消息返回模式1.2.2.3 持久化机制12.2.4 消费时的确认模式12.2.5 集群、镜像队列保证高可用 十三、消息的幂等性13.1 概念13.1.1 幂等性13.1 举例:接口幂等性13.2 数据库的幂等性 13.2 如何避免消息的重复消费问题消息消费时的幂等性13.1 全局唯一id Redis 13.3 :star:代码实现13.3.1 环境准备13.3.2 实例思路整理 十一、队列Queue的消息属性
11.1 具体属性 Type类型只需要关注classicName名称Durability持久化Auto Delete是否自动删除Arguments参数
11.2 自动删除
当最后一个消费者断开连接后队列将会删除一般不会用存在数据丢失的风险
11.2 自定义参数
11.2.1 Message TTL 消息存活时间
官方解释定义了一个消息再被推送后再被丢弃之前可以存活的时间单位毫秒参数格式 “x-message-ttl” number如果消息在指定的时间段内未被消费则该消息将被标记为过期并被丢弃。这可以确保不再需要的消息不会一直存在于队列中从而占据资源。
11.2.2 Auto expire 队列自动到期时间 官方解释x-expires 在自动删除队列之前队列可以闲置多长时间How long a queue can be unused for before it is automatically deleted 定义了队列自动过期的时间。 参数格式 “x-expires”number 如果队列在指定的时间段内未被使用则该队列将被自动删除。 这可以确保不再需要的队列不会一直存在于RabbitMQ服务器上从而占据资源。
11.2.3 Overflow behaviour 溢出行为
官方解释 queue overflow behaviouroverflow behavior参数用于定义当队列达到最大容量时的处理方式。参数格式“x-overflow”string在RabbitMQ中有以下几种可选的overflow behavior drop-head: 当队列达到最大容量时新的消息将被丢弃并且最早进入队列的消息会被删除以腾出空间给新的消息。reject-publish: 当队列达到最大容量时新的消息将被拒绝发送并且发布者将收到一个拒绝通知。这种方式可以让发布者有机会处理无法发送的消息。reject-publish-dlx: 当队列达到最大容量时新的消息将被拒绝发送并且发布者将收到一个拒绝通知。同时被拒绝的消息会被发送到一个死信交换器Dead-Letter Exchange以便后续进行处理。reject-subscribe: 当队列达到最大容量时新的订阅者将无法成功订阅该队列并且会收到一个拒绝通知。这种方式可以让订阅者有机会处理无法接收的消息。
11.2.4 Single active consumer单一消费者模式
Single active consumer单一活动消费者是一种消息队列的消费模式。在这种模式下一个队列只能有一个活动的消费者来处理消息而其他消费者处于非活动状态。参数格式“x-single-active-consumer”bool使用Single active consumer模式可以确保消息的顺序性和可靠性。 当只有一个消费者活动时消息将按照顺序被处理避免了多个消费者并发处理消息可能引起的顺序混乱问题。此外由于只有一个消费者在处理消息可以减少并发操作带来的资源竞争和冲突。 Single active consumer模式也存在一些限制。 于只有一个消费者在处理消息如果该消费者出现故障或变得不可用整个消息队列将无法被处理。因此在设计系统时需要考虑到这种单点故障的风险并采取相应的容错和监控机制来保证系统的可用性。
11.2.5 Dead letter exchange死信交换机和 Dead letter routing key死信路由key
两者配合可以指定DLX发送的交换机和键之前已经研究过就不做赘述了
11.2.6 Max length队列最大信息数 和Max length bytes 队列磁盘大小 Max length参数用于限制队列中消息的最大数量。当队列中的消息数达到最大值时新的消息将被拒绝并返回给发布者。 Max length bytes参数用于限制队列中消息的最大总大小磁盘空间。当队列中所有消息的大小总和达到最大值时新的消息将被拒绝并返回给发布者。
这两个参数可以用于控制队列的大小以避免队列过度增长导致系统资源耗尽。在设置这些参数时需要根据具体的业务需求和系统资源情况进行权衡和调整。 注意Max length bytes的单位是byte。比如要设置1G的最大磁盘空间 x-max-length-bytes: 107374182411.2.7 Maximum priority最高优先级
当消息被发布到队列时可以为消息设置一个优先级优先级越高的消息将会被先处理。使用Maximum priority参数可以限制队列中消息的最大优先级超过该优先级的消息将被丢弃或者被发送到死信交换器Dead-Letter Exchange。
11.2.8 Lazy mode懒模式 用于延迟队列的内存分配从而减少内存的使用量。 在Lazy mode下队列的消息不会立即被写入磁盘而是先被存储在内存中直到内存达到一定的阈值时才会被写入磁盘。 默认情况下消息会一直存在内存中占用过多内存可能会导致运行过慢、消息丢失、系统崩溃等问题 使用Lazy mode可以在一定程度上降低队列的内存使用量提高系统的性能和可扩展性。 然而由于消息需要等待一定时间才能被写入磁盘因此在使用Lazy mode时需要注意消息的持久化和数据丢失的风险。如果需要确保消息不会丢失需要将消息设置为持久化并且在队列中启用持久化模式。 参数配置格式 “x-queue-mode” “lazy”
11.2.9 Master locator主定位器
用于集群暂不涉及
RabbitMQ的Master locator用于在集群中查找当前拥有某个队列的主节点Master Node。在RabbitMQ集群中一个队列可以被复制到多个节点上其中一个节点被指定为主节点其他节点为从节点。主节点负责处理所有的读写请求而从节点只负责复制主节点上的数据。
十二、消息的可靠性投递
12.1 概念理解
消息的可靠性投递是指在消息传递过程中确保消息能够被成功地传递到目标节点并被消费者正确地处理。
在消息传递中可能会发生网络故障、节点宕机等问题这些问题可能会导致消息丢失或重复传递从而影响系统的可靠性和稳定性。
12.2 如何提高消息的可靠性
注意
消息的可靠性投递就是要保证消息投递过程中每一个环节都要成功那么这肯定会牺牲些性能性能与可靠性是无法兼得的
如果业务实时一致性要求不是特别高的场景可以牺牲一些可靠性来换取性能。
消息的传递模型如下 12.2.1 消息发送时的确认模式
对应第一步的生产者到交换机的这一步确保消息成功发送到交换机
12.2.2 消息返回模式
对应的是交换机到队列这一步确保消息成功从交换机发送到队列中 当然在实际生产环境下我们不会出现这种问题必须对所有的name和key进行严格测试才能上线(很少有这种问题 ) ; 1.2.2.3 持久化机制
交换机和队列的持久化机制保证服务器故障或重启后消息仍然存在
队列持久化交换机持久化消息持久化
12.2.4 消费时的确认模式
启动手动确认模式前面有提到。
只有当消费者确保业务运行成功后再确认接受消息。
12.2.5 集群、镜像队列保证高可用
设置rabbitMQ的集群设置镜像队列
十三、消息的幂等性 同一个消息第一次接收正常处理业务 如果同一个消息第二次接收那就不能再处理了否则就重复处理了。 13.1 概念
13.1.1 幂等性
概念对一个资源无论请求一次还是多次该数据本身造成的影响应该是相同的不能因为重复的请求而造成资源重复造成影响。
个人理解有点类似数据库的一致性
13.1 举例:接口幂等性
接口幂等性是指一个接口用同样的参数反复调用不会造成业务错误那么这个接口就是具有幂等性的
这些接口必须要要做幂等设计
注册接口多次请求注册也只能生成同一个新账号发送短信验证码接口多次请求也只发送一次短信比如同一个订单我支付两次但是只会扣款一次第二次支付不会扣款这说明这个支付接口是具有幂等性的;
13.2 数据库的幂等性
问sql语句中哪些语句是非幂等的
select多次查询结果一样幂等delete多次删除结果也是一样幂等update不进行计算的更新操作幂等insert除非指定id多次的插入会导致多条数据所以是非幂等的。
所以需要对insert的进行幂等操作比如数据库自带的约束。或者在插入前进行查询避免重复插入。
13.2 如何避免消息的重复消费问题消息消费时的幂等性
13.1 全局唯一id Redis
当生产者发送消息时设置一个全局唯一的messageId消费者拿到消息后使用redis的setnx指令存储messageId如果存储成功返回为1说明消息还为被处理如果返回为0则说明已经被处理过了。 关于SETNX SETNX 指令常用于实现分布式锁的场景通过尝试设置一个特定的键来获取锁如果设置成功则表示获取到了锁否则表示锁已经被其他客户端持有。 SETNX key value当执行 SETNX 指令时会按照以下步骤进行处理 如果键 key 不存在则设置键 key 的值为 value。如果键 key 已经存在则不进行任何操作返回 0。如果设置成功则返回 1。 13.3 ⭐️代码实现
13.3.1 环境准备 redis 项目依赖新增 spring-boot-starter-redis13.3.2 实例思路整理
生产者
模拟一个订单对象其中一个属性为订单id唯一发送两个订单他们的订单id相同模拟非幂等情况
消费者
开启手动确认模式spring.rabbitmq.listener.simple.acknowledge-mode manual正常监听队列接收到订单信息后将订单id存入redis判断redis的存储结果如果正常存入redis则确认接受信息并继续进行消费者业务。否则拒绝信息。
代码略
