网站平台系统建设方案,wordpress使用ip访问,升级wordpress 另一更新正在进行,短视频代运营方案策划书1.什么是Rabbit MQ#xff1f;
Rabbit MQ是一个开源的消息代理软件#xff0c;它实现了高级消息队列协议(AMQP);
基本概念
消息#xff1a;消息是在应用程序之间传递的数据单元。可以是简单的文本信息#xff0c;可以是复杂的对象。队列#xff1a;队列是消息的容器
Rabbit MQ是一个开源的消息代理软件它实现了高级消息队列协议(AMQP);
基本概念
消息消息是在应用程序之间传递的数据单元。可以是简单的文本信息可以是复杂的对象。队列队列是消息的容器用于存储消息。他就像一个等待处理的任务列表消息以先进先出的方式在队列中被处理。生产者消费者生产者是创建和发送消息的应用程序或组件。消费者则是接收和处理消息的应用程序。
功能特点
可靠性高Rabbit MQ使用持久化机制来确保消息不会丢失。消息可以被标记为持久化这样Rabbit MQ服务器重启后消息仍然可以被恢复。灵活的消息分发策略它支持多种消息分发模式。比如轮询模式多个消费者可以轮流从队列种获取消息确保每个消费者都能公平的处理消息还有直接分发模式根据消息特定的路由键(routing key)将消息发送到指定的队列被对应的消费者处理。支持多种协议除了AMQPRabbit MQ还支持其他消息协议比如STOMP,MQTT。使得它能够与多种不同类型的客户端和应用程序集成。集群和高扩展性Rabbit MQ可以构建集群来提供高可用和横向扩展性.通过在多个节点上部署Rabbit MQ可以实现故障转移。比如一个节点出现故障其他节点可以接管其工作确保消息系统的持续运行。
应用场景
异步处理在一些耗时的操作中比如文件上传后的数据处理等可以将任务消息发送到Rabbit MQ队列。消费者可以在后台异步处理这些任务而不会影响用户其他操作提高系统的响应速度。例如用户在一个社交平台上传了一张照片系统将照片转码任务放入 RabbitMQ 队列用户可以继续浏览其他内容同时转码任务在后台慢慢处理。流量削峰在高流量场景下比如电商系统促销期间订单量可能会突然暴增。通过将订单消息放入Rabbit MQ队列后端系统可以按照自己的处理能力从队列种获取消息进行处理避免后端系统被大量请求压垮。解耦系统组件当一个大型系统包含多个相互关联的子系统时RabbitMQ 可以用于解耦这些子系统。例如在电商系统中订单系统、库存系统、支付系统等之间通过消息队列进行通信。订单系统产生订单消息后发送到队列库存系统和支付系统作为消费者从队列中获取消息并进行相应的处理。这样各个子系统之间不需要直接相互调用降低了系统的耦合度便于系统的维护和扩展。
2.RabbitMQ的七种工作模式
RabbitMQ的七种工作模式
3.如何保证RabbitMQ的消息顺序性 单队列单消费者模式 原理将需要保证顺序的消息发送到同一个队列中并且让这个队列只有一个消费者进行消费。这样消息按照进入队列的顺序被消费者获取自然就保证了消息的顺序性。示例假设有一个订单处理系统订单的创建、支付、发货等消息是有严格顺序要求的。可以将这些和同一个订单相关的消息发送到名为 “订单队列” 的队列中并且只启动一个消费者来处理这个队列中的消息。缺点这种方式的性能和可用性相对较低因为单个消费者可能会成为性能瓶颈而且如果消费者出现故障消息处理就会中断。 拆分多个队列并保证顺序消费 原理根据业务规则将消息划分到不同的队列中每个队列中的消息都有顺序要求并且在每个队列上只配置一个消费者来保证顺序。示例在一个电商系统中对于不同类型的商品如电子产品、服装、食品的订单消息可以分别发送到 “电子产品队列衣服队列食物队列” 等不同的队列中。每个队列都有自己单独的消费者这样就可以在不同的商品类型内部保证订单消息的顺序。局限性需要对业务有很好的理解合理地划分队列并且当业务规则发生变化时可能需要重新调整队列的划分。 消息分组和局部顺序性保证 原理在消息中添加分组标识消费者根据分组标识来处理消息保证同一组内的消息顺序。在 RabbitMQ 中可以通过消息的属性或者消息体中的自定义字段来添加分组标识。示例假设有一个消息包含用户的操作记录如登录、浏览商品、添加购物车等。可以在消息体中添加一个用户 ID 作为分组标识。消费者接收到消息后先按照用户 ID 对消息进行分组然后在每个用户组内按照消息的顺序进行处理这样就可以保证每个用户的操作记录是按照顺序处理的。注意点消费者需要有额外的逻辑来进行分组和顺序控制增加了消费者的复杂性。同时在高并发情况下需要注意分组消息的存储和排序效率。 使用事务和消息确认机制结合 原理在生产者端使用事务来确保消息按照顺序发送到队列。在消费者端结合消息确认机制只有当一条消息处理完成并且符合顺序要求后才确认该消息然后再处理下一条消息。示例在生产者发送消息时开启一个事务将多条有顺序要求的消息依次发送到队列中。如果发送过程中出现问题事务可以回滚保证消息不会乱序发送。消费者在接收到消息后只有在正确处理完当前消息并且下一条消息符合顺序要求时才发送消息确认这样可以防止消息的无序消费。缺点使用事务会增加系统的开销影响性能并且需要仔细处理事务的边界和异常情况。 通过消息优先级辅助保证顺序性在一定程度上 原理RabbitMQ 支持消息优先级。如果消息有顺序要求可以为消息设置优先级按照优先级顺序发送和消费消息。不过这种方法不能完全保证顺序性只是在一定程度上辅助保证顺序。示例在一个新闻发布系统中对于重要新闻的更新消息如头条新闻可以设置较高的优先级其他普通新闻更新消息设置较低的优先级。在消费者端优先处理高优先级的消息并且在优先级相同的消息之间按照发送顺序进行处理这样可以在一定程度上保证重要新闻更新的顺序性。
4.如何保证消息消费时的幂等性(消息不被重复消费) 什么是消息的幂等性 幂等性是指对同一个操作的一次请求和多次重复请求对系统资源的影响是一致的。在消息消费场景中就是指无论消息被消费多少次对系统产生的最终效果和只消费一次是相同的。 利用数据库的唯一约束保证幂等性 原理当消息被消费时需要将消息的关键信息如消息 ID、业务唯一标识等插入到数据库中。如果数据库表中该字段设置了唯一约束那么当重复消息消费导致插入相同的标识时数据库会抛出异常通过捕获这个异常就可以避免重复消费。示例在一个用户注册系统中当接收到用户注册的消息时将用户的手机号码作为唯一标识插入到 “user_registration” 表中。如果消息重复消费第二次插入相同手机号码时会违反唯一约束此时就可以识别出这是重复消息不再进行实际的注册操作。注意点这种方法可能会影响数据库性能因为每次消息消费都涉及数据库操作。同时需要合理设计数据库表结构和唯一约束字段确保能够准确识别重复消息。 使用状态机实现幂等性 原理为业务流程设计一个状态机每个消息的消费会使业务状态发生变化。在消费消息时先检查当前业务状态是否符合消息消费的预期状态如果不符合则说明消息可能已经被消费过不再进行处理。示例在一个订单处理系统中订单有 “已创建”“已支付”“已发货”“已完成” 等状态。当消费支付消息时先检查订单状态是否为 “已创建”如果是则进行支付处理并将订单状态更新为 “已支付”如果订单状态不是 “已创建”则说明支付消息可能已经被处理过不再进行重复支付操作。局限性需要准确地设计和维护状态机状态转换规则复杂时可能会出现错误。并且当业务状态被其他因素如人工干预修改时可能会影响状态机的正常判断。 基于消息的唯一标识进行去重 原理消息本身通常有一个唯一的消息 ID或者可以在消息体中添加自定义的唯一标识。在消息消费者端维护一个已消费消息 ID 的集合可以是内存中的集合、缓存或者数据库存储当接收到消息时先检查消息 ID 是否在已消费集合中如果在则忽略该消息不在则进行消费并将消息 ID 添加到集合中。示例使用 Redis 的 Set 数据结构来存储已消费的消息 ID。在消息消费者中每次接收到消息时使用 Redis 的 SISMEMBER 命令检查消息 ID 是否在集合中。如果不在进行消息消费并使用 SADD 命令将消息 ID 添加到集合中。注意点需要考虑存储已消费消息 ID 的存储介质的性能和可靠性。如果使用内存存储当消费者重启时可能会丢失数据如果使用数据库存储会增加数据库的读写操作。同时对于高并发的场景需要注意存储和查询操作的效率。 通过消息确认机制实现幂等性结合消息中间件特性 原理在消息中间件如 RabbitMQ中消息消费成功后需要向中间件发送确认消息。如果消息没有被正确确认中间件可能会重新发送消息。在消费者端可以通过记录消息的消费状态和确认状态来避免重复消费。示例在消费者内部维护一个消息消费状态表记录消息 ID、消费状态未消费、已消费未确认、已确认等信息。当接收到消息时先检查消费状态如果是 “已确认” 则忽略该消息如果是 “未消费” 则进行消费并将状态更新为 “已消费未确认”在成功消费后发送确认消息给中间件并将状态更新为 “已确认”。复杂性这种方法需要消费者自己维护消息消费状态增加了消费者的复杂性。并且需要确保消息确认机制和消费状态更新的原子性避免出现不一致的情况。
5.如何保证RabbitMQ消息的可靠传输
生产者可靠发送 使用发送方确认模式publisher confirm 原理发送方确认模式是一种更高效的方式来确保消息发送的可靠性。当生产者开启这个模式后每发送一条消息RabbitMQ 服务器会返回一个确认ack消息给生产者。如果生产者没有收到确认消息就可以认为消息发送失败从而进行重试或其他错误处理。注意点虽然发送方确认模式比事务机制性能更好但在高并发场景下生产者需要合理处理确认消息避免因为等待确认而导致性能瓶颈。开启事务机制 原理在 RabbitMQ 中生产者可以使用事务来确保消息的可靠发送。开启事务后生产者发送消息的操作会被包含在一个事务块中。如果消息成功发送到队列事务就可以提交如果发送过程中出现任何问题如网络故障、队列不存在等事务可以回滚保证消息不会丢失。缺点事务机制会带来较大的性能开销因为它涉及到与 RabbitMQ 服务器的多次交互包括开启事务、提交或回滚事务等操作。
2.消息持久化
队列持久化 原理在 RabbitMQ 中可以将队列设置为持久化。持久化的队列会在 RabbitMQ 服务器重启后依然存在确保消息不会因为队列的丢失而丢失。当创建队列时将队列的属性设置为持久化durable true即可。消息持久化 原理除了队列持久化还需要将消息设置为持久化。这样当 RabbitMQ 服务器发生意外情况如断电、重启等时消息能够在服务器恢复后依然存在。在发送消息时将消息的属性设置为持久化MessageProperties.PERSISTENT_TEXT_PLAIN。局限性消息持久化会增加一定的性能开销因为 RabbitMQ 需要将消息写入磁盘来保证持久化。而且在极端情况下如磁盘损坏消息依然可能丢失。
3.消费者可靠接收
自动消息确认和手动消息确认 原理RabbitMQ 默认是自动消息确认模式消费者一旦接收到消息就会自动向 RabbitMQ 服务器发送确认消息然后消息就会从队列中删除。但这种方式可能会导致消息丢失例如消费者在处理消息的过程中出现故障。手动消息确认模式则可以让消费者在成功处理完消息后再发送确认消息这样可以确保消息不会丢失。消息预取QoS 原理通过设置消息预取Quality of ServiceQoS可以限制消费者一次接收的消息数量。这样可以防止消费者接收过多的消息而无法及时处理导致消息积压或者丢失。例如设置 QoS 为 1消费者一次只会接收一条消息只有在处理完这条消息并确认后才会接收下一条消息。
6.RabbitMQ的其他知识 重试机制 死信队列
