河南省建设工程标准定额管理网站试玩平台wordpress

河南省建设工程标准定额管理网站,试玩平台wordpress,网站开发原创动漫,做暧暧网站在线前言#xff1a;一、消息队列的背景技术基础#xff1a;由阻塞队列#xff08;BlockingQueue#xff09;封装而来#xff0c;核心用于实现生产者消费者模型。模型价值#xff1a;解耦合#xff1a;降低系统模块间的依赖削峰填谷#xff1a;缓冲流量波动#xff0c;保障…前言一、消息队列的背景技术基础由阻塞队列BlockingQueue封装而来核心用于实现生产者消费者模型。模型价值解耦合降低系统模块间的依赖削峰填谷缓冲流量波动保障系统稳定性分布式场景适配跨主机通信的常见需求因此将阻塞队列封装为独立服务程序即 “消息队列”。BlockingQueue 是 “单机工具”RabbitMQ 是 “分布式中间件”后者把前者的核心思想扩展到了跨主机、多实例的场景。主流消息队列常见的成熟产品包括RabbitMQ、Kafka、RocketMQ、ActiveMQ 等其中RabbitMQ因功能强、应用广而知名文档后续拟模拟实现其简易版本。补充说明消息队列是后端开发尤其是分布式系统的核心中间件不同产品有不同特性RabbitMQ轻量、支持多协议适合中小型系统Kafka高吞吐、高可靠适合大数据 / 日志场景RocketMQ高可用、低延迟适合金融级业务二、RabbitMQ 最核心的价值解耦 故障隔离 快速容灾1. 无 RabbitMQ直连的致命问题服务器生产者↔客户端消费者直接建立TCP连接连接耦合双方必须硬编码对方的 IP / 端口换主机就要改配置、重启服务效率极低故障传导一方死机比如服务器崩了另一方会因连接中断直接卡死比如客户端一直等服务器数据最终超时崩溃消息丢失没有中间缓存服务器发的消息如果客户端没及时接收直接丢失无法恢复2. 有 RabbitMQ三者的职责划分核心是 “中间件扛下所有复杂工作”具体分工如下角色核心工作只做 “极少的核心事”故障时的容灾逻辑新主机快速接入生产者服务器1. 处理自身核心业务如生成订单、产生日志。2. 按约定格式把消息发给 RabbitMQ。3. 确认 MQ 收到消息即可无需管 “谁来消费”。新服务器启动后只需用原配置连接 RabbitMQ继续发消息即可 —— 不用管消费者在哪、是否换主机消息会暂存在 MQ 里。中间人RabbitMQ1. 接收并持久化存储生产者的消息避免丢失。2.维护所有生产者 / 消费者的连接心跳检测、断线重连。3. 按规则把消息路由到订阅的消费者。4.提供 ACK 确认机制确保消息被消费才删除。生产者 / 消费者死机后MQ 会保留未消费的消息新主机接入时直接复用原连接规则读取未消费消息即可。消费者客户端1. 向 RabbitMQ 订阅指定队列。2. 从MQ 拉取消息处理自身核心业务如推送订单、写入数据库。3. 处理完给 MQ 发 “ACK 确认”。新客户端启动后只需订阅原队列就能立刻拿到MQ 中未消费的消息—— 不用管生产者是谁、是否换主机直接复用原逻辑。假设电商场景服务器生产者生成订单消息客户端消费者接收消息并推送短信。场景 1客户端死机无 MQ服务器发的订单消息直接丢失用户收不到短信有 MQ订单消息暂存在 RabbitMQ 的队列里新客户端启动后直接从 MQ 拉取这些消息推送短信服务器全程无感知。场景 2服务器死机无 MQ客户端因收不到数据一直阻塞等待最终崩溃有 MQ新服务器启动后继续往 MQ 发新的订单消息客户端只需正常从 MQ 取消息无需做任何配置修改。关于RabbitMQ疑惑的讲解疑惑 1RabbitMQ 是如何 “匹配” 生产者和消费者的核心队列是唯一桥梁无直接配对RabbitMQ 的核心设计是「生产者面向队列发消息消费者面向队列取消息」生产者和消费者之间没有任何直接关联全靠 “队列” 作为中间载体流程如下提前约定定义队列核心开发阶段先在 RabbitMQ 中创建好队列比如叫order_queue并约定所有订单相关的生产者都把消息发到order_queue所有处理订单的消费者都订阅order_queue。生产者发消息只认队列不认消费者生产者的逻辑只有处理核心业务生成订单→ 按格式封装消息 → 发送到order_queue→ 确认 MQ 收到即可。 它完全不用管有没有消费者在监听order_queue有多少个消费者在监听消费者是哪台机器、哪个程序。MQ 的工作只管队列的消息存储和投递MQ 收到生产者发往order_queue的消息后如果此时有消费者订阅了order_queue→ 立刻把消息推 / 拉给消费者如果此时没有消费者 → 把消息持久化到磁盘暂存直到有消费者订阅该队列再投递。消费者取消息只认队列不认生产者消费者的逻辑只有启动后订阅order_queue→ 从队列拉 / 收消息 → 处理业务比如推送短信→ 给 MQ 发 ACK 确认。它完全不用管消息是哪个生产者发的生产者是否还在线生产者的 IP / 端口 / 格式只要消息本身的格式是约定好的。总结生产者和消费者的 “匹配”本质是 “都对准同一个队列”而非 MQ 主动给他们建立关系MQ 只做 “队列的管家”不做 “配对的红娘”。疑惑 2生产者和 MQ 的消息格式、消费者和 MQ 的格式是独立的吗结论消息的 “业务格式” 是生产者和消费者提前约定的MQ 只做 “透传”MQ 和生产 / 消费方的 “通信格式”协议层是统一的但和业务格式无关。拆解成两层理解协议层格式MQ 与生产 / 消费方的交互规则RabbitMQ 基于 AMQP 协议或 MQTT 等生产者向 MQ 发消息、消费者从 MQ 取消息都必须遵守 AMQP 的协议格式比如消息的头部、属性、体结构—— 这层格式是统一的生产 / 消费方都要适配 MQ 的协议否则无法通信。比如生产者用 Java 的 RabbitMQ 客户端发消息必须按 AMQP 格式封装消费者用 Python 的 RabbitMQ 客户端取消息也必须按 AMQP 格式解析这层是 “MQ 规定的统一格式”。业务层格式消息的内容消息体里的内容比如订单的 JSON 串{orderId:123,amount:99}是生产者和消费者提前约定的MQ 完全不关心、也不解析这部分内容只做透传。举个例子生产者Java按约定把订单信息转成 JSON封装到 AMQP 消息的 “体” 中发给 MQMQ 收到后只存储 “AMQP 格式的消息”不会解析 JSON 内容消费者Python从 MQ 拿到 AMQP 消息后解析出消息体的 JSON按约定格式处理 —— 这里的 JSON 格式是生产 / 消费方约定的和 MQ 无关。结论协议层格式生产 / 消费方都要适配 MQ统一业务层格式生产 / 消费方互相约定MQ 不参与不存在 “生产者和 MQ 的业务格式、消费者和 MQ 的业务格式独立” 的情况 —— 业务格式是生产 / 消费方的约定MQ 只负责传不参与定义。疑惑 3是否必须 “有生产者就有消费者”会不会存在 “只有生产者、没有消费者” 的情况结论不一定必须同时存在“只有生产者、没有消费者” 是常见场景是 MQ 的核心价值削峰填谷、异步处理的体现。举 3 个真实业务场景说明 “只有生产者、暂时无消费者” 的合理性削峰场景秒杀订单秒杀活动时1 分钟内产生 10 万条订单消息生产者疯狂发消息但消费者的处理能力只有每秒 100 条 —— 此时 MQ 会先把 9 万多条消息暂存消费者慢慢处理不会因为 “消费者处理不过来” 导致生产者阻塞或消息丢失。这个过程中“生产者发消息的速度远大于消费者处理速度”相当于“暂时只有生产者在发消费者跟不上”但MQ 的暂存能力解决了这个问题。异步处理场景日志收集服务器生产者24 小时产生日志消息发给 MQ 的log_queue但日志分析程序消费者只在凌晨 3 点启动此时服务器负载低一次性消费所有日志。这个过程中白天只有生产者发消息MQ 暂存所有日志凌晨消费者才开始处理—— 消息不是 “虚假的”而是等待合适的时机被消费。容灾场景消费者宕机消费者集群突然全部死机生产者仍在正常发消息比如订单消息MQ 会把消息持久化到磁盘等几小时后消费者集群重启立刻消费所有暂存的消息—— 这个过程中“一段时间内只有生产者没有消费者”但消息不会丢失业务能恢复。类比理解把 RabbitMQ 想象成 “快递柜”生产者 寄件人把快递消息放进快递柜队列放完就走不管谁来取消费者 收件人凭取件码订阅队列取快递不管谁寄的快递柜MQ 暂存快递不管寄件人走没走、收件人来没来先把快递存好。寄件人早上放快递收件人晚上取完全没问题快递柜的价值就是 “暂存 解耦”不是 “必须寄件人和收件人同时在场”。关键结论生产者和消费者只认队列不认对方完全解耦MQ 的角色队列管家只负责暂存、投递消息不做 “配对”“解析业务格式”消息格式协议层适配 MQ统一业务层生产 / 消费方约定MQ 透传生产 / 消费方是否同时存在不需要MQ 的暂存能力就是为了应对 “不同时存在” 的场景这是它的核心价值。RabbitMQ 的消息路由链路是生产者 → 交换机 → 队列 → 消费者生产者把消息发给「交换机」并携带「路由键Routing Key」交换机根据自身类型 路由键把消息转发到「一个 / 多个队列」消费者只订阅队列不直接和交换机交互。交换机的核心作用是「消息路由分发」而非直接对接消费者。交换机的 3 种核心类型类型核心路由规则典型场景Direct直连消息的路由键 队列绑定键 → 转发到该队列一对一精准路由如订单 ID 匹配Fanout扇出忽略路由键把消息转发到所有绑定的队列广播如日志同时发往存储 告警Topic主题路由键按通配符匹配队列绑定键 → 转发多维度路由如按地区 / 业务类型分发疑惑4高频消息场景如何适配交换机 / 队列高频消息的优化核心是「队列拆分」第一步按业务维度拆分交换机比如把 “全量订单交换机” 拆成 “秒杀订单交换机”“普通订单交换机”第二步交换机下绑定多个队列比如seckill_order_queue_1、seckill_order_queue_2用相同路由规则分发第三步多个消费者分别订阅不同队列负载均衡。举例秒杀场景下1 个seckill_exchangeDirect 类型绑定 10 个队列生产者发消息到该交换机交换机把消息均匀分发到 10 个队列10 个消费者各消费 1 个队列 —— 通过 “队列水平拆分” 扛高频而非修改交换机标识。业务消息的流向是「生产者 → 交换机 → 队列 → 消费者」消费者不会主动发 “业务消息” 反向给生产者 / MQ比如不会把 “处理完成” 的业务数据再发回给生产者。补充例外非业务消息不影响核心流向消费者会给 MQ 发「控制类指令」但不是 “倒着走的业务消息”比如ACK 确认告诉 MQ“这条消息我处理完了你可以删了”NACK/Reject告诉 MQ“这条消息处理失败你重新投递 / 丢弃”取消订阅告诉 MQ “我不再消费这个队列了”。这些指令是 “消费者对 MQ 的反馈”不是 “反向的业务消息”不会改变 “生产者→消费者” 的核心流向。疑惑5MQ 暂存的消息长时间未消费如何处理持久化消息的销毁规则RabbitMQ 不会 “无限期暂存消息”持久化消息的销毁 / 清理有明确规则核心分「主动配置」和「被动触发」两类第一步先明确 “持久化” 的本质RabbitMQ 的持久化分两层交换机 / 队列持久化重启 MQ 后交换机 / 队列的定义不会消失消息持久化消息被写入磁盘而非仅存内存MQ 重启后消息不丢失。持久化只是 “保证消息不丢”不是 “永久保存”—— 需要手动 / 自动配置销毁规则。第二步长时间未消费的消息如何销毁核心配置 1消息过期时间TTL—— 自动销毁可以给「队列」或「单个消息」设置 TTLTime-To-Live过期时间队列 TTL给队列设置x-message-ttl比如 60 秒所有进入该队列的消息超过 60 秒未被消费自动被 MQ 删除消息 TTL生产者发消息时给单个消息设置过期时间比如 10 分钟仅该消息过期后删除场景比如 “订单支付超时提醒”消息超过 30 分钟未消费说明订单已支付 / 关闭直接销毁无需保留。核心配置 2死信队列DLQ—— 过期 / 失败消息的 “兜底处理”不想直接销毁过期消息可以配置死信队列给普通队列绑定「死信交换机 死信队列」消息过期 / 被拒绝 / 队列满时不会直接销毁而是转发到死信队列死信队列的消息可单独处理比如人工排查也可给死信队列设置 TTL最终销毁。核心配置 3队列最大长度 / 最大字节数 —— 自动淘汰给队列设置x-max-length最大消息数或x-max-length-bytes最大字节数比如队列最多存 10 万条消息超过后MQ 会按 “先进先出” 删除最早的消息场景高频日志队列只保留最近 1 小时的日志超过后自动淘汰旧消息。被动触发消费者 ACK 确认 —— 处理完成后销毁这是最基础的销毁规则消费者处理完消息后发 ACK 确认 → MQ 立刻删除该消息无论是否持久化如果消费者没发 ACK 就宕机MQ 会把消息重新投递直到被消费确认或触发上述过期 / 队列满规则。手动销毁管理指令 / 控制台删除可通过 RabbitMQ 控制台、CLI 命令如rabbitmqctl purge_queue手动清空队列的消息或删除整个队列消息也会被删除。总结持久化消息不会 “永久保存”默认情况下若未配置 TTL / 队列长度消息会一直存到被消费或 MQ 磁盘满实际业务中必须给队列 / 消息设置 TTL避免 “僵尸消息” 占满磁盘高频场景还会结合死信队列既保证重要消息不丢又避免无用消息堆积。