文档教程后端【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址https://gitcode.com/gh_mirrors/code/CodeGuide点击查看免费下载本篇文章围绕《大营销平台系统设计实现》营销服务第 22 节「用户行为返利入账」展开讲解用户行为返利rebate领域从需求设计、库表创建、聚合事务入账到 MQ 异步消息发送与失败任务兜底的完整落地过程。读完你可以掌握如何用 DDD 方式划分返利领域、如何用一个聚合对象实现返利订单与任务记录的原子入库、以及 MQ 发送失败时如何通过任务表补偿这同时也是面试中高频追问的分布式一致性问题。一、章节定位与本章诉求用户行为返利是《大营销平台系统》第二阶段营销服务中的一个独立领域模块位于整个抽奖/返利/积分流程的入口侧第 21 节完成了活动信息 API 的迭代与功能完善第 22 节本节负责把用户的行为动作转化为返利订单并异步通知下游第 23 节接收 MQ 消息完成返利结算给用户的活动账户充值额度。原文档第22节用户行为返利入账给出的本章诉求非常明确按照用户行为返利的需求设计创建相应的库表开发 rebate 返利领域提供返利订单创建接口。并在写入订单后发送 MQ 消息。后续则处理奖励入账。也就是说这一节要做四件事依据 用户行为奖励需求设计 创建返利相关库表开发独立的rebate返利领域对外提供返利订单创建接口接收用户行为触达信息在订单写入后发送 MQ 消息交由下游第 23 节完成奖励入账。本章难度评定为 ★★★☆☆难点不在于单个功能点的实现而在于聚合事务 MQ 异步 任务兜底这套组合设计的理解与落地。二、业务场景什么是用户行为返利用户行为返利User Behavior Rebate是一种非常日常的营销活动类型。文档中给出的例子很直观你在某个平台创建了新账号就会给你发一堆的开户优惠券这些都是日常的返利活动。这类返利的共同特点是由用户完成特定行为动作来触达奖励。原文档列举了常见的返利行为类型行为类型说明打卡 / 签到每日一次的行为动作本节主场景连签连续多日签到通常有额外奖励档位支付完成一笔支付后获得返利开户注册新账号后发放开户优惠交易 / 信贷 / 拉新交易达标、信贷行为、邀请新用户等本节在功能实现上主要落地的是日常日历签到行为但从领域设计上抽象了用户行为类型这个维度把打卡、签到、支付、开户、交易、信贷、拉新等各类任务都作为可扩展的配置项方便后续扩展。这一点与需求文档的设计意图一致——用户行为奖励需求设计 中明确提到用户的 2 个行为动作打卡/签到每天可完成一次另外一个动作是后续对接 openai 项目的时候来接收一个支付完成的消息触达发奖资格。发奖可以是抽奖资格也可以是给用户积分。积分部分后续实现。那么这里 openai 支付的对接和赠送积分的场景虽然要后续实现但在我们本次做的需求中要预留出设计否则后续就不好扩展了。也就是说一个用户行为动作对应奖励一种东西可以是我们前面定义出来的 sku一个 sku 配置了用户可使用的抽奖次数额度也可以是积分。本节以 sku 返利为主但库表与领域设计为积分返利预留了扩展点。三、业务流程聚合对象 事务入库 MQ 兜底原文档用一张业务流程图概括了本节的核心流程并给出了三个关键设计点1. 一个行为可能触发多种奖励按配置组装聚合对象一个用户行为可能会给多种奖励所以在接收到用户信息后会根据配置组装聚合对象。【聚合的目的就是为了做一个统一的事务】用户的某一个行为动作例如签到可能同时命中多条返利配置系统需要把这一行为产生的全部返利结果组装成一个聚合对象目的就是保证它们作为一个整体做一次事务性入库避免一条条写入导致的数据不一致。2. 聚合对象包含返利订单实体与 task 实体一个事务入库一个聚合对象中包含了返利的订单实体对象写入 task 的实体对象。它们是一个事务入库。这是整个设计最关键的一环返利订单记录和**MQ 发送任务记录task**在同一个数据库事务中落库。为什么 task 记录必须和业务订单同事务写入因为在分布式环境下数据库操作和 MQ 消息发送本身无法处于同一个事务中MQ 中间件不参与本地数据库事务一旦订单写库成功但消息发送失败就会造成订单存在、下游不知道的数据丢失。把 task 记录与订单同事务写入就为后续的消息补偿留下了依据。3. 发送 MQ 消息失败有任务兜底另外是发送 MQ 消息在完成入口动作后会直接发送 MQ 消息并且如果发送失败会有任务兜底。【这样是面试中经常问到的点如果 MQ 消息发送失败了你是怎么处理的。】完整流程可以概括为用户行为动作签到/支付等 │ ▼ 根据返利配置组装聚合对象返利订单实体 task 实体 │ ▼ 同一数据库事务入库返利订单 任务记录 │ ▼ 发送 MQ 消息返利入账消息 │ ├── 成功 → 更新 task 状态为已发送 │ └── 失败 → 保留 task 未发送状态由任务扫描补偿兜底四、返利领域建模与库表设计4.1 DDD 领域边界从 DDD 建模的视角看返利是一个独立的领域。在 《架构DDD 领域驱动设计》 的四色建模规范中蓝色 - 决策命令用户发起的行为动作如开始签到、开始抽奖黄色 - 领域事件过去时态描述如签到完成、抽奖完成。签到返利的建模路径就是用户发起签到决策命令 → 触发签到完成领域事件 → 返利领域根据配置组装返利订单 → 写入任务记录。从系统建模可以细分出返利、活动、策略、奖品等领域其中兑换可以是单独的领域也可以合并到返利实现见 system-design-diagram.md。4.2 库表设计思路原文档明确要求创建相应的库表。结合 用户行为奖励需求设计 可以推断返利领域至少需要两类核心表返利配置表描述行为类型 → 奖励内容的映射关系奖励内容关联 skusku 上配置了可用的抽奖次数额度并预留积分等奖励类型的扩展字段返利订单表记录每次用户行为触达产生的返利订单即返利记录作为后续结算和幂等判断的依据。需要说明的是返利订单表承担了幂等校验的职责。面试问题汇总notes.md中专门提到过这个设计RabbitMQ 判断重复消费的逻辑是直接在数据库中查询返利记录表是否有相同的订单 ID 的记录如果发现重复就不消费。这也印证了返利订单表需要包含具备业务唯一性的订单/行为 ID用于支撑签到每天只返利一次这类幂等约束。五、返利订单创建接口与入账实现本节对外提供的是返利订单创建接口核心职责是接收用户行为触达信息包括用户 ID、行为类型打卡/签到/支付等以及必要的业务标识按配置组装聚合对象查询该行为对应的返利配置组装返利订单实体与 task 实体一个事务入库返利订单 task 记录原子写入发送 MQ 消息完成入口动作后立即发送返利入账消息。接口实现遵循 DDD 的分层思想领域层domain只负责业务逻辑配置组装、聚合构建、事务编排数据持久化由基础设施层提供这样返利领域保持独立后续扩展新行为类型开户、拉新、信贷时只需增加配置而不需要改动领域核心逻辑。入账的账在这里有两层含义返利订单入账用户的行为产生了返利订单记录这是本节的完成标志奖励额度入账真正把抽奖次数/积分充入用户账户属于第 23 节结算环节的工作接收 MQ 消息后调用活动账户额度入账接口。本节与下一节的分工正是入口入账 异步结算的经典拆分入口接口快速响应、写库落单重活账户额度更新通过 MQ 异步消化避免用户在签到接口上等待完整的返利链路。六、MQ 消息发送与任务兜底设计面试高频点6.1 为什么数据库操作和 MQ 不能在一个事务里数据库事务只能覆盖本地数据库的读写而 MQ 消息的发送是跨中间件的操作两者天然无法合并成一个原子事务。如果先发消息再写库可能出现消息发出去了但订单没写成功下游收到消息却查不到订单如果先写库再发消息则可能订单写好了但消息发送失败下游永远收不到。无论哪种顺序都存在数据不一致的窗口。6.2 任务表 状态标记 扫描补偿本节的解法是任务记录兜底这也是面试问题汇总中明确提到的设计notes.md 第 18 问本身发送 MQ 是可能存在万分之一或者十万分之的失败的而数据库操作和 MQ 操作本身不能做数据库事务。但又要保证失败后的补偿处理。所以要结合中奖记录在写一条发送 MQ 的任务记录任务记录上有一个状态标记是否发送完成这样就可以通过任务扫描的方式完成 MQ 的补偿发送。落到返利场景就是返利订单 task 记录同事务写库后顺序执行一次 MQ 发送成功后更新 task 状态为已发送如果发送失败或状态更新失败task 记录保持未发送/待补偿状态由定时任务或分布式任务调度如 XXL-JOB扫描未完成的任务进行 MQ 补偿发送。关于补偿量级文档特别强调这里是为了业务流程最快的推进如果是更新失败也没关系还有兜底的任务补偿。【任务补偿的数量并不多但非常需要这个手段】也就是说正常路径追求快入库后立即发消息异常路径依赖任务扫描兜底两者结合保证只要订单存在消息最终一定会被送出。6.3 幂等设计唯一业务 ID既然存在补偿发送就必然存在重复消息的可能。为此 MQ 消息必须携带具备业务唯一性的标识MQ 的消息是必须含带具有唯一标识的业务 ID 的。比如订单 ID、奖品 ID、支付单 ID、交易单 ID、贷款单 ID 等等。接收 MQ 的系统通过唯一 ID 业务更新或者写库的时候可以保证幂等性。notes.md 第 19 问返利场景中消息体携带返利订单 ID或用户行为业务 ID第 23 节消费端通过查询返利记录表判断是否已处理重复消息直接丢弃从而保证签到返利每天只入账一次。6.4 多机部署下的任务抢占如果补偿任务部署在多台机器上每台机器都可能捞到同一条失败消息导致重复发送。notes.md 第 25 问给出了标准答案一个任务就是要有多机备份避免一个挂了就没有人执行了。之后这里的方案是加锁设计一个抢占锁多个任务抢占同一个锁谁抢占到了谁可以执行如果抢占的执行失败了删掉锁重新执行如果删锁失败对于是谁抢占的谁可以做重入锁继续执行锁有失效时间如果抢占到的自己挂了等待锁失效后重新轮候抢占。这套抢占锁 失效时间 重入机制确保任务补偿在任何单点故障场景下都不会中断也不会被多机重复执行配合消息幂等双保险。七、衔接结算第 23 节返利结算本节入账完成后链路进入 第23节用户行为返利结算原文档对该节的设计要点如下上一节对用户的行为根据返利配置进行入账发送 MQ 消息这一节将接收 MQ 消息开始结算返利。这里也就是给用户的活动账户充值。并提供一个日历签到返利的接口用于后续对接到前端 UI 使用。结算环节的三个关键点接收 MQ 消息消费返利入账消息调用活动账户额度入账接口增加用户的可抽奖次数额度分维度更新包括总、月、日账户额度更新总额度、本月额度、当日额度对应签到每天一次的约束可以在日额度层面做校验MQ 消息过滤消费端只处理返利类型为sku 类型的返利其他类型如积分直接忽略留给后续扩展日历签到接口对外提供一个日历签到返利接口用于后续前端 UI 对接对应 web 第5节对接联调额度签到权重接口。由此用户行为返利的完整闭环是入口接口入账第 22 节→ MQ 异步结算第 23 节→ 前端日历签到展示。八、扩展通用返利 RPC 接口对接支付返利签到只是返利的行为之一。为了支撑外部业务系统接入大营销平台还提供了通用返利 RPC 接口详见 第3节RPC接口对接支付返利通过在大营销 big-market 新增提供的通用返利 RPC 接口由 OpenAI 服务 chatgpt-data 系统在支付完成接收到回调消息后进行对接完成返利动作。用户下单完成支付后会接收到支付消息之后调用大营销提供的返利接口进行返利。返利为积分和抽奖次数。这一扩展正好验证了本节领域设计的预留扩展点价值返利领域抽象的是行为类型而非具体行为签到用 HTTP/应用接口触达支付返利用 RPC 接口触达二者的核心逻辑配置组装 → 聚合事务入库 → MQ 发送 → 任务兜底完全复用。积分类型的返利则进一步由 积分领域调额服务 对接返利异步消息完成积分额度增加。九、面试要点速览围绕本节内容最值得沉淀的面试问答均可在 notes.md 找到完整讨论MQ 消息发送失败怎么处理数据库操作与 MQ 无法同事务采用业务记录 任务记录同事务入库先发一次 MQ失败由任务扫描补偿发送的方案保证最终一致。生产者可能多次发送同一个 MQ怎么保证不重复入账消息携带唯一业务 ID如返利订单 ID消费端查返利记录表判断幂等重复即丢弃。多机部署下定时任务重复捞消息怎么办抢占锁机制谁抢到锁谁执行失败删锁重试支持重入锁带失效时间防止持锁者宕机。签到返利为什么要用 MQ 解耦除了削峰填谷更核心的是接口快速响应 下游异步结算 失败可补偿的一致性设计签到动作本身低并发但行为 → 入账 → 结算的链路需要可靠解耦。签到每天只返利一次幂等怎么实现每天的行为记录生成唯一订单 ID返利订单表按唯一 ID 去重同时日额度账户更新也会拦截超限。小结本节「用户行为返利入账」是大营销平台返利链路的入口其技术骨架可以浓缩为一句话一个聚合返利订单 任务记录同事务入库、一条消息MQ 异步通知、一层兜底任务扫描补偿。理解并落地这套设计你就掌握了分布式环境下本地事务 消息异步 任务补偿这一组最核心的最终一致性手段——这也是它成为面试高频考点的根本原因。赞分享文档教程后端【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址https://gitcode.com/gh_mirrors/code/CodeGuide点击查看免费下载相关推荐gearmand客户端开发指南从零开始构建高效任务提交应用gearmand客户端开发指南从零开始构建高效任务提交应用 gearmand是一款功能强大的分布式任务队列系统能够帮助开发者轻松构建高效的任务处理应用。本文文档教程后端大营销平台微服务对接基于 NacosDubbo 的 RPC 支付返利接口设计与实现大营销平台微服务对接基于 NacosDubbo 的 RPC 支付返利接口设计与实现 导读 本文聚焦《大营销平台系统》外部对接阶段的第 3 节核心内容在 b文档教程后端《大营销平台系统》积分领域调额服务调额接口抽象与行为发奖异步链路设计《大营销平台系统》积分领域调额服务调额接口抽象与行为发奖异步链路设计 本文围绕《大营销平台系统设计实现》营销服务第 26 节「积分领域调额服务」展开讲解积分文档教程后端上一篇Apache Curator实战案例10个常见分布式场景解决方案下一篇如何实时跟踪Walrus存储网络活动智能合约事件监控完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 大营销平台用户行为返利入账实战：rebate 返利领域、聚合事务与 MQ 异步任务兜底设计
文档教程后端【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址https://gitcode.com/gh_mirrors/code/CodeGuide点击查看免费下载本篇文章围绕《大营销平台系统设计实现》营销服务第 22 节「用户行为返利入账」展开讲解用户行为返利rebate领域从需求设计、库表创建、聚合事务入账到 MQ 异步消息发送与失败任务兜底的完整落地过程。读完你可以掌握如何用 DDD 方式划分返利领域、如何用一个聚合对象实现返利订单与任务记录的原子入库、以及 MQ 发送失败时如何通过任务表补偿这同时也是面试中高频追问的分布式一致性问题。一、章节定位与本章诉求用户行为返利是《大营销平台系统》第二阶段营销服务中的一个独立领域模块位于整个抽奖/返利/积分流程的入口侧第 21 节完成了活动信息 API 的迭代与功能完善第 22 节本节负责把用户的行为动作转化为返利订单并异步通知下游第 23 节接收 MQ 消息完成返利结算给用户的活动账户充值额度。原文档第22节用户行为返利入账给出的本章诉求非常明确按照用户行为返利的需求设计创建相应的库表开发 rebate 返利领域提供返利订单创建接口。并在写入订单后发送 MQ 消息。后续则处理奖励入账。也就是说这一节要做四件事依据 用户行为奖励需求设计 创建返利相关库表开发独立的rebate返利领域对外提供返利订单创建接口接收用户行为触达信息在订单写入后发送 MQ 消息交由下游第 23 节完成奖励入账。本章难度评定为 ★★★☆☆难点不在于单个功能点的实现而在于聚合事务 MQ 异步 任务兜底这套组合设计的理解与落地。二、业务场景什么是用户行为返利用户行为返利User Behavior Rebate是一种非常日常的营销活动类型。文档中给出的例子很直观你在某个平台创建了新账号就会给你发一堆的开户优惠券这些都是日常的返利活动。这类返利的共同特点是由用户完成特定行为动作来触达奖励。原文档列举了常见的返利行为类型行为类型说明打卡 / 签到每日一次的行为动作本节主场景连签连续多日签到通常有额外奖励档位支付完成一笔支付后获得返利开户注册新账号后发放开户优惠交易 / 信贷 / 拉新交易达标、信贷行为、邀请新用户等本节在功能实现上主要落地的是日常日历签到行为但从领域设计上抽象了用户行为类型这个维度把打卡、签到、支付、开户、交易、信贷、拉新等各类任务都作为可扩展的配置项方便后续扩展。这一点与需求文档的设计意图一致——用户行为奖励需求设计 中明确提到用户的 2 个行为动作打卡/签到每天可完成一次另外一个动作是后续对接 openai 项目的时候来接收一个支付完成的消息触达发奖资格。发奖可以是抽奖资格也可以是给用户积分。积分部分后续实现。那么这里 openai 支付的对接和赠送积分的场景虽然要后续实现但在我们本次做的需求中要预留出设计否则后续就不好扩展了。也就是说一个用户行为动作对应奖励一种东西可以是我们前面定义出来的 sku一个 sku 配置了用户可使用的抽奖次数额度也可以是积分。本节以 sku 返利为主但库表与领域设计为积分返利预留了扩展点。三、业务流程聚合对象 事务入库 MQ 兜底原文档用一张业务流程图概括了本节的核心流程并给出了三个关键设计点1. 一个行为可能触发多种奖励按配置组装聚合对象一个用户行为可能会给多种奖励所以在接收到用户信息后会根据配置组装聚合对象。【聚合的目的就是为了做一个统一的事务】用户的某一个行为动作例如签到可能同时命中多条返利配置系统需要把这一行为产生的全部返利结果组装成一个聚合对象目的就是保证它们作为一个整体做一次事务性入库避免一条条写入导致的数据不一致。2. 聚合对象包含返利订单实体与 task 实体一个事务入库一个聚合对象中包含了返利的订单实体对象写入 task 的实体对象。它们是一个事务入库。这是整个设计最关键的一环返利订单记录和**MQ 发送任务记录task**在同一个数据库事务中落库。为什么 task 记录必须和业务订单同事务写入因为在分布式环境下数据库操作和 MQ 消息发送本身无法处于同一个事务中MQ 中间件不参与本地数据库事务一旦订单写库成功但消息发送失败就会造成订单存在、下游不知道的数据丢失。把 task 记录与订单同事务写入就为后续的消息补偿留下了依据。3. 发送 MQ 消息失败有任务兜底另外是发送 MQ 消息在完成入口动作后会直接发送 MQ 消息并且如果发送失败会有任务兜底。【这样是面试中经常问到的点如果 MQ 消息发送失败了你是怎么处理的。】完整流程可以概括为用户行为动作签到/支付等 │ ▼ 根据返利配置组装聚合对象返利订单实体 task 实体 │ ▼ 同一数据库事务入库返利订单 任务记录 │ ▼ 发送 MQ 消息返利入账消息 │ ├── 成功 → 更新 task 状态为已发送 │ └── 失败 → 保留 task 未发送状态由任务扫描补偿兜底四、返利领域建模与库表设计4.1 DDD 领域边界从 DDD 建模的视角看返利是一个独立的领域。在 《架构DDD 领域驱动设计》 的四色建模规范中蓝色 - 决策命令用户发起的行为动作如开始签到、开始抽奖黄色 - 领域事件过去时态描述如签到完成、抽奖完成。签到返利的建模路径就是用户发起签到决策命令 → 触发签到完成领域事件 → 返利领域根据配置组装返利订单 → 写入任务记录。从系统建模可以细分出返利、活动、策略、奖品等领域其中兑换可以是单独的领域也可以合并到返利实现见 system-design-diagram.md。4.2 库表设计思路原文档明确要求创建相应的库表。结合 用户行为奖励需求设计 可以推断返利领域至少需要两类核心表返利配置表描述行为类型 → 奖励内容的映射关系奖励内容关联 skusku 上配置了可用的抽奖次数额度并预留积分等奖励类型的扩展字段返利订单表记录每次用户行为触达产生的返利订单即返利记录作为后续结算和幂等判断的依据。需要说明的是返利订单表承担了幂等校验的职责。面试问题汇总notes.md中专门提到过这个设计RabbitMQ 判断重复消费的逻辑是直接在数据库中查询返利记录表是否有相同的订单 ID 的记录如果发现重复就不消费。这也印证了返利订单表需要包含具备业务唯一性的订单/行为 ID用于支撑签到每天只返利一次这类幂等约束。五、返利订单创建接口与入账实现本节对外提供的是返利订单创建接口核心职责是接收用户行为触达信息包括用户 ID、行为类型打卡/签到/支付等以及必要的业务标识按配置组装聚合对象查询该行为对应的返利配置组装返利订单实体与 task 实体一个事务入库返利订单 task 记录原子写入发送 MQ 消息完成入口动作后立即发送返利入账消息。接口实现遵循 DDD 的分层思想领域层domain只负责业务逻辑配置组装、聚合构建、事务编排数据持久化由基础设施层提供这样返利领域保持独立后续扩展新行为类型开户、拉新、信贷时只需增加配置而不需要改动领域核心逻辑。入账的账在这里有两层含义返利订单入账用户的行为产生了返利订单记录这是本节的完成标志奖励额度入账真正把抽奖次数/积分充入用户账户属于第 23 节结算环节的工作接收 MQ 消息后调用活动账户额度入账接口。本节与下一节的分工正是入口入账 异步结算的经典拆分入口接口快速响应、写库落单重活账户额度更新通过 MQ 异步消化避免用户在签到接口上等待完整的返利链路。六、MQ 消息发送与任务兜底设计面试高频点6.1 为什么数据库操作和 MQ 不能在一个事务里数据库事务只能覆盖本地数据库的读写而 MQ 消息的发送是跨中间件的操作两者天然无法合并成一个原子事务。如果先发消息再写库可能出现消息发出去了但订单没写成功下游收到消息却查不到订单如果先写库再发消息则可能订单写好了但消息发送失败下游永远收不到。无论哪种顺序都存在数据不一致的窗口。6.2 任务表 状态标记 扫描补偿本节的解法是任务记录兜底这也是面试问题汇总中明确提到的设计notes.md 第 18 问本身发送 MQ 是可能存在万分之一或者十万分之的失败的而数据库操作和 MQ 操作本身不能做数据库事务。但又要保证失败后的补偿处理。所以要结合中奖记录在写一条发送 MQ 的任务记录任务记录上有一个状态标记是否发送完成这样就可以通过任务扫描的方式完成 MQ 的补偿发送。落到返利场景就是返利订单 task 记录同事务写库后顺序执行一次 MQ 发送成功后更新 task 状态为已发送如果发送失败或状态更新失败task 记录保持未发送/待补偿状态由定时任务或分布式任务调度如 XXL-JOB扫描未完成的任务进行 MQ 补偿发送。关于补偿量级文档特别强调这里是为了业务流程最快的推进如果是更新失败也没关系还有兜底的任务补偿。【任务补偿的数量并不多但非常需要这个手段】也就是说正常路径追求快入库后立即发消息异常路径依赖任务扫描兜底两者结合保证只要订单存在消息最终一定会被送出。6.3 幂等设计唯一业务 ID既然存在补偿发送就必然存在重复消息的可能。为此 MQ 消息必须携带具备业务唯一性的标识MQ 的消息是必须含带具有唯一标识的业务 ID 的。比如订单 ID、奖品 ID、支付单 ID、交易单 ID、贷款单 ID 等等。接收 MQ 的系统通过唯一 ID 业务更新或者写库的时候可以保证幂等性。notes.md 第 19 问返利场景中消息体携带返利订单 ID或用户行为业务 ID第 23 节消费端通过查询返利记录表判断是否已处理重复消息直接丢弃从而保证签到返利每天只入账一次。6.4 多机部署下的任务抢占如果补偿任务部署在多台机器上每台机器都可能捞到同一条失败消息导致重复发送。notes.md 第 25 问给出了标准答案一个任务就是要有多机备份避免一个挂了就没有人执行了。之后这里的方案是加锁设计一个抢占锁多个任务抢占同一个锁谁抢占到了谁可以执行如果抢占的执行失败了删掉锁重新执行如果删锁失败对于是谁抢占的谁可以做重入锁继续执行锁有失效时间如果抢占到的自己挂了等待锁失效后重新轮候抢占。这套抢占锁 失效时间 重入机制确保任务补偿在任何单点故障场景下都不会中断也不会被多机重复执行配合消息幂等双保险。七、衔接结算第 23 节返利结算本节入账完成后链路进入 第23节用户行为返利结算原文档对该节的设计要点如下上一节对用户的行为根据返利配置进行入账发送 MQ 消息这一节将接收 MQ 消息开始结算返利。这里也就是给用户的活动账户充值。并提供一个日历签到返利的接口用于后续对接到前端 UI 使用。结算环节的三个关键点接收 MQ 消息消费返利入账消息调用活动账户额度入账接口增加用户的可抽奖次数额度分维度更新包括总、月、日账户额度更新总额度、本月额度、当日额度对应签到每天一次的约束可以在日额度层面做校验MQ 消息过滤消费端只处理返利类型为sku 类型的返利其他类型如积分直接忽略留给后续扩展日历签到接口对外提供一个日历签到返利接口用于后续前端 UI 对接对应 web 第5节对接联调额度签到权重接口。由此用户行为返利的完整闭环是入口接口入账第 22 节→ MQ 异步结算第 23 节→ 前端日历签到展示。八、扩展通用返利 RPC 接口对接支付返利签到只是返利的行为之一。为了支撑外部业务系统接入大营销平台还提供了通用返利 RPC 接口详见 第3节RPC接口对接支付返利通过在大营销 big-market 新增提供的通用返利 RPC 接口由 OpenAI 服务 chatgpt-data 系统在支付完成接收到回调消息后进行对接完成返利动作。用户下单完成支付后会接收到支付消息之后调用大营销提供的返利接口进行返利。返利为积分和抽奖次数。这一扩展正好验证了本节领域设计的预留扩展点价值返利领域抽象的是行为类型而非具体行为签到用 HTTP/应用接口触达支付返利用 RPC 接口触达二者的核心逻辑配置组装 → 聚合事务入库 → MQ 发送 → 任务兜底完全复用。积分类型的返利则进一步由 积分领域调额服务 对接返利异步消息完成积分额度增加。九、面试要点速览围绕本节内容最值得沉淀的面试问答均可在 notes.md 找到完整讨论MQ 消息发送失败怎么处理数据库操作与 MQ 无法同事务采用业务记录 任务记录同事务入库先发一次 MQ失败由任务扫描补偿发送的方案保证最终一致。生产者可能多次发送同一个 MQ怎么保证不重复入账消息携带唯一业务 ID如返利订单 ID消费端查返利记录表判断幂等重复即丢弃。多机部署下定时任务重复捞消息怎么办抢占锁机制谁抢到锁谁执行失败删锁重试支持重入锁带失效时间防止持锁者宕机。签到返利为什么要用 MQ 解耦除了削峰填谷更核心的是接口快速响应 下游异步结算 失败可补偿的一致性设计签到动作本身低并发但行为 → 入账 → 结算的链路需要可靠解耦。签到每天只返利一次幂等怎么实现每天的行为记录生成唯一订单 ID返利订单表按唯一 ID 去重同时日额度账户更新也会拦截超限。小结本节「用户行为返利入账」是大营销平台返利链路的入口其技术骨架可以浓缩为一句话一个聚合返利订单 任务记录同事务入库、一条消息MQ 异步通知、一层兜底任务扫描补偿。理解并落地这套设计你就掌握了分布式环境下本地事务 消息异步 任务补偿这一组最核心的最终一致性手段——这也是它成为面试高频考点的根本原因。赞分享文档教程后端【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址https://gitcode.com/gh_mirrors/code/CodeGuide点击查看免费下载相关推荐gearmand客户端开发指南从零开始构建高效任务提交应用gearmand客户端开发指南从零开始构建高效任务提交应用 gearmand是一款功能强大的分布式任务队列系统能够帮助开发者轻松构建高效的任务处理应用。本文文档教程后端大营销平台微服务对接基于 NacosDubbo 的 RPC 支付返利接口设计与实现大营销平台微服务对接基于 NacosDubbo 的 RPC 支付返利接口设计与实现 导读 本文聚焦《大营销平台系统》外部对接阶段的第 3 节核心内容在 b文档教程后端《大营销平台系统》积分领域调额服务调额接口抽象与行为发奖异步链路设计《大营销平台系统》积分领域调额服务调额接口抽象与行为发奖异步链路设计 本文围绕《大营销平台系统设计实现》营销服务第 26 节「积分领域调额服务」展开讲解积分文档教程后端上一篇Apache Curator实战案例10个常见分布式场景解决方案下一篇如何实时跟踪Walrus存储网络活动智能合约事件监控完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考