百度收录新网站厦门市建设局网站摇号

百度收录新网站,厦门市建设局网站摇号,如何用ps做网站页面设计,wordpress调用搜索功能RabbitMQ架构与集群模式详解 前言 假设你维护了两个服务 A 和 B。A 服务负责转发用户请求到 B 服务#xff0c;B 服务是个算法服务#xff0c;GPU 资源有限。当请求量大到 B 服务处理不过来的时候#xff0c;希望能优先处理会员用户的请求。怎么实现#xff1f;答案是 Ra…RabbitMQ架构与集群模式详解前言假设你维护了两个服务 A 和 B。A 服务负责转发用户请求到 B 服务B 服务是个算法服务GPU 资源有限。当请求量大到 B 服务处理不过来的时候希望能优先处理会员用户的请求。怎么实现答案是 RabbitMQ 的优先级队列。本文将带你深入了解 RabbitMQ 的核心概念和集群架构。个人主页你的主页文章目录RabbitMQ架构与集群模式详解一、RabbitMQ核心概念二、RabbitMQ的特色功能三、单节点的问题四、普通集群模式五、镜像队列集群模式六、Quorum队列模式七、集群模式对比与选型八、总结一、RabbitMQ核心概念1.1 Queue队列消息队列本质上就是一个类似链表的独立进程链表里的每个节点是一条消息。生产者 → [消息1] → [消息2] → [消息3] → 消费者 ↑ 这就是 QueueQueue 的作用是什么削峰填谷。在流量高峰时先暂存数据再慢慢消费保护下游服务不被打垮。打个比方Queue 就像银行的叫号系统客户来了先取号排队柜员按顺序处理不会因为人多就手忙脚乱。但消息也分很多种类比如订单消息和用户消息是两类。为了更好地管理不同种类的数据RabbitMQ 支持创建多个队列RabbitMQ ├── order-queue → 订单消息 ├── user-queue → 用户消息 └── payment-queue → 支付消息每个 Queue 都是独立的进程某个进程挂了不影响其他进程正常工作。1.2 Exchange交换器有了多个队列新的问题来了有些生产者想把消息发到一个Queue有些想发到多个Queue有些想广播给所有 Queue怎么实现这种灵活的路由答案是Exchange交换器。Exchange 是消息的路由中心生产者不直接发消息给 Queue而是发给 Exchange由 Exchange 根据规则分发到对应的 Queue。生产者 → Exchange → Queue-1 ↘ → Queue-2 ↘ → Queue-3Exchange 和 Queue 之间通过Binding Key绑定键建立绑定关系类似正则表达式声明什么样的消息发到哪个队列。四种 Exchange 类型类型路由规则场景Direct精确匹配 Routing Key点对点一对一Fanout广播给所有绑定的队列广播通知Topic通配符匹配*和#灵活路由Headers根据消息头匹配复杂路由少用举个例子# Topic Exchange 示例 Routing Key: order.created → 匹配 order.* → 发到订单队列 Routing Key: order.paid → 匹配 order.* → 发到订单队列 Routing Key: user.login → 匹配 user.* → 发到用户队列1.3 Broker一台服务器上的 RabbitMQ 实例就是一个Broker。BrokerRabbitMQ 实例 ├── Exchange-1 ├── Exchange-2 ├── Queue-1 ├── Queue-2 └── Queue-3Broker 里维护的路由规则和绑定关系统称为元数据Metadata。1.4 整体架构图┌─────────────────────────────────────────────────────────┐ │ Broker │ │ ┌──────────┐ │ │ │ Exchange │──bindingKey──→ Queue-1 ──→ Consumer-1 │ │ │ │──bindingKey──→ Queue-2 ──→ Consumer-2 │ │ └──────────┘──bindingKey──→ Queue-3 ──→ Consumer-3 │ │ ↑ │ └───────│─────────────────────────────────────────────────┘ │ Producer二、RabbitMQ的特色功能RabbitMQ 功能非常丰富你能想到的 MQ 功能它基本都实现了。2.1 延迟队列场景用户下单后 30 分钟未支付自动取消订单。RabbitMQ 通过死信队列 TTL或者延迟插件实现延迟消息。订单创建 → 延迟队列30分钟后投递 → 检查支付状态 → 未支付则取消2.2 死信队列消息在以下情况会变成死信消息被拒绝reject/nack且不重新入队消息过期TTL 到期队列达到最大长度死信会被转发到专门的死信队列DLX方便后续排查和处理。2.3 优先级队列重点这是 RabbitMQ 的特色功能也是开头问题的解决方案。原理生产者发送消息时可以为消息标记优先级0-255消费者总是优先消费优先级高的消息。// 声明优先级队列最大优先级为 10MapString,ObjectargsnewHashMap();args.put(x-max-priority,10);channel.queueDeclare(priority-queue,true,false,false,args);// 发送高优先级消息会员用户AMQP.BasicPropertiespropsnewAMQP.BasicProperties.Builder().priority(9)// 高优先级.build();channel.basicPublish(,priority-queue,props,VIP用户请求.getBytes());// 发送低优先级消息普通用户AMQP.BasicPropertiesprops2newAMQP.BasicProperties.Builder().priority(1)// 低优先级.build();channel.basicPublish(,priority-queue,props2,普通用户请求.getBytes());回到开头的场景用户请求 → A服务根据会员等级设置优先级 → RabbitMQ → B服务GPU算法服务 ↓ 优先消费高优消息会员用户的请求优先级设为 9普通用户的请求优先级设为 1B 服务永远优先处理会员请求处理完后再处理普通请求实际应用现在到处都是 AI恨不得把一块 GPU 掰成 10 块用。比如某聊天 AI当服务遭到大量访问时免费用户会感觉很慢甚至报错但会员用户依旧响应丝滑。背后很可能就是优先级队列在起作用。三、单节点的问题虽然 RabbitMQ 功能很丰富但它的基础架构就是个单实例节点存在明显问题问题说明单点故障Broker 挂了整个服务不可用性能瓶颈单节点处理能力有限无法扩展流量增长时没法水平扩容怎么解决上集群。四、普通集群模式4.1 架构设计多个服务器各部署一个 RabbitMQ 实例通过 RabbitMQ 提供的命令组成集群。┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Broker-1 │ │ Broker-2 │ │ Broker-3 │ │ ┌───────┐ │ │ ┌───────┐ │ │ ┌───────┐ │ │ │ Q1 │ │ │ │ Q2 │ │ │ │ Q3 │ │ │ └───────┘ │ │ └───────┘ │ │ └───────┘ │ │ Exchange │←──→│ Exchange │←──→│ Exchange │ │ (元数据同步) │ │ (元数据同步) │ │ (元数据同步) │ └─────────────┘ └─────────────┘ └─────────────┘关键特点每个 Broker 都是完整功能的 RabbitMQ 实例都能进行读写Broker 之间会互相同步 Exchange 里的元数据但不会同步 Queue 里的数据4.2 读写流程写操作生产者 → Broker-1 → Q1数据只存在 Broker-1 ↓ 元数据同步到 Broker-2、Broker-3Q1 里的消息数据不会同步给其他 Broker但 Exchange 的元数据会同步。读操作情况一消费者访问 Q1 所在的 Broker-1消费者 → Broker-1 → Q1 → 直接返回数据 ✅情况二消费者访问 Broker-2但 Q1 在 Broker-1消费者 → Broker-2 → 查元数据发现 Q1 在 Broker-1 ↓ 从 Broker-1 读取数据 → 返回给消费者4.3 优缺点优点缺点提升整体吞吐量单个 Queue 的读写能力没提升支持水平扩展每个 Broker 仍有单点问题部署简单Queue 所在 Broker 挂了该 Queue 就不可用结论普通集群模式提升了扩展性但没有解决高可用问题。五、镜像队列集群模式5.1 设计思路既然单个 Queue 有单点问题那就给它加几个副本。打个比方就像你手机里存了很多重要照片为了防止手机丢了照片没了你会把照片备份到云盘。镜像队列就是给 Queue 做备份。5.2 架构设计┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Broker-1 │ │ Broker-2 │ │ Broker-3 │ │ ┌───────┐ │ │ ┌───────┐ │ │ ┌───────┐ │ │ │Q1(主) │──────→│ Q1(镜像)│──────→│ Q1(镜像)│ │ │ └───────┘ │ │ └───────┘ │ │ └───────┘ │ │ │ │ ┌───────┐ │ │ │ │ │ │ │Q2(主) │ │ │ │ │ │ │ └───────┘ │ │ │ └─────────────┘ └─────────────┘ └─────────────┘主队列Master负责读写数据镜像队列Mirror负责同步复制主队列数据主队列所在的 Broker 挂了镜像队列可以顶上成为新的主队列5.3 读写流程写操作生产者 → Broker-1 → Q1(主) ↓ 同步 Q1(镜像)Broker-2、Q1(镜像)Broker-3数据写入主队列后会同步到所有镜像队列。读操作情况一消费者访问主队列所在的 Broker消费者 → Broker-1 → Q1(主) → 直接返回数据 ✅情况二消费者访问其他 Broker消费者 → Broker-2 → 从 Broker-1 的 Q1(主) 读取 → 返回数据注意即使 Broker-2 上有 Q1 的镜像读操作也是从主队列读取镜像只用于故障转移。5.4 故障转移Broker-1 挂了 ↓ Q1(镜像)Broker-2 自动升级为 Q1(主) ↓ 服务继续可用 ✅5.5 优缺点优点缺点实现高可用牺牲吞吐量数据要同步多份自动故障转移网络带宽消耗大数据不丢失同步延迟可能导致数据不一致结论镜像队列模式通过牺牲吞吐量换取高可用。六、Quorum队列模式6.1 镜像队列的问题RabbitMQ 基于Erlang语言开发。Erlang 是个很特别的语言自带虚拟机和分布式通信框架。RabbitMQ 通过这个框架在 Broker 间同步元数据。但有个问题如果 Broker 间通信断开网络分区可能出现多个节点都认为自己是主节点的情况导致数据不一致。这就是所谓的脑裂问题。打个比方公司有三个办公室平时通过内网通信。突然网络断了每个办公室都以为自己是总部各自做决策等网络恢复后发现决策冲突了。6.2 Quorum 队列的解决方案RabbitMQ 3.8 版本引入了Quorum 队列使用Raft 一致性算法来解决脑裂问题。Raft 算法核心思想集群中只有一个 Leader其他都是 Follower任何写操作必须经过多数节点Quorum确认才算成功Leader 挂了通过选举产生新 Leader┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Broker-1 │ │ Broker-2 │ │ Broker-3 │ │ ┌───────┐ │ │ ┌───────┐ │ │ ┌───────┐ │ │ │Q1 │ │ │ │Q1 │ │ │ │Q1 │ │ │ │(Leader)│←────→│ (Follower)│←────→│ (Follower)│ │ │ └───────┘ │ │ └───────┘ │ │ └───────┘ │ └─────────────┘ └─────────────┘ └─────────────┘ ↑ Raft 选举写入流程1. 生产者发送消息到 Leader 2. Leader 将消息复制给 Follower 3. 超过半数节点确认后Leader 返回成功 4. 如果 Leader 挂了剩余节点选举新 Leader6.3 为什么 Quorum 能解决脑裂假设 3 个节点网络分区后变成 1 2 两个分区1 个节点的分区无法获得多数票需要 2 票不能选出 Leader停止服务2 个节点的分区可以获得多数票选出 Leader继续服务这样就保证了任何时刻最多只有一个 Leader避免了脑裂。6.4 Quorum 队列 vs 镜像队列特性镜像队列Quorum 队列一致性算法无简单同步Raft脑裂处理可能脑裂不会脑裂数据一致性最终一致强一致性能较高略低需要多数确认推荐场景对一致性要求不高对数据一致性要求高七、集群模式对比与选型7.1 三种模式对比模式高可用高吞吐数据一致性复杂度普通集群❌✅-低镜像队列✅❌最终一致中Quorum队列✅❌强一致中7.2 选型建议选普通集群对高可用要求不高追求高吞吐量消息丢失可以接受选镜像队列需要高可用对数据一致性要求不是特别严格RabbitMQ 版本低于 3.8选 Quorum 队列需要高可用对数据一致性要求高RabbitMQ 版本 3.8金融、支付等关键业务7.3 RabbitMQ vs Kafka vs RocketMQ特性RabbitMQKafkaRocketMQ定位企业级消息中间件大数据流处理业务消息中间件协议AMQP自定义自定义优先级队列✅ 原生支持❌❌延迟队列✅❌✅死信队列✅❌✅事务消息✅⚠️ 仅发送端✅吞吐量万级十万级十万级适用场景复杂路由、企业集成日志、大数据电商、金融业务八、总结本文介绍了 RabbitMQ 的核心概念和集群架构概念说明Queue存储消息的队列独立进程Exchange消息路由中心根据规则分发消息BrokerRabbitMQ 实例元数据Exchange 里的路由规则和绑定关系三种集群模式模式核心思想普通集群同步元数据不同步队列数据提升吞吐镜像队列队列数据多副本牺牲吞吐换高可用Quorum队列Raft 算法强一致性解决脑裂核心结论做架构做到最后都是在做折中。普通集群牺牲高可用换吞吐镜像队列牺牲吞吐换高可用没有完美的方案只有适合的场景。热门专栏推荐Agent小册Java基础合集Python基础合集Go基础合集大数据合集前端小册数据库合集Redis 合集Spring 全家桶微服务全家桶数据结构与算法合集设计模式小册消息队列合集等等等还有许多优秀的合集在主页等着大家的光顾感谢大家的支持文章到这里就结束了如果有什么疑问的地方请指出诸佬们一起来评论区一起讨论希望能和诸佬们一起努力今后我们一起观看感谢您的阅读如果帮助到您不妨3连支持一下创造不易您们的支持是我的动力