Rabbitmq

1.RabbitMQ持久化机制

RabbitMQ持久化分为队列持久化、消息持久化和交换器持久化。不管时持久化的消息还是非持久化的消息都可以被写入到磁盘。

在这里插入图片描述

1.1 RabbitMQ队列持久化

队列持久化是定义队列时的durable参数来实现的,durable未true时,队列才会持久化。

在这里插入图片描述

1.2 RabbitMQ消息持久化

	消息持久化通过消息的属性deliveryMode来设置是否持久化,在发送消息时通过bascPublish的参数传入。

在这里插入图片描述

1.3 RabbitMQ交换器持久化

同队列一样,交换器也需要在定义时设置持久化标识,否则Broker重启后将丢失数据。
在这里插入图片描述
在这里插入图片描述
RabbitMQ内存告警
当内存使用超过配置的阈值或者磁盘剩余空间低于配置的阈值时,RabbitMQ会暂时阻塞客户端的连接,并停止接收客户端发来的消息,以此避免服务崩溃,客户端与服务端的心跳检测也会失效。
在这里插入图片描述
RabbitMQ内存控制
当出现内存告警时,可以通过管理命令临时调整内存大小
rabbitmqctl_set_vm_memory_high_watermark
faction为内存阈值,RabbitMQ默认值为0.4,标识当RabbitMQ使用内存超过40%时,就会产生告警并阻塞所有生产者连接。
通过此命令修改的阈值在Broker重启后将会失效,通过修改配置文件的方式设置的阈值则不会在重启Broker才会生效。
RabbitMQ内存换页
在某个Broker节点触及内存并阻塞生产者之前,它会尝试将队列中的消息页到磁盘以释放内存空间。持久化和非持久化的消息都会被转储到磁盘中,其中持久化的消息本身就在本身就在磁盘中有一份副本,这里会将持久化的消息从内存中清除掉。
默认情况下,在内存到大内存阈值的50%时会进行换页动作也就是说,在默认的内存阈值为0.4的情况下,当内存超过0.4*0.5=0.2时会进行换页动作。
可以通过在配置文件中配置vm_memory_high_watermark_paging_ratio项来修改此值。
vm_memory_high_watermark_relative=0.4
vm_memory_high_watermark_paing_radio=0.75

RabbitMQ磁盘告警
当磁盘剩余空间低于确定的阈值时,RabbitMQ同样会阻塞生产者,这样可以避免因非持久化的消息持续换页而耗尽磁盘空间导致服务崩溃。

	默认情况下,磁盘阈值为50MB,表示当磁盘剩余空间低于50MB时会阻塞生产者并停止持久化的消息持续换页而耗尽磁盘空间导致服务崩溃。
	这个阈值的设置可以减小,但不能完全消除因磁盘耗尽而导致崩溃的可能性。比如在两次磁盘空间检查期间内,磁盘空间从大于50MB被耗尽到0MB。

RabbitMQ磁盘限制
通过命可以临时调整磁盘阈值
rabbitmqctlset_disk_free_limit<disk_limit>
rabbitmqctlset_disk_free_limit_mem_relative
disk_limit为固定大小,单位为KB、MB、GB
fraction为相对比,建议的取值为1.0~2.0之间
对应的配置如下:

在这里插入图片描述在这里插入图片描述

1.4 RabbitMQ消息可靠性

RabbitMQ消息可靠性,一般时业务系统接入消息中间件时首要考虑的问题,一般通过三个方面保障
**发送可靠性**:确保消息成功发送到Broker
**存储可靠性**:Broker对消息持久化,确保消息不会丢失
**消息可靠性**:确保消息成功被消费
1.4.1 RabbitMQ消息发送可靠性

一般消息发送可靠性分为三个层级

  1. At more once:最多一次,消息可能会丢失,但绝不会重复传输
  2. At least once:最少一次,消息绝不会丢失,但可能会重复传输
  3. Exactly once:恰好一次,每条消息肯定会被传输一次且仅传输一次。

RabbitMQ支持其中的“最多一次”和“最少一次”
其中最少一次 投递实现需要考虑以下这几个方面的内容:

  • 消息生产者需要开启事务机制或者publisher confirm机制,以确保消息可以可靠地传输到RabbitMQ中。
  • 消息生产者需要配合使用andatory参数或者备份交换来确保消息能够从交换器路由到队列中进而能够保存下来而不会被丢弃。
  • "最多一次"的方式就无须考虑以上那些二方面,生产者随意发送,不过这样很难确保消息会发送成功。

在这里插入图片描述

1.4.2 RabbitMQ消息消费可靠性

消费者在消费消息的同时,需要将autoAck设置为false,然后通过手动确认的方式去确认已经正确消费的消息,以免在消费端引起不必要的消息丢失。

在这里插入图片描述

2. RabbitMQ常用插件

  1. rabbitmq_auth_mechanism_ssl
    身份验证机制插件,允许RabbitMQ客户端使用509证书和(pki)证书进行身份验证
  2. rabiitmq_event_exchange
    事件分发插件,使客户端可以接收到Broker的queue.deleted 、exchage.creared、 binding.created等事件
  3. rabbitmq_management
    基于web界面的管理/监控插件

3. 基于MQ的分布式事务解决方案

RabbitMQ时一款分布式消息中间件,基于erlang语言开发,具备语言级别的高并发处理能力。和Spring框架是同一家公司。支持持久化、高可用
核心5个概念:

  1. Queue:真正存储数据的地方
  2. Exchange:接收请求,转存数据
  3. Bind:收到请求后存储到哪里
  4. 消息生产者:发送数据的应用
  5. 消息消费者:取出数据处理的应用

在这里插入图片描述
在这里插入图片描述

  • 基于数据库XA/JTA协议的方式:需要数据库厂商支持;java组件有atomikos等;(需要数据库厂商支持;JAVA组件有atomikos等)

  • 异步校对数据的方式;(支护宝、微信支付状态、对账单的形式)

  • 基于可靠消息(MQ)的解决方案;(异步场景;通用性较强;扩展性较高)

  • TCCb编程式的解决方案(严选、阿里、蚂蚁金服自己封装的DTX)

下面是美团点评系统架构:
在这里插入图片描述

多系统间的分布式事务问题如下图:
在这里插入图片描述

在这里插入图片描述

3秒钟认为超时了,调用接口认为失败。其实还在运行。
在这里插入图片描述
使用RabbitMQ消息中间件的整体思路:

在这里插入图片描述
步骤一可靠消息生产-记录消息发送如下图发送数据到Rabbit消息中间件
在这里插入图片描述
为确保数据一定成功发送到MQ可在同一事务中添加一个记录表操作
如下图:
在这里插入图片描述

在这里插入图片描述

在这里插入图片描述
步骤二修改发送状态如下图:
未发送
在这里插入图片描述
已发送:
在这里插入图片描述
在这里插入图片描述

步骤四处理失败消息
在这里插入图片描述

4. 优点和缺点

优点

  1. 通用性强
  2. 拓展性强
  3. 方案成熟

缺点
1、基于消息中间件,只适合异步场景;
2、消息处理会延迟,需要业务上能够容忍;

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值