首页
关于
Search
1
同步本地Markdown至Typecho站点
54 阅读
2
微服务
38 阅读
3
苍穹外卖
27 阅读
4
JavaWeb——后端
24 阅读
5
消息队列MQ
18 阅读
后端学习
项目
杂项
科研
论文
默认分类
登录
推荐文章
推荐
拼团设计模式
项目
8月11日
0
7
0
推荐
拼团交易系统
项目
6月20日
0
21
1
推荐
Smile云图库
项目
6月7日
0
27
0
热门文章
54 ℃
同步本地Markdown至Typecho站点
项目
3月22日
0
54
0
38 ℃
微服务
后端学习
3月21日
0
38
0
27 ℃
苍穹外卖
项目
3月21日
0
27
0
最新发布
2025-07-05
matlab
matlab笔记 命令行窗口 clc：清屏（命令行窗口） clear all:把命名的变量删掉，不是命令行窗口 命名规则： 变量命名以字母开头，不可以下划线，变量是区分字母大小写的 脚本 %% xxx 注释（百分号+一个空格） % xxx 也是注释 s='a' '"aaaa",字符串 abs(s) 字符s的ascii码,为97 char(97), 输出'a' numtostr(65) ans='65'，数字转字符串 length(str),字符串的长度 矩阵 A=[1 2 3 ;4 5 6 ;7 8 9] 分号换行 B=A‘ ，矩阵转置 C=A(:) ,将矩阵拉成一列，按列存储，第一列拼接第二列拼接第三列 D=inv(A) 求逆矩阵 E=zeros(10,5,3) 生成10行5列3维0矩阵 元胞数组 A=cell(1,6)，生成1行6列的小格子，每个小格子可以存放各种数据 eye(3),生成3x3的单位阵 A{2}=eye(3),matlab数组从1开始，不是0
科研
zy123
7月5日
0
5
0
2025-06-27
小论文
小论文 1.背景意义这边需要改。 2.卡尔曼滤波这边，Q、R不明确 / 真实若干时刻的测量值可以是真实值；但后面在线预测的时候仍然传的是真实值，事实上无法获取=》 考虑用三次指数平滑，对精确重构出来的矩阵谱分解，得到的特征值作为'真实值'，代入指数平滑算法中进行在线更新，执行单步计算。 4.这块有问题，没提高秩性，没说除了ER模型外的移动模型如RWP 特征值精度预估 1. 噪声随机变量与协方差 符号 含义 $w_i$ 第 $i$ 个过程噪声样本 $v_j$ 第 $j$ 个观测噪声样本 $Q$ 过程噪声的真实方差（协方差矩阵退化） $R$ 观测噪声的真实方差（协方差矩阵退化） 说明： 在矩阵形式的 Kalman Filter 中，通常写作 $$ w_k\sim\mathcal N(0,Q),\quad v_k\sim\mathcal N(0,R). $$ 这里为做统计检验，把 $w_i, v_j$ 当作样本，$Q,R$ 就是它们在标量情况下的方差。 2. 样本统计量 符号 含义 $N_w,;N_v$ 过程噪声样本数和观测噪声样本数 $\bar w$ 过程噪声样本均值 $\bar v$ 观测噪声样本均值 $s_w^2$ 过程噪声的样本方差估计 $s_v^2$ 观测噪声的样本方差估计 定义： $$ \bar w = \frac1{N_w}\sum_{i=1}^{N_w}w_i,\quad s_w^2 = \frac1{N_w-1}\sum_{i=1}^{N_w}(w_i-\bar w)^2, $$ $$ \bar v = \frac1{N_v}\sum_{j=1}^{N_v}v_j,\quad s_v^2 = \frac1{N_v-1}\sum_{j=1}^{N_v}(v_j-\bar v)^2. $$ 3. 方差比的 $F$ 分布区间估计 构造 $F$ 统计量 $$ F = \frac{(s_w^2/Q)}{(s_v^2/R)} = \frac{s_w^2}{s_v^2},\frac{R}{Q} \sim F(N_w-1,,N_v-1). $$ 置信区间（置信度 $1-\alpha$） 查得 $$ F_{L}=F_{\alpha/2}(N_w-1,N_v-1),\quad F_{U}=F_{1-\alpha/2}(N_w-1,N_v-1), $$ 则 $$ \begin{align*} P\Big{F_{\rm L}\le F\le F_{\rm U}\Big}=1-\alpha \quad\Longrightarrow \quad P\Big{F_{\rm L},\le\frac{s_w^2}{s_v^2},\frac{R}{Q}\le F_{\rm U},\Big}=1-\alpha. \end{align*} $$ 解出 $\frac{R}{Q}$ 的区间 $$ P\Bigl{,F_{L},\frac{s_v^2}{s_w^2}\le \frac{R}{Q}\le F_{U},\frac{s_v^2}{s_w^2}\Bigr}=1-\alpha. $$ 令 $$ \theta_{\min}=\sqrt{,F_{L},\frac{s_v^2}{s_w^2},},\quad \theta_{\max}=\sqrt{,F_{U},\frac{s_v^2}{s_w^2},}. $$ 4. 卡尔曼增益与误差上界 在标量情况下（即状态和观测均为1维），卡尔曼增益公式可简化为： $$ K = \frac{P_k H^T}{HP_k H^T + R} = \frac{HP_k}{H^2 P_k + R} $$ 针对我们研究对象，特征值滤波公式的系数都属于实数域。$P_{k-1}$是由上次迭代产生，因此可以$FP_{k-1}F^T$看作定值，则$P_k$的方差等于$Q$的方差，即： $$ \text{var}(P_k) = \text{var}(Q) $$ 令 $c = H$, $m = 1/H$（满足 $cm = 1$），则： $$ K = \frac{cP_k}{c^2 P_k + R} = \frac{1}{c + m(R/P_k)} \quad R/P_k\in[\theta_{\min}^2,\theta_{\max}^2]. $$ 则极值为 $$ K_{\max}=\frac{1}{c + m\,\theta_{\min}^2},\quad K_{\min}=\frac{1}{c + m\,\theta_{\max}^2}. $$ 通过历史数据计算预测误差的均值： $$ E(x_k' - x_k) \approx \frac{1}{M} \sum_{m=1}^{M} (x_k^{l(m)} - x_k^{(m)})\\ $$ 定义误差上界 $$ \xi =\bigl(K_{\max}-K_{\min}\bigr)\;E\bigl(x_k'-x_k\bigr) =\Bigl(\tfrac1{c+m\,\theta_{\min}^2}-\tfrac1{c+m\,\theta_{\max}^2}\Bigr) \,E(x_k'-x_k). $$ 若令 $c\,m=1$，可写成 $$ \xi =\frac{(\theta_{\max}-\theta_{\min})\,E(x_k'-x_k)} {(c^2+\theta_{\min})(c^2+\theta_{\max})}. $$ 量化噪声方差估计的不确定性，进而评估卡尔曼滤波器增益的可能波动，并据此给出滤波误差的上界. 指数平滑法 指数平滑法（Single Exponential Smoothing） 指数平滑法是一种对时间序列进行平滑和短期预测的简单方法。它假设近期的数据比更久之前的数据具有更大权重，并用一个平滑常数 $\alpha$（$0<\alpha\leq1$）来控制“记忆”长度。 平滑方程： $$ S_t = \alpha,x_t + (1-\alpha),S_{t-1} $$ $x_t$：时刻 $t$ 的实际值 $S_t$：时刻 $t$ 的平滑值（也可作为对 $x_{t+1}$ 的预测） $S_1$ 的初始值一般取 $x_1$ 举例： 假设一产品过去 5 期的销量为 $[100,;105,;102,;108,;110]$，取 $\alpha=0.3$，初始平滑值取 $S_1=x_1=100$： $S_2=0.3\times105+0.7\times100=101.5$ $S_3=0.3\times102+0.7\times101.5=101.65$ $S_4=0.3\times108+0.7\times101.65\approx103.755$ $S_5=0.3\times110+0.7\times103.755\approx106.379$ 因此，对第 6 期销量的预测就是 $S_5\approx106.38$。 二次指数平滑法（Holt’s Linear Method） 当序列存在趋势（Trend）时，单次平滑会落后。二次指数平滑（也称 Holt 线性方法）在单次平滑的基础上，额外对趋势项做平滑。 水平和趋势平滑方程： $$ \begin{cases} L_t = \alpha,x_t + (1-\alpha)(L_{t-1}+T_{t-1}), \[6pt] T_t = \beta,(L_t - L_{t-1}) + (1-\beta),T_{t-1}, \end{cases} $$ $L_t$：水平（level） $T_t$：趋势（trend） $\alpha, \beta$：平滑常数，通常 $0.1$–$0.3$ 预测公式： $$ \hat _{t+m} = L_t + m,T_t $$ 其中 $m$ 为预测步数。 举例： 用同样的数据 $[100,105,102,108,110]$，取 $\alpha=0.3,;\beta=0.2$，初始化： $L_1 = x_1 = 100$ $T_1 = x_2 - x_1 = 5$ 接下来计算： $t=2$： $$ L_2=0.3\times105+0.7\times(100+5)=0.3\times105+0.7\times105=105 $$ $$ T_2=0.2\times(105-100)+0.8\times5=0.2\times5+4=5 $$ $t=3$： $$ L_3=0.3\times102+0.7\times(105+5)=0.3\times102+0.7\times110=106.4 $$ $$ T_3=0.2\times(106.4-105)+0.8\times5=0.2\times1.4+4=4.28 $$ $t=4$： $$ L_4=0.3\times108+0.7\times(106.4+4.28)\approx0.3\times108+0.7\times110.68\approx110.276 $$ $$ T_4=0.2\times(110.276-106.4)+0.8\times4.28\approx0.2\times3.876+3.424\approx4.199 $$ $t=5$： $$ L_5=0.3\times110+0.7\times(110.276+4.199)\approx0.3\times110+0.7\times114.475\approx112.133 $$ $$ T_5=0.2\times(112.133-110.276)+0.8\times4.199\approx0.2\times1.857+3.359\approx3.731 $$ 预测第 6 期 ($m=1$)： $$ \hat _6 = L_5 + 1\times T_5 \approx 112.133 + 3.731 = 115.864 $$ 小结 单次指数平滑适用于无明显趋势的序列，简单易用。 二次指数平滑（Holt 方法）在水平外加趋势成分，适合带线性趋势的数据，并可向未来多步预测。 通过选择合适的平滑参数 $\alpha,\beta$ 并对初值进行合理设定，即可在实践中获得较好的短期预测效果。 三次指数平滑法概述 三次指数平滑法在二次（Holt）方法的基础上又加入了对季节成分的平滑，适用于同时存在趋势（Trend）和季节性（Seasonality）的时间序列。 主要参数及符号 $m$：季节周期长度（例如季度数据 $m=4$，月度数据 $m=12$）。 $\alpha, \beta, \gamma$：水平、趋势、季节三项的平滑系数，均在 $(0,1]$ 之间。 $x_t$：时刻 $t$ 的实际值。 $L_t$：时刻 $t$ 的水平（level）平滑值。 $B_t$：时刻 $t$ 的趋势（trend）平滑值。 $S_t$：时刻 $t$ 的季节（seasonal）成分平滑值。 $\hat x_{t+h}$：时刻 $t+h$ 的 $h$ 步预测值。 平滑与预测公式（加法模型） $$ \begin{aligned} L_t &= \alpha\,(x_t - S_{t-m}) + (1-\alpha)\,(L_{t-1}+B_{t-1}),\\ B_t &= \beta\,(L_t - L_{t-1}) + (1-\beta)\,B_{t-1},\\ S_t &= \gamma\,(x_t - L_t) + (1-\gamma)\,S_{t-m},\\ \hat x_{t+h} &= L_t + h\,B_t + S_{t-m+h_m},\quad\text{其中 }h_m=((h-1)\bmod m)+1. \end{aligned} $$ 加法模型 适用于季节波动幅度与水平无关的情况； 乘法模型 则把"$x_t - S_{t-m}$"改为"$x_t / S_{t-m}$"、"$S_t$"改为"$\gamma,(x_t/L_t)+(1-\gamma),S_{t-m}$"并在预测中用乘法。 计算示例 假设我们有一个周期为 $m=4$ 的序列，前 8 期观测值： $$ x = [110,\;130,\;150,\;95,\;120,\;140,\;160,\;100]. $$ 取参数 $\alpha=0.5,\;\beta=0.3,\;\gamma=0.2$。 初始值按常见做法设定为： $L_0 = \frac{1}{m}\sum_{i=1}^m x_i = \tfrac{110+130+150+95}{4}=121.25$. 趋势初值 $$ B_0 = \frac{1}{m^2}\sum_{i=1}^m (x_{m+i}-x_i) = \frac{(120-110)+(140-130)+(160-150)+(100-95)}{4\cdot4} = \frac{35}{16} \approx 2.1875. $$ 季节初值 $S_i = x_i - L_0$，即 $[-11.25,;8.75,;28.75,;-26.25]$ 对应 $i=1,2,3,4$。 下面我们演示第 5 期（$t=5$）的更新与对第 6 期的预测。 $t$ $x_t$ 计算细节 结果 已知初值 0 – $L_0=121.25,;B_0=2.1875$ 1–4 – $S_{1\ldots4}=[-11.25,,8.75,,28.75,,-26.25]$ 5 120 $L_5=0.5(120-(-11.25)) +0.5(121.25+2.1875)$ $\approx127.3438$ $B_5=0.3(127.3438-121.25)+0.7\cdot2.1875$ $\approx3.3594$ $S_5=0.2(120-127.3438)+0.8\cdot(-11.25)$ $\approx-10.4688$ 预测 $h=1$ – $\hat x_6 = L_5 + 1\cdot B_5 + S_{6-4};(=S_2=8.75)$ $\approx139.45$ 解读： 期 5 时，剔除上周期季节影响后平滑得到新的水平 $L_5$； 由水平变化量给出趋势 $B_5$； 更新第 5 期的季节因子 $S_5$； 期 6 的一步预测综合了最新水平、趋势和对应的季节因子，得 $\hat x_6\approx139.45$。 总结思考 如果你把预测值 $\hat x_{t+1}$ 当作"新观测"再去更新状态，然后再预测 $\hat x_{t+2}$，这种"预测—更新—预测"的迭代方式会让模型把自身的预测误差也当作输入，不断放大误差。 正确做法是——在时刻 $t$ 得到 $L_t,B_t,S_t$ 后，用上面的直接公式一次算出所有未来 $\hat x_{t+1},\hat x_{t+2},\dots$，这样并不会"反馈"误差，也就没有累积放大的问题。 或者，根据精确重构出来的矩阵谱分解，得到的特征值作为'真实值'，进行在线更新，执行单步计算。 实时估计 为什么不用AI 能做预测 ，对于完全随机网络没有用 复杂度高 需要数据训练 算力时间 图神经 可以搞多维特征 AI对结构预测不准， 特征 为什么要等随机网络稳定？这里其实是一个假设，稳定下来：RWP 在足够长时间后满足 Birkhoff 点态遍历定理，节点的取样分布趋于稳态，并且对每个时刻都是同分布！！！然后可以应用那个结论。
科研
zy123
6月27日
0
4
0
2025-06-27
DDD领域驱动设计
DDD领域驱动设计 什么是 DDD？ DDD（领域驱动设计，Domain-Driven Design）是一种软件设计方法论，它为软件工程设计提供了一套完整的指导思想与实践手段。通过领域、界限上下文、实体、值对象、聚合、工厂、仓储等概念，DDD 帮助我们合理划分工程模型，从而在前期投入更多思考，规划出可持续迭代和演进的系统架构。 在工程实践中，DDD 通常分为两个层面的设计： 1. 战略设计 战略设计的目标是应对复杂业务需求。通过抽象与分治，将系统合理拆分为独立的业务模块或微服务，以实现“分而治之”。但拆分是否合理，要看实际开发与上线过程：如果每次上线都需要改动多个微服务，那么说明设计失败，反而形成了“微服务单体”。相比之下，更合理的模式是：以少数几个中等规模的单体应用为核心，周围构建一个服务生态系统，这样既能保持灵活性，也避免过度拆分。 2. 战术设计 战术设计关注如何在代码层面表达业务概念。它强调利用面向对象的思维方式，将业务逻辑封装在领域模型中，并通过实体、聚合、领域服务来承载业务行为。 传统的 MVC 三层架构往往只是 Service 层加数据模型的简单组合，容易导致 Service 类臃肿、逻辑复杂，甚至出现“贫血模型”问题——数据与行为分离，增加了维护难度。DDD 的战术设计通过丰富的领域模型来规避这一问题，使系统结构更清晰、业务逻辑更可维护。 为什么要用DDD？ 先说说传统Spring MVC： Spring MVC 传统上多采用 分层架构（Controller-Service-DAO）。 对于 简单业务 或 原型开发，这种方式足够清晰，开发成本低，上手快。 说说Spring MVC的不足： 在 复杂业务场景（核心逻辑复杂、规则频繁变化的系统）中，传统分层模式会暴露出明显问题： 1）业务逻辑分散： 大量 if-else、规则判断和外部调用混杂在 Service 中。 代码难以维护，稍有业务变更，就需要在已有方法里继续堆条件分支。 @Service public class OrderService { @Autowired private OrderRepository orderRepository; @Autowired private PaymentGateway paymentGateway; public void payOrder(Long orderId, String payMethod) { Order order = orderRepository.findById(orderId); // 校验订单 if (order == null) { throw new IllegalArgumentException("订单不存在"); } if (!order.getStatus().equals("UNPAID")) { throw new IllegalStateException("订单状态不允许支付"); } // 校验金额 if (order.getAmount().compareTo(BigDecimal.ZERO) <= 0) { throw new IllegalStateException("订单金额异常"); } // 支付逻辑 boolean success = paymentGateway.pay(order.getId(), order.getAmount(), payMethod); if (!success) { throw new RuntimeException("支付失败"); } // 修改状态 order.setStatus("PAID"); orderRepository.save(order); } } 一个 Service 同时承担校验、业务逻辑、状态修改、持久化和外部调用，演变成“上帝类”。 2）贫血模型：Entity/POJO 只存数据，业务逻辑全堆在 Service，对象与业务语义严重脱节，比如Order 类里找不到 pay()，只能在 OrderService 找到 payOrder()。 3）随着需求增长，Service 越来越庞大，修改风险高、测试困难。 引出DDD的价值 1）业务逻辑回归领域模型（充血模型） 通过 实体、值对象、聚合、领域服务 等概念，把业务规则放回领域模型中，实现高内聚： public class Order { private Long id; private BigDecimal amount; private String status; // 领域方法：支付 public void pay(PaymentGateway paymentGateway, String payMethod) { validateBeforePay(); boolean success = paymentGateway.pay(this.id, this.amount, payMethod); if (!success) { throw new RuntimeException("支付失败"); } this.status = "PAID"; } private void validateBeforePay() { if (!"UNPAID".equals(this.status)) { throw new IllegalStateException("订单状态不允许支付"); } if (amount.compareTo(BigDecimal.ZERO) <= 0) { throw new IllegalStateException("订单金额异常"); } } } @Service public class OrderAppService { @Autowired private OrderRepository orderRepository; @Autowired private PaymentGateway paymentGateway; public void payOrder(Long orderId, String payMethod) { Order order = orderRepository.findById(orderId); order.pay(paymentGateway, payMethod); // 业务逻辑放在 Order 里 orderRepository.save(order); } } 扩展更容易：如果要加优惠券逻辑，只需要在 Order 里扩展，而不是在 Service 里继续堆 if-else。 2）统一语言（Ubiquitous Language） DDD 强调与业务专家使用一致的术语建模，保证沟通顺畅： 传统写法: Controller: OrderController.create() Service: OrderService.saveOrder() DAO: OrderRepository.insert() 业务专家说：“下单” 。开发说：“调用 create() 接口，service.saveOrder()，repository.insert()。” DDD 写法: 团队必须先和业务专家一起挖掘、定义业务概念。 然后这些词汇会 直接落到模型、聚合、实体、方法名 上。 Customer.placeOrder() （客户下单） Order.markAsPendingPayment() （订单标记为待支付） OrderRepository.save(order) （仓储保存订单） 业务专家说：“下单 → 待支付” 。开发说：“placeOrder() → markAsPendingPayment()。” 3）技术解耦与可演进性 1）领域层不依赖技术实现，领域模型只关心业务，不关心底层是 MySQL、Redis、ES 还是文件。 所有外部依赖都通过 接口 定义，比如 OrderRepository。具体的存储实现交给 适配器，在基础设施层完成。 2）遵循依赖倒置原则，领域层依赖抽象接口，而不是依赖具体实现，当技术实现需要调整（如 MySQL → Redis），只需要改适配器。领域模型的变更只来自业务规则的变化，而不是技术变更。 **面试官可能追问：**你只是把service层中的逻辑移动到了实体类中，将臃肿的代码逻辑转移到了别处？ 回答： 表面上看，DDD 确实是把 Service 里的逻辑挪到了实体，但本质不是搬家，而是职责重构。 在贫血模型里，实体只是数据容器，业务规则分散在不同 Service 里，导致代码臃肿、逻辑重复。 在充血模型里，规则和实体强绑定，代码语义更贴近业务： 规则归属清晰：订单的支付校验、发货校验都收拢在 Order 聚合里，不会分散在多个 Service。 统一语言：order.pay() 就等于业务里的“订单支付”，减少沟通成本。 复杂度可控：领域服务负责编排，聚合/实体承载业务逻辑，基础设施负责实现，避免出现‘上帝 Service’。 更易维护扩展：新增优惠券逻辑只需在 Order 内扩展，而不是在庞大的 Service 里继续加 if-else。 所以 DDD 的意义在于让领域模型成为业务的表达中心，而不仅仅是逻辑搬家。 如何理解聚合根？ 我把聚合理解为一组强相关的实体和值对象，它们必须作为一个整体来保证业务一致性。聚合根是这组对象对外唯一的入口。所有修改必须通过聚合根来进行，它负责维护不变式，并定义事务边界；仓储也以聚合根为单位。跨聚合我们通过 ID 引用与领域事件实现最终一致，避免大事务。例如在订单域，Order 是聚合根，OrderLine、Address 在聚合内；总价计算、状态流转等不变式在一次事务里由 Order 保证；库存属于另一个聚合，通过“订单已提交”事件去扣减库存。这样既保证一致性，又降低耦合、便于扩展。 DDD概念理论 所有例子可以基于： 1.创建订单+扣减库存+用户。 2.聚合根：Order，内部有item实体，地址值对象 或者 用户实体+活动实体+优惠实体 充血模型 vs 贫血模型 定义 贫血模型：对象仅包含数据属性和简单的 getter/setter，业务逻辑由外部服务处理。 充血模型：对象既包含数据，也封装相关业务逻辑，符合面向对象设计原则。 特点 贫血模型 充血模型 封装性 数据和逻辑分离 数据和逻辑封装在同一对象内 职责分离 服务类负责业务逻辑，对象负责数据 对象同时负责数据和自身的业务逻辑 适用场景 简单的增删改查、DTO 传输对象 复杂的领域逻辑和业务建模 优点 简单易用，职责清晰 高内聚，符合面向对象设计思想 缺点 服务层臃肿，领域模型弱化 复杂度增加，不适合简单场景 面向对象原则 违反封装原则 符合封装原则 贫血模型： // 1. “贫血”的订单实体 (Entity) // 它只是一个数据袋子，没有行为，只有getter/setter public class Order { private Long id; private String status; private BigDecimal amount; // ... 一堆getter和setter方法 } // 2. “贫血”的商品实体 (Entity) public class Product { private Long id; private String name; private Integer stock; // 库存 // ... 一堆getter和setter方法 } // 3. 庞大的“服务层” (Service) 包含所有业务逻辑 @Service public class OrderService { @Autowired private ProductRepository productRepository; public void decreaseStock(Long productId, Integer quantity) { // 步骤1: 查询商品 Product product = productRepository.findById(productId); // 步骤2: 检查库存（业务规则） if (product.getStock() < quantity) { throw new RuntimeException("库存不足"); } // 步骤3: 计算并设置新库存（业务逻辑） Integer newStock = product.getStock() - quantity; product.setStock(newStock); // 对象的状态由外部服务来修改 // 步骤4: 保存回数据库 productRepository.save(product); } } 问题：所有业务逻辑（检查库存、计算新库存）都放在了 OrderService这个外部服务里。Product对象本身只是个“傻傻的”数据载体，它对自己的业务规则（如“库存不能为负”）一无所知，谁都可以随意setStock，非常容易出错。这就是 “贫血模型”。 充血模型： // 1. “充血”的商品实体 (Entity/Aggregate Root) // 它不仅有数据，更有行为（方法），它对自己的业务规则负责 public class Product { private Long id; private String name; private Integer stock; // 库存 // 核心业务行为：减少库存 // 这个方法是直接写在这个实体对象内部的！ public void decreaseStock(Integer quantity) { // 守护业务规则：库存不能减少为负数 if (this.stock < quantity) { throw new DomainException("商品库存不足，无法减少"); } // 业务逻辑：修改自身状态 this.stock -= quantity; } // 其他行为，如增加库存... public void increaseStock(Integer quantity) { this.stock += quantity; } } // 2. 变得很“薄”的服务层 (Service/Application Service) // 它的职责不再是处理业务逻辑，而是协调事务、调用仓库、发布事件等 @Service public class OrderApplicationService { @Autowired private ProductRepository productRepository; public void decreaseStock(Long productId, Integer quantity) { // 步骤1: 获取领域对象（聚合根） Product product = productRepository.findById(productId); // 步骤2: 调用领域对象自身的业务方法！ product.decreaseStock(quantity); // 逻辑在Product内部 // 步骤3: 保存这个发生了变化的对象 productRepository.save(product); } } 这样的方式可以在使用一个对象时，就顺便拿到这个对象的提供的一系列业务方法，所有使用对象的逻辑方法，都不需要自己再次处理同类逻辑。 但不要只是把充血模型，仅限于一个类的设计和一个类内的方法设计。充血还可以是整个包结构**（领域模型）**，一个包下包括了用于实现此包 Service 服务所需的各类零部件（模型、仓储、工厂），也可以被看做充血模型。 同时我们还会再一个同类的类下，提供对应的内部类，如用户实名，包括了通信类、实名卡、银行卡、四要素等。它们都被写进到一个用户类下的内部子类，这样在代码编写中也会清晰的看到子类的所属信息，更容易理解代码逻辑，也便于维护迭代。 我的实体类本身还是偏贫血模型，主要负责承载数据和基本的不变式校验。**但在领域层里，我会把仓储、领域服务和实体组合在一起，所有业务逻辑都在领域模型中闭环实现，不会散落到外层，这样整体上就是充血思想。**实体保证自身一致性，复杂逻辑交给领域服务来实现。 限界上下文 限界上下文是指一个明确的边界，规定了某个子领域的业务模型和语言，确保在该上下文内的术语、规则、模型不与其他上下文混淆。是一个 业务设计概念。 表达 语义环境 实际含义 "我吃得很饱，现在不能动了" 日常用餐 字面意思：吃到肚子很满 "我吃得很饱，今天的演讲让人充实" 知识分享 比喻：得到了很大满足 限界上下文的作用 定义业务边界：类似于语义环境，为通用语言划定范围 消除歧义：确保团队对领域对象、事件的认知一致 领域转换：同一对象在不同上下文有不同名称（goods在电商称"商品"，运输称"货物"） 模型隔离：防止不同业务领域的模型相互干扰 在代码工程里，每个上下文拥有独立包结构 领域模型 指特定业务领域内，业务规则、策略以及业务流程的抽象和封装。在设计手段上，通过风暴模型拆分领域模块，形成界限上下文。最大的区别在于把原有的众多 Service + 数据模型的方式，拆分为独立的有边界的领域模块。每个领域内创建自身所属的；领域对象（实体、聚合、值对象）、仓储服务(DAO 操作)、工厂、端口适配器Port（调用外部接口的手段）等。 在原本的 Service + 贫血的数据模型开发指导下，Service 串联调用每一个功能模块。这些基础设施（对象、方法、接口）是被相互调用的。这也是因为贫血模型并没有面向对象的设计，所有的需求开发只有详细设计。 换到充血模型下，现在我们以一个领域功能为聚合，拆分一个领域内所需的 Service 为领域服务，VO、Req、Res 重新设计为领域对象，DAO、Redis 等持久化操作为仓储等。举例：一套账户服务中的，授信认证、开户、提额降额等，每一个都是一个独立的领域，在每个独立的领域内，创建自身领域所需的各项信息。 领域模型还有一个特点，它自身只关注业务功能实现，不与外部任何接口和服务直连。如；不会直接调用 DAO 操作库，也不会调用缓存操作 Redis，更不会直接引入 RPC 连接其他微服务。而是通过仓库Repository和端口适配器port，定义调用外部数据的含有出入参对象的接口标准，让基础设施层做具体的调用实现——通过这样的方式让领域只关心业务实现，同时做好防腐。(依赖倒置） 领域服务 一组无状态的业务操作，封装那些“不属于任何单个实体/聚合”的领域逻辑。 职责 执行跨聚合、跨实体的业务场景—— 处理一个订单支付时，可能需要处理与 订单、账户、支付信息 等多个实体的交互。 在这种情况下，领域服务负责协调这些实体之间的交互。 协调仓储接口、调用多个聚合根的方法，但本身不持有长期状态 领域服务自己不持有数据状态，它的职责是调度和协调。它通过调用聚合根（或实体）的方法来完成业务操作。它也不会涉及持久化（数据存储），这些通常是通过仓储层来管理的。 典型示例 订单支付功能： 涉及订单、用户账户、支付信息等多个实体，适合放在领域服务中实现 订单（Order）：包含订单的详细信息。 账户（Account）：用户的账户信息，包括余额。 支付信息（PaymentDetails）：支付的具体信息，例如支付方式、金额等。 public class PaymentService { public void processPayment(Order order, PaymentDetails paymentDetails, Account account) { // 1. 检查账户余额 if (account.getBalance() < paymentDetails.getAmount()) { throw new InsufficientFundsException(); } // 2. 扣除账户余额 account.deductBalance(paymentDetails.getAmount()); // 3. 更新订单状态 order.setStatus(OrderStatus.PAID); // 4. 记录支付信息或其他操作 paymentDetails.recordPayment(order); } } 领域对象 实体 实体是基于持久化层数据和领域服务功能目标设计的领域对象。与持久化的 PO（持久化对象）不同，PO 只是原子类对象，缺乏业务语义，而实体对象不仅具备业务语义，还具有唯一标识。实体对象与领域服务方法紧密结合，跟随其生命周期进行操作。 例如，用户的 PO 对象可能包括用户开户信息、授信信息和额度信息等多个方面，而订单则可能涉及多个实体，例如商品下单时的购物车实体。实体通常作为领域服务方法的入参对象。 在代码中，实体通常表现为具有唯一标识的业务对象，标识属性（如 ID）是其核心特征。例如： 订单实体：通过订单 ID 唯一标识 用户实体：通过用户 ID 唯一标识 核心特征： 实体的属性随着时间变化而变化。 唯一标识（ID）保持不变，确保实体的唯一性。 实体对象通常在代码中以实体类的形式存在，并且通常采用 充血模型 实现，即将与该实体相关的业务逻辑和行为写入实体类中，而不仅仅是存储数据。 值对象 值对象是没有唯一标识的业务对象，具有以下特征： 创建后不可修改（immutable） 只能通过整体替换来更新 通常用于描述实体的属性和特征 在开发值对象的时候，通常不会提供 setter 方法，而是提供构造函数或者 Builder 方法来实例化对象。这个对象通常不会独立作为方法的入参对象，但做可以独立作为出参对象使用。 聚合与聚合根 ”高内聚、低耦合“，代码中直观的感受就是仓储层中，传入的如果是聚合根，意味着要对不同的表进行处理，因此对应方法上一般要加@Transactional-------拼团中的锁单、退单都是如此！！！ 锁单：同时操作拼团表和拼团明细表；退单拼团表+拼团明细表+消息通知表。 在领域驱动设计（DDD）中，聚合是一组紧密关联的 **实体 **和 值对象的组合，这些对象在业务上共同协作，形成一个统一的一致性与事务边界。聚合根 是聚合的唯一入口，负责对外提供操作接口，并维护聚合内部的一致性和业务规则。 1. 聚合（逻辑边界 设计概念） 一致性边界：聚合内的所有变更必须在同一事务中完成，要么全部成功，要么全部失败，确保内部业务不变式（Invariant）始终成立。 事务边界：一次事务只允许跨越一个聚合，避免分布式事务的复杂性。 访问约束：外部代码不得直接修改聚合内除聚合根之外的对象，所有操作都必须通过聚合根进行。 示例： 一个订单聚合可能包含： 订单实体（聚合根）：Order，全局唯一ID，提供操作方法。 订单明细实体：OrderItem，描述商品项（数量、单价）。 收货地址值对象：ShippingAddress，不可变，包含地址信息。 在下单过程中，购物车实体（来自上游）会被转换为订单聚合内部的订单明细实体。 原则：聚合内保证事务一致性，聚合与聚合之间通过事件或服务实现最终一致性。 2. 聚合根（物理入口 具体的类） 唯一入口：对外唯一的访问点，聚合内的所有修改必须经由聚合根发起。 全局标识：聚合根是一个拥有全局唯一 ID 的实体。 规则守护者：负责封装聚合内部的业务逻辑、数据校验及不变式维护。 跨聚合交互：与其他聚合交互时，只传递 ID 或使用领域服务，不直接持有对方实体的引用，避免跨边界耦合。 public class Order { // 聚合根 private final OrderId id; // 根实体唯一标识 private List<OrderItem> items; // 聚合内实体 private ShippingAddress address; // 聚合内值对象 public Order(String orderId, ShippingAddress shippingAddress) { this.orderId = orderId; this.shippingAddress = shippingAddress; this.items = new ArrayList<>(); } public void addItem(String productId, int quantity, double price) { OrderItem item = new OrderItem(productId, quantity, price); items.add(item); } public double totalAmount() { return items.stream().mapToDouble(OrderItem::totalPrice).sum(); } } // 使用示例 public class Main { public static void main(String[] args) { // 创建送货地址 ShippingAddress address = new ShippingAddress("123 Main St", "Cityville", "12345"); // 创建订单 Order order = new Order("1", address); // 添加商品到订单 order.addItem("A001", 2, 100.0); order.addItem("B002", 1, 50.0); // 输出订单详情 System.out.println(order); // 输出订单总金额 System.out.println("Total amount: " + order.totalAmount()); } } 说明： Order 是聚合根，对外暴露安全的操作方法。 OrderItem 是聚合内的实体，不允许外部直接新增或修改，只能通过 Order.addItem()，即通过聚合根来操作。 ShippingAddress 是不可变的值对象，每次修改需整体替换。 仓储服务 特征 封装持久化操作：Repository负责封装所有与数据源交互的操作，如创建、读取、更新和删除（CRUD）操作。这样，领域层的代码就可以避免直接处理数据库或其他存储机制的复杂性。 抽象接口：Repository定义了一个与持久化机制无关的接口，这使得领域层的代码可以在不同的持久化机制之间切换，而不需要修改业务逻辑。 职责分离 领域层 只定义 Repository 接口，关注“需要做哪些数据操作”（增删改查、复杂查询），不关心具体实现。 基础设施层 实现这些接口（ORM、JDBC、Redis、ES、RPC、HTTP、MQ 推送等），封装所有外部资源的访问细节。 仓储解耦的手段使用了依赖倒置的设计。 示例： 只定义接口，由基础设施层来实现。 public interface IActivityRepository { GroupBuyActivityDiscountVO queryGroupBuyActivityDiscountVO(String source, String channel); SkuVO querySkuByGoodsId(String goodsId); } 使用：在应用程序中使用依赖注入（DI）来将具体的Repository实现注入到需要它们的领域服务或应用服务中。 聚合和领域服务和仓储服务的比较 有状态（Stateful）： 一个订单（Order）聚合，它可能会记录订单的状态，比如“未支付”或“已支付”，以及订单项（OrderItem）的列表。在处理订单时，这些状态会发生变化（例如，当订单支付时，它的状态从“未支付”变为“已支付”）。 无状态： 一个计算价格的服务（PricingService）是无状态的，它接收输入（例如商品数量、商品价格等），然后计算并返回结果。它不会记住上一次计算的结果，每次计算都是独立的。 特性 聚合（Aggregate） 领域服务（Domain Service） 仓储（Repository） 本质 相关实体和值对象的组合，以“聚合根”为唯一访问入口 无状态的业务逻辑单元，封装跨实体 / 跨聚合规则 抽象的数据访问接口，隐藏底层存储细节，为聚合提供持久化能力 状态 有状态——内部维护数据与不变式 无状态——仅暴露行为 无业务状态；实现层可能有缓存，但对外看作无状态 职责 1. 内部一致性2. 定义事务边界3. 提供领域行为（order.pay() 等） 1. 承载跨实体规则2. 协调多个聚合完成业务动作 1. 加载 / 保存聚合根2. 把 PO ↔️ Entity 映射3. 屏蔽 SQL/ORM/缓存等技术细节 边界 聚合边界：内部操作要么全部成功要么全部失败 无一致性边界，仅调用聚合或仓储 持久化边界：一次操作针对一个聚合；不负责业务事务（由应用层控制） 典型用法 Order.addItem(),Order.cancel() PricingService.calculate(...),InventoryService.reserveStock(...) orderRepository.findById(id),orderRepository.save(order) **自己总结：**领域服务纯编排流程并注入仓储服务； 仓储服务只写接口，规定一个具体的'动作'； 然后基础设施层中子类实现该仓储接口，并注入若干Dao，一个'动作'可能调用多个Dao来实现； Dao直接与数据库打交道，实现增删查改。 DDD架构设计 四层架构 用户接口层interface：处理用户交互和展示 应用层application：协调领域对象完成业务用例 领域层domain：包含核心业务逻辑和领域模型 基础设施层infrastructure：提供技术实现支持 如何从MVC架构映射到DDD架构？ 六边形架构 领域模型设计 方式1；DDD 领域科目类型分包，类型之下写每个业务逻辑。 方式2；业务领域分包，每个业务领域之下有自己所需的 DDD 领域科目。（拼团营销系统是方式2）
后端学习
zy123
6月27日
0
12
0
2025-06-20
拼团交易系统
拼团交易系统 部署 本地环境：Maven3.8.4 SpringBoot: 2.7.12 jdk:1.8 目录结构： docker-compose: version: '3.8' services: # 1. 前端 group-buy-market-front: image: nginx:alpine container_name: group-buy-market-front restart: unless-stopped ports: - '18091:80' volumes: - ./nginx/html:/usr/share/nginx/html - ./nginx/conf/nginx.conf:/etc/nginx/nginx.conf:ro privileged: true networks: - group-buy-network # 4. Java 后端 group-buying-sys: build: context: ../../.. # 从 docs/tag/v2.0 回到项目根 dockerfile: group-buying-sys-app/Dockerfile image: smile/group-buying-sys:latest container_name: group-buying-sys restart: unless-stopped depends_on: mysql: condition: service_healthy redis: condition: service_healthy ports: - '8091:8091' environment: - TZ=Asia/Shanghai - SPRING_PROFILES_ACTIVE=prod volumes: - ./log:/data/log logging: driver: json-file options: max-size: '10m' max-file: '3' networks: - group-buy-network mysql: image: mysql:8.0 container_name: group-buy-mysql hostname: mysql command: --default-authentication-plugin=mysql_native_password restart: unless-stopped environment: TZ: Asia/Shanghai MYSQL_ROOT_PASSWORD: 123456 ports: - "13306:3306" volumes: - ./mysql/my.cnf:/etc/mysql/conf.d/mysql.cnf:ro - ./mysql/sql:/docker-entrypoint-initdb.d healthcheck: test: [ "CMD", "mysqladmin" ,"ping", "-h", "localhost" ] interval: 5s timeout: 10s retries: 10 start_period: 15s networks: - group-buy-network # Redis redis: image: redis:6.2 restart: unless-stopped container_name: group-buy-redis hostname: redis privileged: true ports: - 16379:6379 volumes: - ./redis/redis.conf:/usr/local/etc/redis/redis.conf command: redis-server /usr/local/etc/redis/redis.conf networks: - group-buy-network healthcheck: test: [ "CMD", "redis-cli", "ping" ] interval: 10s timeout: 5s retries: 3 # rabbitmq # 账密 admin/admin # rabbitmq-plugins enable rabbitmq_management rabbitmq: image: rabbitmq:3.8-management container_name: group-buy-rabbitmq hostname: rabbitmq restart: unless-stopped ports: - "5672:5672" - "15672:15672" environment: RABBITMQ_DEFAULT_USER: admin RABBITMQ_DEFAULT_PASS: admin command: rabbitmq-server volumes: - ./rabbitmq/enabled_plugins:/etc/rabbitmq/enabled_plugins - ./rabbitmq/mq-data:/var/lib/rabbitmq networks: - group-buy-network nacos: image: nacos/nacos-server:v2.1.0 container_name: group-buy-nacos-server hostname: nacos restart: unless-stopped env_file: - ./nacos/custom.env ports: - "8848:8848" - "9848:9848" - "9849:9849" depends_on: - mysql networks: - group-buy-network volumes: - ./nacos/init.d:/docker-entrypoint-init.d networks: group-buy-network: external: true dockerfile: # —— 第一阶段：Maven 构建 —— FROM maven:3.8.7-eclipse-temurin-17-alpine AS builder WORKDIR /workspace # 把项目级 settings.xml 复制到容器里 COPY .mvn/settings.xml /root/.m2/settings.xml # 1. 先只拷贝父 POM 及各模块的 pom.xml，加速依赖下载 COPY pom.xml ./pom.xml COPY group-buying-sys-api/pom.xml ./group-buying-sys-api/pom.xml COPY group-buying-sys-domain/pom.xml ./group-buying-sys-domain/pom.xml COPY group-buying-sys-infrastructure/pom.xml ./group-buying-sys-infrastructure/pom.xml COPY group-buying-sys-trigger/pom.xml ./group-buying-sys-trigger/pom.xml COPY group-buying-sys-types/pom.xml ./group-buying-sys-types/pom.xml COPY group-buying-sys-app/pom.xml ./group-buying-sys-app/pom.xml # 离线下载所有依赖 RUN mvn dependency:go-offline -B # 2. 拷贝所有源码 COPY . . # 3. 只打包 main 应用模块（连带编译它依赖的模块），跳过测试，加速构建 RUN mvn \ -f pom.xml clean package \ -pl group-buying-sys-app -am \ -DskipTests -B # —— 第二阶段：运行时镜像 —— FROM openjdk:17-jdk-slim LABEL maintainer="smile" # 可选：设置时区 ENV TZ=Asia/Shanghai RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone # 把构建产物拷过来 COPY --from=builder \ /workspace/group-buying-sys-app/target/group-buying-sys-app.jar \ app.jar # 暴露端口，按需改 EXPOSE 8091 ENTRYPOINT ["java", "-jar", "app.jar"] 修改项目后部署的影响： 前端服务 (group-buy-market-front) 代码位置：通过卷挂载 (./nginx/html:/usr/share/nginx/html)。 修改影响 如果修改的是 ./nginx/html 下的前端代码（如 HTML/JS/CSS），无需重建，Nginx 会直接读取更新后的文件。 如果修改的是 Nginx 配置 (./nginx/conf/nginx.conf)，需重启容器生效： docker compose restart group-buy-market-front Java 后端服务 (group-buying-sys) 代码位置：通过镜像构建（build 指定了 Dockerfile 路径）。 修改影响 如果修改了 Java 代码或依赖（如 pom.xml），必须重建镜像： docker compose up -d --build group-buying-sys 其他服务（MySQL/Redis/RabbitMQ/Nacos） 代码位置：均使用官方镜像，无业务代码。 修改影响 修改配置文件（如 ./redis/redis.conf）需重启容器： docker compose restart redis 无需 --build（除非你自定义了它们的镜像）。 压测 .服务器资源：2核心4GB 验证锁单接口：防超卖 Jmeter测试，一秒发1000次请求下： 可以发现，只有一开始的少部分的并发请求进入抢占库存，抢占失败会返回'拼团组队失败，缓存库存不足'，后面'交易锁单拦截-xx'都是在第一层就被拦下了，即下单前的人数/库存校验。 如果仅要求“防超卖”，已经可以确保在资源有限时也不超卖。 但是在2核 4GB，服务只能稳定支撑 ≈240 QPS，平均响应 2 秒 测试查询拼团配置接口： ≈320 QPS 系统备忘录 本系统涉及微信和支付宝的回调。 1.微信扫码登录，*https://mp.weixin.qq.com/debug/cgi-bin/sandboxinfo?action=showinfo&t=sandbox/index*平台上配置了扫描通知地址，如果是本地测试，需要打开frp内网穿透，然后填的地址是frp建立通道的服务器端的ip:端口 2.支付宝，用户付款成功回调，也是同理，本地测试就要开frp。注意frp中的通道，默认是本地端口=远程端口，但是如果在服务器上部署了一套，那么远程的端口就会与frp的端口冲突！！！导致本地测试的时候失效。 流程： 用户锁单-》支付宝付款-》成功后return_url设置了用户支付完毕后跳转回哪个地址是给前端用户看的； alipay_notify_url设置了支付成功后alipay调用你的后端哪个接口。 这里有小商城和拼团系统，notify_url指拼团系统中拼团达到指定人数后，通知小商城的HTTP地址，但是如果notify_type为MQ，则 notify_url为空，并且notify_mq非空，指明是拼团成功通知还是用户退单通知（topic.team_refund）。 如果不参与拼团，则支付回调会直接修改订单为deal_done，然后发一个'支付成功'消息，进入下一环节：发货。 若参与拼团，则RPC调用拼团系统中的'拼团交易结算'接口，增加拼团完成量、更新订单状态。 若拼团达到人数，发送拼团成功通知，小商场将订单中相应拼团的 status 都设置为deal_done，然后小商场内部也再发一个'支付成功'消息，主要用于通知这些 拼团对应的订单进入下一环节：发货（感觉'支付成功'取名不够直观）。 若为用户退单通知，小商场需处理退款业务。 临时记的备忘录，不一定完善，具体看后面总结。 踩坑 Lua脚本问题（后面也没采用这种方式） long max = target + recovery; String lua = "local v = redis.call('INCR', KEYS[1])+1; " + "if tonumber(v) > tonumber(ARGV[1]) then " + " redis.call('DECR', KEYS[1]); " + " return 0; " + "end " + "return v;"; Long occupy = redisService.eval( lua, RScript.ReturnType.INTEGER, Collections.singletonList(teamOccupiedStockKey), max); 报错： org.redisson.client.RedisException: ERR Error running script (call to f_xxxx): @user_script:1: user_script:1: attempt to compare nil with number. 问题：max的值根本传不到 ARGV[1] 原因：因为我配置了一个全局默认的序列号器： config.setCodec(JsonJacksonCodec.INSTANCE); //用 Jackson 进行序列化 Lua脚本期望：原始字符串或数字参数 因此，需要对这块单独配置序列化器StringCodec()： redissonClient.getScript(new org.redisson.client.codec.StringCodec()).eval(xxx,xx....) 系统设计 在 DDD 中有一套共识的工程两阶段设计手段，包括；战略设计、战术设计。 战略设计：战略设计的核心是通过业务边界划分和上下文隔离，将复杂的业务系统拆分为多个高内聚、低耦合的限界上下文，并明确它们之间的交互方式（如通过领域事件、API、消息队列等）。 战术设计：战术设计关注如何在限界上下文内部，使用领域模型来表达业务逻辑，避免传统的贫血模型（Anemic Model）导致的复杂、难以维护的代码。 用例图 用例图（use case diagram）是用户与系统交互的最简表示形式，展现了用户和与他相关的用例之间的关系。它不仅反映了不同角色（如用户、运营）在系统中的职责边界和任务范围，还以可视化的方式呈现了系统提供的核心功能和服务，如同一份构建系统的战略蓝图。 四色建模图 MVC的困局：面向过程的“大通铺” 传统MVC开发是面向过程的，像一个大通铺，大家挤在一起。 为每个功能流程（A、B、C流程）编写代码，导致功能代码四处复制、杂乱交织，难以管理和复用。 DDD的解法：面向领域的“精装公寓” DDD通过领域建模，将系统划分为不同的领域（如活动域、人群标签配置域、交易域）。 这就像为每个家庭分配独立的公寓和房间，让代码各归其位，结构清晰，易于维护。 1.建模方法 建模的起点：从用户行为出发 DDD建模始于用户，分析其行为命令如何触发系统动作。 用例图是完美的起点，它直观展示了用户与系统的所有交互，帮助我们识别出所有关键行为。 统一的语言：协作的基石 建模过程需要产品、研发、测试等所有角色基于统一语言（如“拼团”、“成团”）进行协作。 四色建模/风暴模型是DDD的标准方法，旨在让所有参与者能共同理解和构建业务模型。 此图为风暴事件指导图，通过寻找领域事件，发起事件命令，完成领域事件的过程，完成 DDD 工程建模。 蓝色 - 决策命令，是用户发起的行为动作，如；发起拼团Command、支付订单Command，是流程的起点。 黄色 - 领域事件，在领域内已经发生的、有业务意义的事实。如支付已成功Event、拼团已成功Event。，是流程的终点。 红色 - 业务流程，连接决策命令和领域事件的处理逻辑或业务规则。它接收命令，执行业务操作，并产生事件，如拼团成团策略（判断人数是否已满）、支付处理流程。 粉色 - 外部系统，流程中需要调用的第三方服务或系统，如支付宝支付、微信登录。 绿色 - 只读模型，做一些读取数据的动作，没有写库的操作，如拼团活动展示。 棕色 - 领域对象，承载业务数据和行为的核心对象，是命令操作的直接目标，包括实体、值对象、聚合根，如用户地址（值对象）。 综上，左下角的示意图。是一个用户，通过一个策略命令，使用领域对象，通过业务流程，完成2个领域事件，调用1次外部接口个过程。我们在整个 DDD 建模过程中，就是在寻找这些节点。 流程解析： 1.起点：用户意图（User），用户想要做一件事，比如“发起拼团”或“支付订单”。 2.动作：决策命令（Command），用户的意图被封装为一个具体的 Command（命令），通常包含执行该命令所需的所有数据。 3.核心：领域对象，命令不会凭空执行，它必须作用于一个具体的领域对象（通常是聚合根 Aggregate）。这个对象是业务的核心载体，拥有数据和行为。 4.执行：业务流程，领域对象根据自身的业务规则来处理接收到的命令。这个过程会修改对象自身的状态（如减少库存），并封装了最核心的业务逻辑。 5.结果：领域事件，业务执行成功后，会产生一个或多个领域事件。 6.扩展：调用外部系统，产生的领域事件可能会触发后续动作，其中之一就是调用外部系统。这是系统与外界协作的方式。 7.展示：读模型，负责提供数据查询功能。它通常通过监听领域事件来更新自己的数据视图，确保用户能看到最新的状态 2.寻找领域事件 寻找领域事件的过程，就是寻找系统中流程节点的结果态。什么结束了、什么完成了、什么终止。这个过程就是一堆人头脑风暴的过程，避免错失流程节点。 比如：发起拼团完成、支付完成、参与拼团完成、拼团目标达成、回调通知完成... 3.划分领域 在确定了领域事件以后，接下来要做的就是通过决策命令串联领域事件，并填充上所需要的领域对象。 首先，通过用户的行为动作，也就是决策命令，串联到对应的领域事件上。并对复杂的流程提供出红色的业务流程。 之后，为决策命令添加领域对象，每一个领域在整个流程中都起到了至关重要的作用。 有了识别出来的领域角色的流程，就可以非常容易的划分出领域边界了。 观察串联好的流程和聚集的领域对象，功能紧密相关、数据频繁交互的一组对象和事件自然形成一个领域。 例如： 所有与成团逻辑相关的命令、事件、实体（如拼团锁单、拼团结算）、策略（如成团校验策略）可以划归为 拼团域。 所有与活动相关的，比如活动配置信息、商品试算优惠价格，都可以划分为活动域。 4.简易流程图 首先，站在运营的角度，要为这次拼团配置对应的拼团活动。那么就会涉及到；给哪个渠道的什么商品ID配置拼团，这样用户在进入商品页就可以看到带有拼团商品的信息了。之后要考虑，这个拼团的商品所提供的规则信息，包括：折扣、起止时间、人数等。还要拿到折扣的一个试算金额。这个试算出来的金额，就是告诉用户，通过拼团可以拿到的最低价格。 那么，拼团活动表，为什么会把折扣拆分出来呢。因为这里的折扣可能有多种迭代到一个拼团上。比如，给一个商品添加了直减10元的优惠，又对符合的人群id的用户，额外打9折，这样就有了2个折扣迭代。所以拆分出来会更好维护。这是对常变的元素和稳定的元素进行设计的思考。 另外，为了支持拼团库表，需要先根据业务规则把符合条件的用户 ID 写入 Bitmap，并为这批用户打上可配置的人群标签。创建拼团活动时，只需关联对应标签，即可让活动自动面向这部分用户生效，实现精准运营和差异化折扣。 之后，站在用户的角度，是参与拼团。首次发起一个拼团或者参与已存在的拼团进行数据的记录，达成拼团约定拼团人数后，开始进行通知。这个通知的设计站在平台角度可以提供回调，那么任何的系统也就都可以接入了。 系统表设计 group_buy_activity（拼团活动） 字段名 说明 id 自增 activity_id 活动ID activity_name 活动名称 discount_id 折扣ID group_type 成团方式（0自动成团、1达成目标成团） take_limit_count 拼团次数限制 target 拼团目标 valid_time 拼团时长（分钟） status 活动状态（0创建、1生效、2过期、3废弃） start_time 活动开始时间 end_time 活动结束时间 tag_id 人群标签规则标识 tag_scope 人群标签规则范围（多选；1可见限制、2参与限制） create_time 创建时间 update_time 更新时间 group_buy_discount（折扣配置） 字段名 说明 id 自增ID discount_id 折扣ID discount_name 折扣标题 discount_desc 折扣描述 discount_type 折扣类型（0:base、1:tag） market_plan 营销优惠计划（ZJ:直减、MJ:满减、ZK:折扣、N元购） market_expr 营销优惠表达式 tag_id 人群标签（特定优惠限定） create_time 创建时间 update_time 更新时间 group_buy_order（拼团订单表） 字段名 说明 id 自增ID team_id 拼单组队ID activity_id 活动ID source 渠道 channel 来源 original_price 原始价格 deduction_price 折扣金额 pay_price 支付价格 target_count 目标数量 complete_count 完成数量 lock_count 锁单数量 status 状态（0拼单中、1完成、2失败、3完成-含退单） valid_start_time 拼团开始时间 valid_end_time 拼团结束时间 notify_type 回调类型（HTTP、MQ） notify_url 回调地址（HTTP 回调不可为空） create_time 创建时间 update_time 更新时间 group_buy_order_list（拼团订单明细表） 字段名 说明 id 自增ID user_id 用户ID team_id 拼单组队ID order_id 订单ID activity_id 活动ID start_time 锁单时间 end_time 最晚锁单时间 valid_end_time 拼团结束时间 goods_id 商品ID source 渠道 channel 来源 original_price 原始价格 deduction_price 折扣金额 pay_price 支付金额 status 状态（0初始锁定、1消费完成、2用户退单） out_trade_no 外部交易单号（幂等） create_time 创建时间 update_time 更新时间 biz_id 业务唯一ID out_trade_time 外部交易时间 notify_task（回调任务） 字段名 说明 id 自增ID activity_id 活动ID team_id 拼单组队ID notify_category 回调种类（trade_unpaid2refund） notify_type 回调类型（HTTP、MQ） notify_mq 回调消息 notify_url 回调接口 notify_count 回调次数 notify_status 回调状态（0初始、1完成、2重试、3失败） parameter_json 参数对象 uuid 唯一标识 create_time 创建时间 update_time 更新时间 crowd_tags（人群标签） 字段名 说明 id 自增ID tag_id 人群ID tag_name 人群名称 tag_desc 人群描述 statistics 人群标签统计量 create_time 创建时间 update_time 更新时间 crowd_tags_detail（人群标签明细） 字段名 说明 id 自增ID tag_id 人群ID user_id 用户ID create_time 创建时间 update_time 更新时间 crowd_tags_job（人群标签任务） 字段名 说明 id 自增ID tag_id 标签ID batch_id 批次ID tag_type 标签类型（参与量、消费金额） tag_rule 标签规则（限定类型 N次） stat_start_time 统计数据开始时间 stat_end_time 统计数据结束时间 status 状态（0初始、1计划、2重置、3完成） create_time 创建时间 update_time 更新时间 sc_sku_activity（渠道商品活动配置关联表） 字段名 说明 id 自增ID source 渠道 channel 来源 activity_id 活动ID goods_id 商品ID create_time 创建时间 update_time 更新时间 sku（商品信息） 字段名 说明 id 自增ID source 渠道 channel 来源 goods_id 商品ID goods_name 商品名称 original_price 商品价格 create_time 创建时间 update_time 更新时间 DDD架构设计 MVC架构： DDD架构： 价格试算与人群标签 活动是否允许用户参与，拼团的判断逻辑有两重，具体条件如下： 活动是否设置了 tag_scope tag_scope 用于限制活动参与的范围。若活动未设置 tag_scope，则默认认为没有任何限制，所有用户均可参与拼团；若配置了 tag_scope，则需要根据该配置进一步判断用户是否符合参与条件。 用户是否在指定的人群标签 tag_id 范围内 tag_id 指定了本次活动的参与人群，只有拥有该标签的人群才能参与活动（具体逻辑就是每个tagid的位图里存了很多userid，只有这些userid才能参与）。如果活动未配置 tag_id，则默认所有用户都可参与拼团。需要注意的是，在本项目的实现中，虽然活动配置了 tag_id，但由于位图（bitmap）未进行配置，实际上也是默认所有用户均可参与拼团。 ps：这里只校验用户是否有参与活动的资格！！！ 后续还有锁单的校验，注意区分，锁单是基于这里的资格判断之后的，再去此时活动是否仍有效、用户参与拼团次数是否已达上限... 价格试算 @Service @RequiredArgsConstructor public class IndexGroupBuyMarketServiceImpl implements IIndexGroupBuyMarketService { private final DefaultActivityStrategyFactory defaultActivityStrategyFactory; @Override public TrialBalanceEntity indexMarketTrial(MarketProductEntity marketProductEntity) throws Exception { StrategyHandler<MarketProductEntity, DefaultActivityStrategyFactory.DynamicContext, TrialBalanceEntity> strategyHandler = defaultActivityStrategyFactory.strategyHandler(); TrialBalanceEntity trialBalanceEntity = strategyHandler.apply(marketProductEntity, new DefaultActivityStrategyFactory.DynamicContext()); return trialBalanceEntity; } } IndexGroupBuyMarketService │ │ indexMarketTrial() ▼ DefaultActivityStrategyFactory │ (return rootNode) ▼ RootNode.apply() │ doApply() (执行) │ router() （路由到下一node） ▼ SwitchNode.apply() │ ... ▼ ... (可能还有其他节点) ▼ EndNode.apply() → 组装结果并返回 TrialBalanceEntity ▲ └────────── 最终一路向上 return IndexGroupBuyMarketService 是领域服务，整个价格试算的入口 DefaultActivityStrategyFactory 帮你拿到 根节点，真正的“工厂”工作（多线程预处理、分支路由）都在各 Node 里完成。 DynamicContext 是一次性创建的共享上下文：谁需要谁就往里放 目前项目中是单策略模式，即满减、直减这些优惠N选一；后期可扩展成组合策略，实现方式： 1.简单点就是每种组合单独定义一个组合策略，比如“满减 + 直减”： @Service("MJ_COUPON") public class MJCouponCalculateService extends AbstractDiscountCalculateService { @Resource private MJCalculateService mjCalculateService; @Resource private CouponCalculateService couponCalculateService; @Override public BigDecimal doCalculate(BigDecimal originalPrice, GroupBuyActivityDiscountVO.GroupBuyDiscount groupBuyDiscount) { // 先满减 BigDecimal afterMJ = mjCalculateService.doCalculate(originalPrice, groupBuyDiscount); // 再优惠券 return couponCalculateService.doCalculate(afterMJ, groupBuyDiscount); } } 但是如果以后有更多组合（比如“满减+直减+优惠券”），会出现类爆炸。 2.动态策略配置，比如：["MJ", "COUPON"]。 写一个通用的 CompositeDiscountService，按照配置顺序，依次执行每个基础策略： public class CompositeDiscountService extends AbstractDiscountCalculateService { private final List<IDiscountCalculateService> strategies; @Override public BigDecimal doCalculate(BigDecimal originalPrice, GroupBuyActivityDiscountVO.GroupBuyDiscount discount) { BigDecimal price = originalPrice; for (IDiscountCalculateService s : strategies) { price = s.calculate("userId", price, discount); } return price; } } 如何配置多种策略？？？ （1）规则优先级配置（非动态计算） 运营预先定义策略顺序：例如强制规定 满减 → 直减 → 折扣，避免计算所有排列组合。优点：性能高（O(n)），规则可控。适用场景：优惠策略较少或业务方明确要求顺序。 （2）动态计算最优解 有限枚举 + 剪枝优化，仅对允许叠加的策略枚举顺序，并通过规则提前排除无效组合（如互斥优惠）。 优点：灵活性高，用户获利最大化。 假设总价 300元，可用优惠： 满 200减 50. 满 300打 8折. 直减 20元 1. 满减 → 折扣 : (300-50)*0.8 = 200 2. 满减 → 直减 : (300-50)-20 = 230 3. 折扣 → 满减 : (300 * 0.8)-50 = 190 ← 最优 4. 折扣 → 直减 : (300 * 0.8)-20 = 220 5. 直减 → 满减 : (300-20) → 不满200，满减不生效 → 280 6. 直减 → 折扣 : (300-20)*0.8 = 224 （3）分层优惠 总价 │ ├─ 第一阶段：全局优惠（如全场8折） │ ├─ 第二阶段：品类优惠（如家电满1000减100） │ └─ 第三阶段：单品优惠（如A商品直降50） 人群标签 人群标签采集 步骤 目的 说明 1. 记录日志 标明本次批次任务的开始 方便后续排查、链路追踪 2. 读取批次配置 拿到该批次统计范围、规则、时间窗等 若返回 null 通常代表批次号错误或已被清理 3. 采集候选用户 从业务数仓/模型结果里拉取符合条件的用户 ID 列表 真实场景中会：• 调 REST / RPC 拿画像• 或扫离线结果表• 或读 Kafka 流 4. 双写标签明细 将每个用户与标签的关系永久化 & 提供实时校验能力 方法内部两件事：• 插入 crowd_tags_detail 表• 在 Redis BitMap 中把该用户对应位设为 1（幂等处理冲突） 5. 更新统计量 维护标签当前命中人数，用于运营看板 这里简单按“新增条数”累加，也可改为重新 count(*) 全量回填 6. 结束 方法返回 void 如果过程抛异常，调度系统可重试/报警 一句话总结 这是一个被定时器或消息触发的离线批量打标签任务： 拉取任务规则 → （离线）筛出符合条件的用户 → 写库 + 写 Redis 位图 → 更新命中人数。 之后业务系统就能用位图做到毫秒级 isUserInTag(userId, tagId) 判断，实现精准运营投放。 Bitmap（位图） 概念 Bitmap 又称 Bitset，是一种用位（bit）来表示状态的数据结构。 它把一个大的“布尔数组”压缩到最小空间：每个元素只占 1 位，要么 0（False）、要么 1（True）。 为什么用 Bitmap？ 超高空间效率：1000 万个用户，只需要约 10 MB（1000 万 / 8）。 超快操作：检查某个索引位是否为 1、计数所有“1”的个数（BITCOUNT）、找出第一个“1”的位置（BITPOS）等，都是 O(1) 或者极快的位运算。 典型场景 用户标签 / 权限判断：把符合某个条件的用户的索引位置设置为 1，以后实时判断“用户 X 是否在标签 A 中？”就只需读一个 bit。 海量去重 / 布隆过滤器：在超大流量场景下判断“URL 是否已访问过”、“手机号是否已注册”等。 统计分析：快速统计某个条件下有多少个用户／对象符合（BITCOUNT）。 示例： default int getIndexFromUserId(String userId, int bitmapSize) { try { MessageDigest md = MessageDigest.getInstance("MD5"); byte[] hashBytes = md.digest(userId.getBytes(StandardCharsets.UTF_8)); BigInteger bigInt = new BigInteger(1, hashBytes); return bigInt.mod(BigInteger.valueOf(bitmapSize)).intValue(); } catch (NoSuchAlgorithmException e) { throw new RuntimeException("MD5 algorithm not found", e); } } int index = getIndexFromUserId(uuid, 10_000_000); // 1千万位的bitmap 输入：userId = "abcd-1234" MD5（十六进制）：E2FC714C4727EE9395F324CD2E7F331F 可以当做128位的无符号整数，假设是bigInt =302349823749823749823749823 bitmapSize=10000 那么index=bigInt % 10000 = 9823 Bitmap 的存储方式 bitmap.set(123) 的含义就是把 第 123 位 (bit) 标记为 1。 在底层实现上，Bitmap 通常用一段连续的二进制数组（比如 int[] 或 byte[]）来存储： 如果用 int 数组存储：每个 int 占 32 bit（在 Java/C++ 等语言里）。 第 123 个 bit 属于第 123 / 32 = 3 个整型元素（下标从 0 开始）。 在这个元素里具体是哪一位呢？就是 123 % 32 = 27 这位。 所以实际上是 array[3] 的第 27 个 bit 被置 1。 如果用 byte 数组存储：每个 byte 占 8 bit。 第 123 个 bit 属于第 123 / 8 = 15 个字节。 在这个字节里具体位置是 123 % 8 = 3。 所以是 array[15] 的第 3 位被置 1。 布隆过滤器 核心思想：用 多个哈希函数 来降低冲突。 具体做法： 对 userId 用 k 个不同的 hash 函数（可以是 MD5 的不同切片、或 MurmurHash 等）。 得到 k 个位置，把这些位置的 bit 全部设为 1。 判断存在性时，只要这 k 个位置都为 1，就认为“可能存在”；只要有一个为 0，就一定不存在。 这样虽然依然有假阳性（可能存在其实不存在），但概率大大降低。 判断是否是否存在，如果任意一个bit=0 =》一定不存在；如果所有bit=1=》可能存在。 人群标签过滤 白名单。 无 tagId（没配标签）→ 不限人群，全部放行（visible=true, enable=true）。 有 tagId 且位图存在 → 位图里的人可以参加（白名单）。 有 tagId 但位图不存在 → 现在的实现是默认全放行（把“未配置位图”当作“不限制”），因为真实场景中由外部系统统计用户行为=>将符合条件的用户放入位图中，这里暂时没有模拟。 动态降级与人群切量 downgradeSwitch —— 降级开关 作用：在出现异常或高压场景时，主动关闭部分功能，保证核心流程可用。 值为 0（默认）：功能正常，系统按照全量逻辑执行。 值为 1：开启降级，比如： 关闭一些非核心功能（如推荐、统计、日志落库）。 使用兜底方案（如直接返回默认值、提示“稍后再试”）。 cutRange —— 人群切量开关 作用：做灰度发布或分流测试，让不同用户群体验不同的功能版本。 默认值为 100：表示 100% 用户都可用，即全量发布。 如果设置为 30：就表示 只有 30% 的用户能进入新功能，其他 70% 用户还是老逻辑。 计算逻辑：对用户 ID 做哈希，取模 100，落在 [0, cutRange] 范围内的用户通过。 public boolean isCutRange(String userId) { // 计算哈希码的绝对值 int hashCode = Math.abs(userId.hashCode()); // 获取最后两位 int lastTwoDigits = hashCode % 100; // 判断是否在切量范围内 // 在范围内，可以继续参加活动 if (lastTwoDigits <= Integer.parseInt(cutRange)) { return true; } return false; } 不要直接对用户 ID 取模，因为可能是String类型的。 拼团交易锁单 下单到支付中间有一个流程，即锁单，比如淘宝京东中，在这个环节（限定时间内）选择使用优惠券、京豆等，可以得到优惠价，再进行支付；拼团场景同理，先加入拼团，进行锁单，然后优惠试算，最后才付款。 锁单流程： 1.幂等查询，如果已有一模一样的锁单，直接返回该条记录； 2.拼团人数校验（前端显示有滞后性，在调用锁单接口的时候还要重新拉取一下） 3.优惠试算，查看拼团活动配置信息（优惠价、目标人群、活动有效期、最大参与次数...）。 4.人群限定，非目标人群不允许参与活动 5.锁单责任链 活动有效性 用户参与次数 剩余库存校验 拼团结算 结算规则过滤：SC渠道拦截、外部交易单号交易、结算时间校验（now小于拼团结束时间） 对接商城和拼团系统 下单总体流程 查询商品并初始化订单 查询商品信息，构建订单，填入 total_amount，此时订单状态为 PAY_CREATE。 判断订单类型 普通下单：直接进入预支付流程。 拼团下单/开团：远程调用拼团系统，执行锁单逻辑（活动校验、库存校验、优惠计算等）。 生成预支付订单 根据订单类型决定支付金额： 普通单：按商品原价。 拼团单：按优惠后价格。 创建支付单，填入 pay_amount、pay_url 等信息，订单状态置为 PAY_WAIT。 等待支付回调 用户扫码/支付成功后，支付平台回调商城接口，更新订单状态。 超时未支付订单由调度任务关闭。 具体业务步骤 1. 用户下单 如果用户已存在未支付订单： 且有支付链接（pay_url） → 直接返回支付链接。 没有支付链接 → 进入支付单创建流程。 否则，进入新订单创建。 2. 创建订单 查询商品信息并保存新订单（状态 PAY_CREATE）。 若为拼团单（marketType == GROUP_BUY_MARKET），调用拼团系统执行 营销锁单 校验活动有效性 校验用户参与次数 校验剩余库存 优惠试算 记录拼团锁单结果（订单号、折扣金额等） 普通订单跳过营销锁单。 3. 创建预支付单 拼团单：根据优惠结果生成预支付订单。 普通单：直接用原价生成预支付订单。 更新订单状态为 PAY_WAIT，返回支付链接。 支付完成与组队结算 1.支付回调 更新订单状态 触发“支付结算并发货”流程 2.组队结算判断 调用拼团营销系统组队结算接口，更新当前拼团完成人数 判断该拼团是否已完成： 是： 调用营销结算 HTTP 接口 结算完成 N 个用户组成的队伍 发送“组队完成回调通知” 否：直接结束流程 3.后续发货 当收到拼团完成（complete_count==target_count）的回调消息时，小型商城执行后续交易结算及发货逻辑（目前是模拟触发的）。 注意 alipay_notify_url 作用：支付宝在用户支付成功后，向该地址发起服务器端回调（需公网可访问，或通过内网穿透映射到本地）。 调用流程：支付宝 → pay-mall 用途：pay-mall 接收到支付成功通知后，可以调用拼团组队结算接口。 与之相关的两个地址： return_url：用户付款后网页自动跳转的地址（通常是返回商城首页），属于前端页面跳转，与业务结算无关。 gateway_url：支付宝提供的商户收款页面地址（用户发起付款时访问）。 group-buy-market_notify_url http://127.0.0.1:8092/api/v1/alipay/group_buy_notify 注意！HTTP调用下才使用，MQ这个字段失效！ 作用：由 pay-mall 商城设置，作为拼团平台的回调地址。 调用流程：拼团平台（group-buy-market） → pay-mall 触发条件：某个 teamId 的拼团人数达到目标值，拼团成功。 用途：通知 pay-mall 对该 teamId 下所有成员执行后续操作，例如发货。 本地对接 在 group-buying-sys 项目中，对 group-buying-api 模块执行 mvn clean install（或在 IDE 中运行 install）。这会将该模块的 jar 安装到本地 Maven 仓库（~/.m2/repository）。然后在 pay-mall 项目的 pom.xml 中添加依赖，使用相同的 groupId、artifactId 和 version 即可引用该模块，如下所示： <dependency> <groupId>edu.whut</groupId> <artifactId>group-buying-api</artifactId> <version>1.0.0-SNAPSHOT</version> </dependency> 发包 仅适用于本地，共用一个本地Maven仓库，一旦换台电脑或者在云服务器上部署，无法就这样引入，因此可以进行发包。这里使用阿里云效发包https://packages.aliyun.com/ 1）点击制品仓库->生产库 2）下载settings-aliyun.xml文件并保存至本地的Maven的conf文件夹中。 3） 配置项目的Maven仓库为阿里云提供的这个，而不是自己的本地仓库。 4）发包，打开Idea中的Maven，双击deploy 5）验证 6）使用 将公共镜像仓库的settings文件和阿里云效的settings文件合并，可以同时拉取公有依赖和私有包。 逆向工程：退单 逆向的流程，要分析用户是在哪个流程节点下进行退单行为。包括3个场景； 已锁单、未支付：redis恢复量+1，mysql中锁单量-1 已锁单、已支付，但拼团未成团：redis恢复量+1，mysql中锁单量、完成量-1，退款 已锁单、已支付，且拼团已成团：redis恢复量无需+1，因为成团之后不开放给别人；mysql中锁单量、完成量-1，退款，拼团设置为'已完成含退单'状态，但拼团中所有人都退单，更新为失败！ 核心流程说明 阶段一：退单操作流程 客户主动提交退单请求 通过责任链模式处理：数据加载Node（查询订单） → 重复检查Node（防止重复退单） → 策略执行Node 策略选择 根据订单状态和拼团状态选择对应退单策略（三种之一） 执行退单 更新数据库操作（锁单量、完成量、拼团状态、订单状态...） 消息通知 + 任务补偿 发送MQ退单消息通知（未支付退单、已支付未成团...三种消息 notify_category） 将消息写入notify_task表，定时任务扫描未成功处理的消息，以做补偿兜底。 阶段二：库存恢复流程 消息监听 MQ监听器接收退单成功消息 服务调用 调用恢复库存服务 策略选择 根据退单类型选择对应策略（已成团的无需恢复了，反正新用户也无法再参与该拼团） 库存恢复 执行Redis库存恢复操作（带分布式锁保护） 设计模式应用 责任链模式 TradeRefundRuleFilterFactory 构建的过滤链： DataNodeFilter → UniqueRefundNodeFilter → RefundOrderNodeFilter 策略模式 策略接口：RefundOrderStrategy 实现策略： Unpaid2RefundStrategy（未付款退单的流程） Paid2RefundStrategy（已付款退单） PaidTeam2RefundStrategy（已成团退单） 工厂模式 TradeRefundRuleFilterFactory 负责组装责任链 模板方法模式 AbstractRefundOrderStrategy 提供： 公共方法封装 （发送退单MQ消息、库存恢复redis） 依赖注入支持 退单触发入口 1）用户主动退单 2）定时任务，定时任务扫描锁单但未结算的订单，若支付时间超过设定值，对这笔订单执行退单操作。 注意：小型支付商城中的订单可能有些是普通订单，有些是拼团订单。 对于普通订单，无需调用拼团系统中的退单接口，自己本地退单，对于CREATE或PAY_WAIT状态的订单，直接修改订单状态为CLOSED；对于PAY_SUCCESS（个人支付完成）、DEAL_DONE，额外调用支付宝退款。 对于拼团订单，RPC调用拼团系统的退单接口，调用成功后设置订单为WAIT_REFUND，然后由MQ消息回调调用支付宝退款。 定时任务+MQ消息通知 定时任务 拼团营销系统： 1.MQ消息补偿，每天零点执行一次（暂定） //每天零点执行一次 @Scheduled(cron = "0 0 0 * * ?") public void exec() { // 为什么加锁？分布式应用N台机器部署互备（一个应用实例挂了，还有另外可用的），任务调度会有N个同时执行，那么这里需要增加抢占机制，谁抢占到谁就执行。完毕后，下一轮继续抢占。 // 获取锁句柄，并未真正获取锁 RLock lock = redissonClient.getLock("group_buy_market_notify_job_exec"); try { //尝试获取锁 waitTime = 3:如果当前锁已经被别人持有，调用线程最多等待 3 秒去重试获取; // leaseTime = 0:不设过期时间，看门狗机制 boolean isLocked = lock.tryLock(3, 0, TimeUnit.SECONDS); if (!isLocked) return; Map<String, Integer> result = tradeTaskService.execNotifyJob(); log.info("定时任务，回调通知完成 result:{}", JSON.toJSONString(result)); } catch (Exception e) { log.error("定时任务，回调通知失败", e); } finally { if (lock.isLocked() && lock.isHeldByCurrentThread()) { lock.unlock(); } } } 2.超时未支付订单扫描，每隔5分钟执行一次；主要就是营销锁单了，但是15分之内还没付款，自动调用退单逻辑，释放锁单量，然后发退单的MQ消息。 小型支付商城： 1.支付宝回调补偿，未支付订单扫描，每隔10秒调用一次支付宝的接口，查询某未支付的订单到底付了没有，如果付了，则更新订单状态。主要是为了防止用户付了钱，但是由于网络波动，导致支付宝调用系统的回调接口失败，做的一次补偿动作。 2.超时订单扫描，每3分钟执行一次，对于超过15分钟仍未付款的订单，将其关闭。 待优化：将定时轮询查询改为在每个用户下单时发一个延迟消息的事件触发方式。 特性 定时轮询查询 延迟消息（事件触发） 优胜方 实时性 差（取决于轮询间隔，如1分钟） 高（理论上精确到秒） 延迟消息 数据库压力 巨大（高频扫描全表） 极小（只查单条记录） 延迟消息 可靠性 高（逻辑简单，不易丢单） 中（依赖MQ的可靠性） 定时轮询 扩展性 差（订单量越大，性能越差） 好（天然分布式，随订单量线性扩展） 延迟消息 复杂度 低（实现简单） 中（需引入和维护MQ） 定时轮询 资源利用率 低（大量无效查询） 高（按需触发，无浪费） 延迟消息 MQ消息 有三种MQ消息： 1.退款成功通知 2.拼团组队成功通知 3.订单支付成功消息 退款成功消息：拼团系统发送，拼团订单。拼团系统发送，小型商城和拼团系统都接收，各自执行退单流程。 组队成功消息：拼团系统发送，拼团订单。拼团系统发送，小型商城和拼团系统都接收，小型商城更新订单状态；拼团系统仅仅是简单的打印一下'通知成功'消息。 订单支付成功消息：小型商城发送，普通订单则用户支付后的回调就发送；拼团订单则是先接到'组队成功消息'之后 再发MQ。小型商城接收，更新订单状态为模拟发货。 这里主要起到解耦的作用，将发货这个过程解耦。 不仅在相关接口完成的时候自动发送MQ消息，同时有兜底，将MQ消息持久化进Mysql，设置定时任务来扫描表，对暂未处理（处理失败）的MQ消息重新投递。 字段名 类型 允许为空 默认值 约束 / 备注 id int UNSIGNED NO AUTO_INCREMENT 自增ID，主键 activity_id bigint NO 活动ID team_id varchar(8) NO 拼单组队ID notify_category varchar(64) YES NULL 回调种类 notify_type varchar(8) NO 'HTTP' 回调类型（HTTP、MQ） notify_mq varchar(32) YES NULL 回调消息 notify_url varchar(128) YES NULL 回调接口 notify_count int NO 回调次数 notify_status tinyint(1) NO 回调状态【0 初始、1 完成、2 重试、3 失败】 parameter_json varchar(256) NO 参数对象（JSON 字符串） uuid varchar(128) NO 唯一标识 create_time datetime NO CURRENT_TIMESTAMP 创建时间 update_time datetime NO CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP 更新时间 如何确保MQ消息持久化成功？ // 4. 更新数据库，拼团交易结算，若达到拼团人数，返回notifyTaskEntity发送回调通知，否则返回null不做处理 NotifyTaskEntity notifyTaskEntity =repository.settlementMarketPayOrder(groupBuyTeamSettlementAggregate); // 5. 组队回调处理 - 处理失败也会有定时任务补偿，通过这样的方式，可以减轻任务调度，提高时效性 if (null != notifyTaskEntity) { threadPoolExecutor.execute(() -> { Map<String, Integer> notifyResultMap = null; try { notifyResultMap = tradeTaskService.execNotifyJob(notifyTaskEntity); log.info("回调通知拼团完结 result:{}", JSON.toJSONString(notifyResultMap)); } catch (Exception e) { log.error("回调通知拼团完结失败 result:{}", JSON.toJSONString(notifyResultMap), e); throw new AppException(e.getMessage()); } }); } 在拼团支付成功后的结算过程中（repository.settlementMarketPayOrder），所有数据库操作（更新状态、更新拼团人数、持久化拼团成功消息）都被包含在一个事务内。通过 @Transactional 注解保证了事务的一致性，确保了操作的原子性。 如果任何步骤失败，事务会回滚，数据保持一致。 repository.settlementMarketPayOrder 执行失败的话，后面也不会发送MQ消息了。 如果操作是幂等的，并且失败是由于 暂时性故障（如数据库连接失败、网络问题等），那么可以引入 重试机制 来增加系统的容错性。 如何衡量消息是否成功发送？ private Map<String, Integer> execNotifyJob(List<NotifyTaskEntity> notifyTaskEntityList) throws Exception { //successCount:成功回调的任务数量 int successCount = 0, errorCount = 0, retryCount = 0; for (NotifyTaskEntity notifyTask : notifyTaskEntityList) { // HTTP模式下回调小商城中的groupBuyNotify接口 success 成功，error 失败 String response = port.groupBuyNotify(notifyTask); // 更新状态判断&变更数据库表回调任务状态 if (NotifyTaskHTTPEnumVO.SUCCESS.getCode().equals(response)) { int updateCount = repository.updateNotifyTaskStatusSuccess(notifyTask); if (1 == updateCount) { successCount += 1; } } else if (NotifyTaskHTTPEnumVO.ERROR.getCode().equals(response)) { if (notifyTask.getNotifyCount() < 5) { // 失败但可以重试 → 标记为 RETRY，等待下一次收集 “待处理的通知任务列表” if (repository.updateNotifyTaskStatusRetry(notifyTask) == 1) { retryCount++; } } else { // 已达最大重试次数 → 标记为 ERROR（不再重试） if (repository.updateNotifyTaskStatusError(notifyTask) == 1) { errorCount++; } } } } 目前逻辑比较简单，只能确保消息发送出去了，如果为了提高安全性，还需要： 1.发送方确认机制（ConfirmCallback、returnCallback） 2.消费方确认机制，比如把auto ACK改为manul ACK，配置无状态重试/有状态重试（需要对消息做幂等性处理），超过最大重试次数的消息进入死信队列中，等待人工审查。 3.消费方成功收到消息并将消息表中的对应消息的status设置为'已完成'，而不是发送者来写。 收获 实体对象 实体是指具有唯一标识的业务对象。 在 DDD 分层里，Domain Entity ≠ 数据库 PO。 在 edu.whut.domain.*.model.entity 包下放的是纯粹的业务对象，它们只表达业务语义（团队 ID、活动时间、优惠金额……），对「数据持久化细节」保持无感知。因此它们看起来“字段不全”是正常的： 它们不会带 @TableName / @TableId 等 MyBatis-Plus 注解； 也不会出现数据库的技术字段（id、create_time、update_time、status 等）； 只保留聚合根真正需要的业务属性与行为。 @Data @Builder @AllArgsConstructor @NoArgsConstructor public class PayActivityEntity { /** 拼单组队ID */ private String teamId; /** 活动ID */ private Long activityId; /** 活动名称 */ private String activityName; /** 拼团开始时间 */ private Date startTime; /** 拼团结束时间 */ private Date endTime; /** 目标数量 */ private Integer targetCount; } 这个也是实体对象，因为多个字段的组合： teamId 和 activityId 能唯一标识这个实体。 多线程异步调用 如果某任务比较耗时（如加载大量数据），可以考虑开多线程异步调用。 // Runnable ➞ 只能 run()，没有返回值 public interface Runnable { void run(); } // Callable<V> ➞ call() 能返回 V，也能抛检查型异常 public interface Callable<V> { V call() throws Exception; } public class MyTask implements Callable<String> { private final String name; public MyTask(String name) { this.name = name; } @Override public String call() throws Exception { // 模拟耗时操作 TimeUnit.MILLISECONDS.sleep(300); return "任务[" + name + "]的执行结果"; } } public class SimpleAsyncDemo { public static void main(String[] args) { // 创建大小为 2 的线程池 ExecutorService pool = Executors.newFixedThreadPool(2); try { // 构造两个任务 MyTask task1 = new MyTask("A"); MyTask task2 = new MyTask("B"); // 用 FutureTask 包装 Callable FutureTask<String> future1 = new FutureTask<>(task1); FutureTask<String> future2 = new FutureTask<>(task2); // 提交给线程池异步执行 pool.execute(future1); pool.execute(future2); // 主线程可以先做别的事… System.out.println("主线程正在做其他事情…"); // 在需要的时候再获取结果（可加超时） String result1 = future1.get(1, TimeUnit.SECONDS); //设置超时时间1秒 String result2 = future2.get(); //无超时时间 System.out.println("拿到结果1 → " + result1); System.out.println("拿到结果2 → " + result2); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } catch (ExecutionException e) { System.err.println("任务执行中出错: " + e.getCause()); } catch (TimeoutException e) { System.err.println("等待结果超时"); } finally { pool.shutdown(); } } } 动态配置（热更新） BeanPostProcessor 是 Spring 提供的一个扩展接口，用来在 Spring 容器实例化 Bean（并完成依赖注入）之后，但 在调用 Bean 的初始化方法之前或之后，对 Bean 进行额外的加工处理。 Spring 容器启动时会扫描并实例化所有实现了 BeanPostProcessor 接口的 Bean，然后在Bean 初始化阶段前后依次调用它们的 postProcessBeforeInitialization 和 postProcessAfterInitialization 方法。 postProcessAfterInitialization返回你修改之后的bean实例。 **原理：**利用 Redis 的发布/订阅（Pub/Sub）机制，在程序运行时动态推送配置变更通知，订阅者接收到消息后更新相应的 Bean 字段。通过 反射（Reflection API） 可以 动态修改运行中的对象实例的字段值。 实现步骤 注解标记 用 @DCCValue("key:default") 标注需要动态注入的字段，指定 Redis Key 和默认值。 // 标记要动态注入的字段 @Retention(RUNTIME) @Target(FIELD) public @interface DCCValue { String value(); // "key:default" } // 业务使用示例 @Service public class MyFeature { @DCCValue("myFlag:0") //标注字段，默认值为0 private String myFlag; public boolean enabled() { return "1".equals(myFlag); } } 启动时注入 实现 BeanPostProcessor，覆写postProcessAfterInitialization方法，在每个 Spring Bean 初始化后自动执行： 扫描标注了 @DCCValue 的字段； 拼接完整 Redis Key，若 Redis 中没有配置，则写入默认值（即@DCCValue注解上的值）； 通过反射将配置值注入到 Bean 的字段； 将配置与 Bean 映射关系存入本地HashMap，以便后续热更新。 @Override public Object postProcessAfterInitialization(Object bean, String name) { private final Map<String, Object> dccObjGroup = new HashMap<>(); Class<?> cls = AopUtils.isAopProxy(bean) ? AopUtils.getTargetClass(bean) : bean.getClass(); for (Field f : cls.getDeclaredFields()) { DCCValue dccValue = f.getAnnotation(DCCValue.class); if (dccValue != null) { String[] parts = dccValue.value().split(":"); String key = PREFIX + parts[0]; // Redis 中存储的 Key String defaultValue = parts[1]; // 默认值 RBucket<String> bucket = redis.getBucket(key); String value = bucket.isExists() ? bucket.get() : defaultValue; bucket.trySet(defaultValue); // 若 Redis 中无配置，则写入默认值 injectField(bean, f, value); // 通过反射注入值 dccObjGroup.put(key, bean); // 缓存配置与 Bean 映射关系 } } return bean; // 返回初始化后的 Bean } 运行时热更新 订阅一个 Redis Topic（频道），比如 "dcc_update"； 外部通过发布接口 PUBLISH dcc_update "key,newValue" 发送更新消息； private final RTopic dccTopic; @GetMapping("/dcc/update") public void update(@RequestParam String key, @RequestParam String value) { // 发布配置更新消息到 Redis 主题，格式为 "configKey,newValue" String message = key + "," + value; dccTopic.publish(message); // 通过 dccTopic 发布更新消息 log.info("配置更新发布成功 - key: {}, value: {}", key, value); } 订阅者收到后： 更新 Redis 中的配置； 从映射里取出对应 Bean，使用反射更新字段。 // 发布/订阅配置热更新 @Bean("dccTopic") public RTopic dccTopic(RedissonClient redis) { RTopic dccTopic = redis.getTopic("dcc_update"); dccTopic.addListener(String.class, (channel, msg) -> { String[] parts = msg.split(","); // msg 约定格式："configKey,newValue" String key = PREFIX + parts[0]; // 拼接 Redis Key String newValue = parts[1]; // 新的配置值 RBucket<String> bucket = redis.getBucket(key); if (!bucket.isExists()) { return; // 如果不是我们关心的配置，跳过 } bucket.set(newValue); // 更新 Redis 中的配置 Object bean = beans.get(key); // 从内存中取出 Bean 实例 if (bean != null) { injectField(bean, parts[0], newValue); // 通过反射更新 Bean 字段 } }); return dccTopic; // 返回 Redis Topic 实例 } 在 Redis 的发布/订阅模型中，RTopic dccTopic = redis.getTopic("dcc_update"); 这行代码指定了 dccTopic 订阅的主题（也可以理解为一个消息通道）。不同的类可以通过依赖注入来使用这个 RTopic 实例。一些类可以调用 dccTopic.publish(message) 向该通道发送消息；而另一些类则可以通过 dccTopic.addListener() 来订阅该主题，从而接收消息并进行相应的处理。 面试官：为什么选择Redis Pub/Sub，不用rabbitmq？ 两者都能实现这个需求，但 Redis 更轻量。在多实例部署时，每个实例都能收到广播并通过反射完成热更新；如果某个节点宕机重启，它会直接从 Redis 中拉取最新配置，而不依赖历史广播。 确实，Redis Pub/Sub 没有消息确认等可靠性机制；如果换成 RabbitMQ，配置交换机为广播模式，各实例使用匿名队列，同样可以接收消息并完成更新，而且还能提供更强的可靠性保证。不过在本项目中，动态配置中心在初期就基于 Redis 实现了，RabbitMQ 是在后期做交易领域时才引入的组件。考虑到场景对可靠性要求不高，同时也为了保持架构的简单性，所以没有替换为 RabbitMQ。 热更新数据流转过程 1.广播消息（PUBLISH）：配置变更会通过 PUBLISH 命令广播到 Redis 中的某个主题。 2.Redis Sub（订阅）：订阅该主题的客户端收到消息后，进行处理。 3.更新 Redis 和 Bean 字段： 更新 Redis 中的配置（保持一致性）。 更新 Bean 实例的对应字段（通过反射，确保配置的实时性）。 重要说明 RedissonClient（ Redis）的作用： 1.消息广播（通过 Topic） 2.redis中的配置与bean中的字段配置一致，有一定容错 / 恢复能力，如果某个节点启动时错过了消息，它可以在初始化时直接从 Redis 读到最新配置。 HashMap的作用： 在广播监听阶段，快速获取要操作的bean实例，进行反射。 OkHttpClient+Retrofit 1.引入依赖 <dependency> <groupId>com.squareup.okhttp3</groupId> <artifactId>okhttp</artifactId> <version>4.12.0</version> </dependency> <dependency> <groupId>com.squareup.retrofit2</groupId> <artifactId>retrofit</artifactId> <version>2.11.0</version> </dependency> <dependency> <groupId>com.squareup.retrofit2</groupId> <artifactId>converter-jackson</artifactId> <version>2.11.0</version> </dependency> 2.配置 OkHttpClient @Configuration public class OkHttpClientConfig { @Bean public OkHttpClient okHttpClient() { return new OkHttpClient.Builder() .connectTimeout(Duration.ofSeconds(10)) .readTimeout(Duration.ofSeconds(30)) .writeTimeout(Duration.ofSeconds(30)) .retryOnConnectionFailure(true) // TODO: 可以统一加日志拦截器、鉴权拦截器 .build(); } } 单例复用：Spring 管理 Bean，整个应用只创建一次。 集中配置：超时、拦截器、SSL 等只在这里写一份，避免代码里到处 new。 3.配置Retrofit @Configuration public class RetrofitConfig { private static final String BASE_URL = "https://api.example.com/"; @Bean public Retrofit retrofit(OkHttpClient okHttpClient) { return new Retrofit.Builder() .baseUrl(BASE_URL) .client(okHttpClient) // 🔑 复用统一的 OkHttpClient .addConverterFactory(JacksonConverterFactory.create()) .build(); } @Bean public ApiService apiService(Retrofit retrofit) { return retrofit.create(ApiService.class); } } 4.定义 API 接口（Retrofit 风格） public interface ApiService { @GET("users/{id}") Call<User> getUser(@Path("id") String id); @POST("orders") Call<OrderResponse> createOrder(@Body OrderRequest request); } 5.在 Service 中调用 @Slf4j @Service @RequiredArgsConstructor public class UserService { private final ApiService apiService; // 同步请求 public User getUserById(String id) { try { Response<User> resp = apiService.getUser(id).execute(); if (resp.isSuccessful()) { return resp.body(); } throw new RuntimeException("请求失败，HTTP " + resp.code()); } catch (Exception e) { log.error("获取用户信息失败", e); throw new RuntimeException(e); } } // 异步请求 public void getUserAsync(String id) { apiService.getUser(id).enqueue(new Callback<User>() { @Override public void onResponse(Call<User> call, Response<User> response) { log.info("异步回调结果: {}", response.body()); } @Override public void onFailure(Call<User> call, Throwable t) { log.error("异步请求失败", t); } }); } } Retrofit 在运行时会生成这个接口的实现类，帮你完成： 拼 URL（把 {id} 换成具体值） 发起 GET 请求 拿到响应的 JSON 并自动反序列化成 User 对象 OkHttp 提供底层能力：连接池、超时、拦截器、HTTP/2 等，适合做全局单例配置。 特点/场景 Retrofit RPC（如 gRPC、Dubbo 等） 主要用途 封装 HTTP API 调用，集成第三方服务 微服务之间的内部通信 协议层 基于 HTTP/HTTPS（REST 风格） 基于 TCP/HTTP2，自定义协议或 Protobuf 数据序列化 JSON（默认） Protobuf / Thrift / Avro（更高效） 典型应用场景 第三方 REST API、外部服务调用 微服务架构、跨语言调用、内部高性能通信 调用方式 支持同步/异步，声明式接口 支持同步/异步、流式调用，多语言 SDK 性能特点 依赖 HTTP/JSON，序列化开销较大 高吞吐量、低延迟，序列化高效 易用性 简单，代码少，学习成本低 需要服务框架支持，学习/配置成本较高 支付宝下单沙箱 https://open.alipay.com/develop/sandbox/app 读取本地配置文件。 @Data @Component @ConfigurationProperties(prefix = "alipay", ignoreInvalidFields = true) public class AliPayConfigProperties { // 「沙箱环境」应用ID - 您的APPID，收款账号既是你的APPID对应支付宝账号。获取地址；https://open.alipay.com/develop/sandbox/app private String appId; // 「沙箱环境」商户私钥，你的PKCS8格式RSA2私钥 private String merchantPrivateKey; // 「沙箱环境」支付宝公钥 private String alipayPublicKey; // 「沙箱环境」服务器异步通知页面路径 private String notifyUrl; // 「沙箱环境」页面跳转同步通知页面路径 需http://格式的完整路径，不能加?id=123这类自定义参数，必须外网可以正常访问 private String returnUrl; // 「沙箱环境」 private String gatewayUrl; // 签名方式 private String signType = "RSA2"; // 字符编码格式 private String charset = "utf-8"; // 传输格式 private String format = "json"; } 创建alipay客户端。 @Configuration public class AliPayConfig { @Bean("alipayClient") public AlipayClient alipayClient(AliPayConfigProperties properties) { return new DefaultAlipayClient(properties.getGatewayUrl(), properties.getAppId(), properties.getMerchantPrivateKey(), properties.getFormat(), properties.getCharset(), properties.getAlipayPublicKey(), properties.getSignType()); } } 公众号扫码登录流程 https://mp.weixin.qq.com/debug/cgi-bin/sandboxinfo?action=showinfo&t=sandbox/index 微信开发者平台。 微信登录时，需要调用微信提供的接口做验证，使用Retrofit 场景：用微信的能力来替你的网站做“扫码登录”或“社交登录”，代替自己写一整套帐号／密码体系。后台只需要基于 openid 做一次性关联（比如把某个微信号和你系统的用户记录挂钩），后续再次扫码就当作同一用户； 1.前端请求二维码凭证 用户点击“扫码登录”，前端向后端发 GET /api/v1/login/weixin_qrcode_ticket。 后端获取 access_token 1.先尝试从本地缓存（如 Guava Cache）读取 access_token； 2.若无或已过期，则请求微信接口： GET https://api.weixin.qq.com/cgi-bin/token ?grant_type=client_credential &appid={你的 AppID} &secret={你的 AppSecret} 微信返回 { "access_token":"ACCESS_TOKEN_VALUE", "expires_in":7200 }，后端缓存这个值（有效期约 2 小时）。 后端利用 access_token 创建二维码 ticket，返给前端。（每次调用微信会返回不同的ticket） 2.前端展示二维码 前端根据 ticket 生成二维码链接：https://mp.weixin.qq.com/cgi-bin/showqrcode?ticket={ticket} 3.微信回调后端 用户确认扫描后，微信服务器向你预先配置的回调 URL（如 POST /api/v1/weixin/portal/receive）推送包含 ticket 和 openid 的消息。 后端：将 ticket → openid 存入缓存（openidToken.put(ticket, openid)）；调用 sendLoginTemplate(openid) 给用户推送“登录成功”模板消息（手机公众号上推送，非网页） 4.前端获知登录结果 轮询方式：生成二维码后，前端每隔几秒向后端 check_login 接口发送 ticket来验证登录状态，后端查缓存来判断 ticket 对应用户是否成功登录。 推送方式：前端通过 WebSocket/SSE 建立长连接，后端回调处理完成后直接往该连接推送登录成功及 JWT。 浏览器指纹获取登录ticket 在扫码登录流程的基础上改进！！！ 目的：把「这张二维码／ticket」严格绑在发起请求的那台浏览器上，防止别的设备或会话拿到同一个 ticket 就能登录。 1.生成指纹 前端在用户打开「扫码登录页」时，先用 JS／浏览器 API（比如 User-Agent、屏幕分辨率、插件列表、Canvas 指纹等）算出一个唯一的浏览器指纹 fp。 2.获取 ticket 时携带指纹 前端发起请求： GET /api/v1/login/weixin_qrcode_ticket_scene?sceneStr=<fp> 后端执行： String ticket = loginPort.createQrCodeTicket(sceneStr); sceneTicketCache.put(sceneStr, ticket); // 把 fp→ticket 映射进缓存 3.扫码后轮询校验 前端轮询：传入 ticket 和 sceneStr 指纹 GET /api/v1/login/check_login_scene?ticket=<ticket>&sceneStr=<fp> 后端逻辑（简化）： // 1) 验证拿到的 sceneStr(fp) 对应的 ticket 是否一致 String cachedTicket = sceneTicketCache.getIfPresent(sceneStr); if (!ticket.equals(cachedTicket)) { // fp 不匹配，拒绝 return NO_LOGIN; } // 2) 再看 ticket→openid 有没有被写入（扫码并回调后，saveLoginState 会写入） String openid = ticketOpenidCache.getIfPresent(ticket); if (openid != null) { // 同一浏览器，且已扫码确认，返回 openid（或 JWT） return SUCCESS(openid); } return NO_LOGIN; 4.回调时保存登录状态 当用户扫描二维码，微信会回调你预定的接口地址，拿到 ticket、openid 后，调用： ticketOpenidCache.put(ticket, openid); // 保存 ticket→openid 注意 ticketOpenidCache 和 sceneTicketCache 一般是一个Cache Bean，这里只是为了更清晰。 安全性提升 防止“票据劫持”：别人就算截获了这个 ticket，想拿去自己那台机器上轮询也不行，因为指纹对不上。 防止多人共用：多个人在不同设备上同时扫同一个码，只有最先发起获取 ticket 的那台浏览器能完成登录。 独占锁和无锁化场景（防超卖） 目标： 保证 库存数量的正确性 —— 不能出现“明明只有 10 件商品，却卖出去 11 件”的情况。 典型问题场景： 秒杀/拼团/抢购，高并发请求瞬间打到库存。 多个并发事务都认为“库存足够”，于是都扣减成功。 独占锁 适用场景 定时任务互备 多机部署时，确保每天只有一台机器在某个时间点执行同一份任务（如数据清理、报表生成、邮件推送等）。 @Scheduled(cron = "0 0 0 * * ?") public void exec() { // 获取锁句柄，并未真正获取锁 RLock lock = redissonClient.getLock("group_buy_market_notify_job_exec"); try { //尝试获取锁 waitTime = 3:如果当前锁已经被别人持有，调用线程最多等待 3 秒去重试获取;leaseTime = 0:不设过期时间，看门狗机制 boolean isLocked = lock.tryLock(3, 0, TimeUnit.SECONDS); if (!isLocked) return; Map<String, Integer> result = tradeSettlementOrderService.execSettlementNotifyJob(); log.info("定时任务，回调通知拼团完结任务 result:{}", JSON.toJSONString(result)); } catch (Exception e) { log.error("定时任务，回调通知拼团完结任务失败", e); } finally { if (lock.isLocked() && lock.isHeldByCurrentThread()) { lock.unlock(); } } } 无锁化并发控制（法一） 目标：在万级并发下保证 不超卖、可退单补量、团长也算库存，且不引入 JVM 级互斥锁。 角色 Redis Key 含义 变化方式 计数器 teamOccupiedStockKey 已占用名额（仅团员） INCR 退单补量 recoveryTeamStockKey 退回名额（累加） 退单环节 INCRBY 配额上限 target 团长 + 团员 的最大名额 配置 1. Lua 原子脚本 -- KEYS[1] = teamOccupiedStockKey -- ARGV[1] = target（含团长） -- ARGV[2] = recoveryCount local limit = tonumber(ARGV[1]) + tonumber(ARGV[2]) local v = redis.call('INCR', KEYS[1]) + 1 -- +1 把团长补进去 if v > limit then redis.call('DECR', KEYS[1]) -- 回滚 return 0 -- 告诉调用方名额已满 else return v -- 抢到的序号（含团长） end 原子性：INCR → 判断 → DECR 全在一条脚本里，Redis 单线程保证不会被并发打断。 +1 偏移：计数器只统计团员，每次 +1 把团长补进去，对比对象与 target 同维度。（redis中的teamOccupiedStockKey的值比真实锁单量少1，是正常的，因为redis中只存了团员的锁单，团长是在代码逻辑中手动+1的） 退单补量：limit = target + recoveryCount，退单线程把名额写回 recoveryTeamStockKey 后，下一次抢单自然放量。 无锁化并发控制（法二） @Override public boolean occupyTeamStock(String teamOccupiedStockKey, String recoveryTeamStockKey, Integer target, Integer validTime) { // 获取失败恢复量 Long recoveryCount = redisService.getAtomicLong(recoveryTeamStockKey); recoveryCount = null == recoveryCount ? 0 : recoveryCount; // 1. incr 得到值，与总量和恢复量做对比。恢复量为系统失败时候记录的量。 // 2. 从有组队量开始，相当于已经有了一个占用量，所以要 +1，因为团长开团的时候teamid为null，但事实上锁单已经有一单了。 long occupy = redisService.incr(teamOccupiedStockKey) + 1; //取teamOccupiedStockKey的值，先自增，再返回；类似++i if (occupy > target + recoveryCount) { repository.recoveryTeamStock(recoveryTeamStockKey); return false; } // 1. 给每个产生的值加锁为兜底设计，虽然incr操作是原子的，基本不会产生一样的值。但在实际生产中，遇到过集群的运维配置问题，以及业务运营配置数据问题，导致incr得到的值相同。 // 2. validTime + 60分钟，是一个延后时间的设计，让数据保留时间稍微长一些，便于排查问题。 String lockKey = teamOccupiedStockKey + Constants.UNDERLINE + occupy; Boolean lock = redisService.setNx(lockKey, validTime + 60, TimeUnit.MINUTES); if (!lock) { log.info("组队库存加锁失败 {}", lockKey); } return lock; } 这里teamOccupiedStockKey 和recoveryTeamStockKey 都是只增不减的，如果抢占失败的，直接对recoveryTeamStockKey+1。 recoveryTeamStockKey 还有通过参与拼团的人退单来+1 为什么对teamOccupiedStockKey-1 必须要用Lua脚本？ long occupy = redisService.incr(teamOccupiedStockKey); if (occupy > target + recoveryCount) { redisService.decr(teamOccupiedStockKey); // 回滚 return false; } 如果直接JAVA代码中写两个逻辑，风险在： INCR 和 DECR 是两条独立命令。 在 INCR 和 DECR 之间的时间窗口里，其他请求可能已经拿到 INCR 的结果。 多个失败请求并发执行，会出现“多次 DECR 把计数扣过头”的问题，导致库存虚减甚至超卖。 本项目采用第二种方法！！！ 极端兜底锁 String lockKey = teamOccupiedStockKey + Constants.UNDERLINE + occupy; Boolean lock = redisService.setNx(lockKey, validTime + 60, TimeUnit.MINUTES); if (!lock) { log.info("组队库存加锁失败 {}", lockKey); } 解决极小概率 相同序号并发撞号 的问题（ TTL 比业务 validTime 多留 60 min，方便排查。 订单关闭/失效时记得删除对应 lockKey（目的是设置了过期时间为拼团有效期+60分钟），防止 Redis 小键堆积。 怎样的情况可能导致并发撞号？ t1：客户端发起 INCR，Redis 内存里变成 101，返回 101（内存里修改完成就返回，不等落盘）； t1+Δ：Redis 还没把这条写刷到磁盘（AOF 还在缓冲里 / OS 还没 fsync）； t2：Redis 故障崩溃 → 只剩下落盘的旧状态（100）； t3：重启后加载旧数据，从 100 再开始递增 → 101（和之前用过的号重复）。 持久化粒度取决于 appendfsync 配置： always：每次写都 fsync → 最安全，最慢。 everysec（默认）：每秒 fsync → 可能丢 1 秒内的数据。 no：完全交给操作系统 → 性能好，但可能丢几十秒。 典型适用场景 电商秒杀 & 拼团抢购 万级甚至十万级并发下不适合所有请求都排队，必须让绝大多数请求用原子计数并行处理。 抢票系统 票务分配、座位预占，都讲究“先到先得”+“补偿回退”，不能用一把大锁。 本项目有两层防护： 页面／接口层校验 进入拼团展示页，前端先查当前正在拼团的信息（可以看到XX拼团还剩X人）。 用户点击下单时，调用锁单接口，由于页面刷新的时间戳可能滞后，出现“页面显示还差 X 人，但点进去已满员”的情况时，返回"拼团组 队完结，锁单量已达成"。但仍有可能出现：数据库显示有剩余名额，但高并发下，可能有多个用户透过这层防护！！！ 真正的并发保证：Redis 原子 INCR + 补偿计数（recoveryTeamStockKey） + 兜底 SETNX（法二） 生活例子理解 假设你有一个限量商品，每个商品有一个唯一的编号，假设这些商品编号为 1、2、3、4、5（总共 5 个）。这些商品被分配给用户，每个用户会抢一个编号。每个用户成功抢到一个商品后，系统会在库存中占用一个编号。 抢购过程： 有 5 个商品编号（1-5），这些编号是库存量。 每个用户请求一个商品编号，系统会给用户分配一个编号（这个过程就像是自增占用量的过程）。 如果用户请求的编号超过了现有库存的最大编号（5），则说明没有商品可以分配给该用户，用户抢购失败。 如果有多个用户抢同一个编号（例如都想抢到编号 1 的商品），系统通过“分布式锁”来保证只有一个用户能成功抢到编号 1，其他用户则失败。 Supplier<T> Supplier<T> 是 Java 8 提供的一个函数式接口 @FunctionalInterface public interface Supplier<T> { /** * 返回一个 T 类型的结果，参数为空 */ T get(); } 任何“无参返回一个 T 类型对象”的代码片段（方法引用或 lambda）都可以当成 Supplier<T> 来用。 作用 1.延迟执行 把“取数据库数据”这类开销大的操作，包装成 Supplier<T> 传进去；只有真正需要时（缓存未命中），才触发执行。 // 缓存未命中时，才调用 supplier.get() 执行数据库查询 T dbResult = dataFetcher.get(); 2.解耦逻辑 缓存组件不关心数据如何获取，只负责缓存策略；调用方通过 Supplier提供数据获取逻辑。 public <T> T getFromCacheOrDb(String key, Supplier<T> dataFetcher) { ... } 3.重用性高 同一个缓存-回源模板方法可以服务于任何返回 T 的场景，既可以查 User，也可以查 Order、List<Product>…… // 查询用户 User user = getFromCacheOrDb("user:123", () -> userDao.findById(123)); // 查询订单列表 List<Order> orders = getFromCacheOrDb("orders:456", () -> orderDao.listByUserId(456)); 分布式限流（AOP + Redisson 实现）+黑名单 核心思路 动态开关管理 使用 @DCCValue("rateLimiterSwitch:open") 从配置中心动态注入全局开关，支持热更新。 当开关为 "close" 时，直接放行所有请求，切面不再执行限流逻辑。 AOP 切面拦截 通过自定义注解 @RateLimiterAccessInterceptor 标记需要限流的方法。 注解参数 key 用于指定限流维度（如 userId 表示按用户限流，all 表示全局限流）。 切面在运行时解析这个字段的值，动态生成 Redis 限流器 Key，例如： //添加拦截注解 @RateLimiterAccessInterceptor(key = "userId", permitsPerSecond = 5, fallbackMethod = "fallback") public void order(String userId) {...} 请求1: userId=U12345 → Redis Key: rl:limiter:U12345 请求2: userId=U67890 → Redis Key: rl:limiter:U67890 反射的应用： 获取限流维度 Key（如 userId） 切面会从方法参数对象中反射查找 userId字段： private String extractField(Object obj, String name) { Field field = getFieldByName(obj, name); field.setAccessible(true); Object v = field.get(obj); return v != null ? v.toString() : null; } 调用降级方法 当请求被限流或进入黑名单时，切面会通过反射执行注解里指定的 fallbackMethod： Method method = jp.getTarget().getClass() .getMethod(fallbackMethod, ms.getParameterTypes()); return method.invoke(jp.getTarget(), jp.getArgs()); 限流与黑名单 使用 RRateLimiter 实现分布式令牌桶，每秒放入 permitsPerSecond 个令牌。 取不到令牌时： 如果配置了 blacklistCount，用 RAtomicLong 记录该 Key 的拒绝次数； 拒绝次数超限后，将 Key 加入黑名单 24 小时。（rl:bl:keyAttr 中存放着24小时内该用户超限次数，如果大于blacklistCount，则黑名单启动拦截；而不是指某个rl:bl:keyAttr 存在就拦截，还是要比较次数的！） 命中黑名单或限流时，调用注解里的 fallbackMethod 执行降级逻辑。 注意这里有两个key: rl:bl:keyAttr ，设置了24小时的过期时间，里面存着24小时内xx用户超限的次数。 rl:limiter:keyAttr 未设置过期时间（xx用户随时来，随时限流） 令牌桶算法（Token Bucket） 工作原理：按固定速率往桶里放“令牌”（tokens），例如每秒放 N 个。每次请求到达时，必须先从桶中“取一个令牌”，才能通过；如果取不到，则拒绝或降级。 特点：支持流量平滑释放和突发流量吸纳，桶最多能存储 M 个令牌。 方法调用 ↓ AOP 切面拦截（匹配 @RateLimiterAccessInterceptor） ↓ 检查全局限流开关（@DCCValue 注入） ↓ 解析注解里的 key → 获取对应参数值（如 userId） ↓ 黑名单检查（RAtomicLong） ↓ 分布式令牌桶限流（RRateLimiter.tryAcquire） ↓ ├─ 成功 → 执行目标方法 └─ 失败 → 累加拒绝计数 & 调用 fallbackMethod 对比维度 本地限流 分布式限流 实现复杂度 低：直接用 Guava RateLimiter，几行代码即可接入 中高：依赖 Redis/Redisson，需要注入客户端并管理限流器 性能开销 极低：全程内存操作，纳秒级延迟 中等：每次获取令牌需网络往返，存在 RTT 延迟 限流范围 单实例：仅对当前 JVM 有效，多实例互不影响 全局：多实例共享同一套令牌桶，合计速率可控 状态持久化 & 容错 无：服务重启后状态丢失；实例宕机只影响自身 有：Redis 存储限流器与黑名单，可持久化；需保证 Redis 可用性 目前本项目采用 分布式限流，使用 Redisson 实现跨实例令牌桶，确保全局限流控制。 防止重复下单 目标： 保证 同一个用户 在某一时间段/某一业务维度下（比如一个拼团活动、一个商品），只生成一条有效订单。 典型问题场景： 用户在页面疯狂点击“立即购买”。 用户在弱网环境下重复请求。 用户恶意构造多条请求。 常见方案： 前端限制：按钮禁用、loading 状态。 后端约束 复合唯一索引（userId+goodId+activityId），天然保证“一人一单”； 幂等 Key（idempotencyKey 或外部交易号），请求携带 Key，数据库唯一索引约束避免重复写入； （可选）分布式锁，避免并发下插入多条记录。 本质：限制用户的重复请求，确保“一次支付流程只产生一条订单”。 如何实现幂等性 保证业务的幂等性，核心思想就是：对于同一个操作的多次重复请求，其产生的结果应该与仅执行一次请求的结果完全相同。 1）生成幂等 Key 前端进入支付流程时调用接口（GET /api/idempotency-key），后端生成全局唯一 ID（UUID 或雪花 ID）返回给前端； 或者外部系统（如小商城）传来唯一的外部交易单号（out_trade_no），天生作为幂等Key。 请求携带幂等 Key 用户点击“下单”时，调用 /create_pay_order 接口，需在请求体中附带 idempotencyKey； 服务端根据该 Key 判断：若数据库中已有相同 idempotency_key，直接返回该订单，否则创建新订单。 2）唯一索引 在订单表中新增 idempotency_key 列，并对其增加唯一索引； 双重保障：前端重复发送同一 Key，也仅能插入一条记录，彻底避免重复下单。 3）Redis 分布式锁 根据 idempotencyKey 在 Redis 里尝试获取一个分布式锁（比如 SETNX idempotencyKey，或者 Redisson 的 RLock.tryLock()） 拿到锁的请求：先查数据库是否已有相同 idempotencyKey 的订单； 如果没有 → 创建新订单并写入数据库； 如果已有 → 直接返回该订单。 两种实践： 只 INSERT：如果 (user_id, idempotency_key) 已经存在，会报错 Duplicate entry。 先查后插：需要 SELECT → 再 INSERT，下订单时额外先查一次消耗资源，且并发下有竞态，还要兜异常。 推荐两者结合： INSERT INTO orders (user_id, idempotency_key, ...) VALUES (:uid, :key, ...) ON DUPLICATE KEY UPDATE id = LAST_INSERT_ID(id); SELECT LAST_INSERT_ID() AS order_id; 情况 A：key 第一次出现 INSERT 成功，生成新的自增 id； ON DUPLICATE 分支不会触发； LAST_INSERT_ID() = 新生成的订单 ID。 情况 B：key 已存在 INSERT 命中唯一约束，触发 ON DUPLICATE KEY UPDATE 分支； 这里我们写的是 id = LAST_INSERT_ID(id)，相当于把已存在行的 id“赋值给自己”，不改变数据，但会更新会话里的 LAST_INSERT_ID() 值； 因此 SELECT LAST_INSERT_ID() 返回的是已有订单的 id。 还可以用Redis SETNX（原子操作，保证只处理一次）。 来查消息是否被处理过 RPC微服务调用 RPC（Remote Procedure Call，远程过程调用） 就像调用本地方法一样调用远程服务的方法。 框架（Dubbo、gRPC、Thrift 等）会帮你处理 序列化、网络通信、连接管理、负载均衡 等细节。 开发者只需要写接口 + 实现类，调用方直接调用接口，RPC 框架在背后“悄悄”完成远程调用。 实现步骤 1.父Pom统一版本 <!-- 统一锁版本，避免不同模块写不同小版本 --> <dependency> <groupId>org.apache.dubbo</groupId> <artifactId>dubbo-bom</artifactId> <version>3.3.5</version> <type>pom</type> <scope>import</scope> </dependency> 2.pay-mall-infrustruct（Consumer）group-buying-sys-trigger (Provider)引入依赖 <dependencies> <!-- Dubbo 核心 + Spring Boot 自动装配 --> <dependency> <groupId>org.apache.dubbo</groupId> <artifactId>dubbo-spring-boot-starter</artifactId> </dependency> <!-- Nacos 注册中心扩展 --> <dependency> <groupId>org.apache.dubbo</groupId> <artifactId>dubbo-registry-nacos</artifactId> </dependency> </dependencies> 3.部署nacos（详见微服务笔记） 4.配置注册（消费者、生产者都要配） dubbo: application: name: group-buy-market-service # 换成各自服务名 registry: address: nacos://localhost:8848 # 远程环境写内网地址 # username/password 如果 Nacos 开了鉴权 protocol: name: dubbo port: 20880 # 生产者开放端口；消费者可不写 consumer: timeout: 3000 # 毫秒 check: false # 忽略启动时服务是否可用 5.开启 Dubbo 注解扫描 在消费者、生产者的主启动类上加，设置正确的包名，让 @DubboService 和 @DubboReference 被 Spring+Dubbo 识别和处理 @SpringBootApplication @EnableDubbo(scanBasePackages = "edu.whut") public class Application { … } 6.在Dubbo RPC调用中，DTO对象需要在网络中进行传输，因此它们必须实现 java.io.Serializable 接口： /** * 用户信息请求对象 */ @Data public class UserRequestDTO implements Serializable { // 实现 Serializable private static final long serialVersionUID = 1L; // 添加 serialVersionUID，用于版本控制 // 用户ID private String userId; // 用户名 private String userName; // 邮箱 private String email; } 7.定义服务接口： 服务接口定义了服务提供者能够提供的功能以及服务消费者能够调用的方法。这个接口必须是公共的，并且通常放置在一个独立的 api模块中。供服务提供者和消费者共同依赖。 /** * 用户服务接口 */ public interface IUserService { /** * 根据用户ID获取用户信息 * @param requestDTO 用户请求对象 * @return 用户响应对象 */ UserResponseDTO getUserInfo(UserRequestDTO requestDTO); /** * 创建新用户 * @param requestDTO 用户请求对象 * @return 操作结果 */ String createUser(UserRequestDTO requestDTO); } 8.服务提供者 (Provider) 实现并暴露服务 在服务提供者应用中，实现上述定义的服务接口，并使用 @DubboService 注解将其暴露为Dubbo服务。可以放在trigger/rec包下。 /** * 用户服务实现类 */ @DubboService(version = "1.0.0", group = "user-service") // 关键注解：暴露Dubbo服务 @Service // 也可以同时是Spring的Service public class UserServiceImpl implements IUserService { @Override public UserResponseDTO getUserInfo(UserRequestDTO requestDTO) { System.out.println("收到获取用户信息的请求: " + requestDTO.getUserId()); // 模拟业务逻辑 UserResponseDTO response = new UserResponseDTO(); response.setUserId(requestDTO.getUserId()); response.setUserName("TestUser_" + requestDTO.getUserId()); response.setEmail("test_" + requestDTO.getUserId() + "@example.com"); return response; } @Override public String createUser(UserRequestDTO requestDTO) { System.out.println("收到创建用户的请求: " + requestDTO.getUserName()); // 模拟业务逻辑 return "User " + requestDTO.getUserName() + " created successfully."; } } 9.服务消费者 (Consumer) 引用远程服务 在服务消费者应用中，通过 @DubboReference 注解引用远程Dubbo服务。Dubbo 会自动通过注册中心查找并注入对应的服务代理。 /** * 用户API控制器 */ @RestController public class UserController { @DubboReference(version = "1.0.0", group = "user-service") // 关键注解：引用Dubbo服务 private IUserService userService; @GetMapping("/user/info") public UserResponseDTO getUserInfo(@RequestParam String userId) { UserRequestDTO request = new UserRequestDTO(); request.setUserId(userId); return userService.getUserInfo(request); } @GetMapping("/user/create") public String createUser(@RequestParam String userName, @RequestParam String email) { UserRequestDTO request = new UserRequestDTO(); request.setUserName(userName); request.setEmail(email); return userService.createUser(request); } } RPC：同步调用、强一致、快速响应，比如pay-mall调用拼团系统的拼团交易锁单 、营销结算、营销拼团退单 HTTP：本系统调用微信支付这种第三方接口。 MQ：异步解耦、削峰填谷、最终一致性，比如退单消息，pay-mall调用营销拼团退单接口后，将订单设置为'待退单状态'，然后拼团系统退单完成后发送'退单完成'消息，pay-mall接收继续做最终的退单处理。 怎么确保这个微服务调用的可靠性？ 如果小型支付商城调用拼团失败，有两种情况： 1.网络异常、超时，dubbo框架会抛一个异常，可以特别处理，对其进行重试，设置最大重试次数，以及指数退避算法；这里要求锁单做幂等校验！ 2.业务异常，不重试，可能是因为用户参与次数已达上限、活动过期之类的。 日志系统 输出流向一览 输出到3个地方：控制台、本地文件、ELK日志（服务器上内存不足无法部署！） 日志级别 控制台 本地文件（异步） Logstash (TCP) TRACE/DEBUG — — — INFO ✔ log_info.log ✔ WARN ✔ log_info.log``log_error.log ✔ ERROR/FATAL ✔ log_info.log``log_error.log ✔ 注意：实际写文件时，都是通过 ASYNC_FILE_INFO/ERROR 两个异步 Appender 执行，以免日志写盘阻塞业务线程。 ELK日志系统 本地文件每台机器都会在自己 /data/log/... 目录下滚动输出自己的日志，互相之间不会合并。 如果你希望跨多台服务器统一管理，就需要把日志推到中央端——ELK日志系统 ELK=Elasticsearch（存储&检索）+ Logstash（采集&处理）+ Kibana（可视化） docker-compose.yml: version: '3' services: elasticsearch: image: elasticsearch:7.17.28 ports: ['9201:9200','9300:9300'] environment: - discovery.type=single-node - ES_JAVA_OPTS=-Xms512m -Xmx512m volumes: - ./data:/usr/share/elasticsearch/data logstash: image: logstash:7.17.28 ports: ['4560:4560','9600:9600'] volumes: - ./logstash/logstash.conf:/usr/share/logstash/pipeline/logstash.conf environment: - LS_JAVA_OPTS=-Xms1g -Xmx1g kibana: image: kibana:7.17.28 ports: ['5601:5601'] environment: - elasticsearch.hosts=http://elasticsearch:9200 networks: default: driver: bridge kibana配置： # # ** THIS IS AN AUTO-GENERATED FILE ** # # Default Kibana configuration for docker target server.host: "0" server.shutdownTimeout: "5s" elasticsearch.hosts: [ "http://elasticsearch:9200" ] # 记得修改ip monitoring.ui.container.elasticsearch.enabled: true i18n.locale: "zh-CN" logstash配置: input { tcp { mode => "server" host => "0.0.0.0" port => 4560 codec => json_lines type => "info" } } filter {} output { elasticsearch { action => "index" hosts => "es:9200" index => "group-buy-market-log-%{+YYYY.MM.dd}" } } 自己的项目： <!-- 上报日志；ELK --> <springProperty name="LOG_STASH_HOST" scope="context" source="logstash.host" defaultValue="127.0.0.1"/> <!--输出到logstash的appender--> <appender name="LOGSTASH" class="net.logstash.logback.appender.LogstashTcpSocketAppender"> <!--可以访问的logstash日志收集端口--> <destination>${LOG_STASH_HOST}:4560</destination> <encoder charset="UTF-8" class="net.logstash.logback.encoder.LogstashEncoder"/> </appender> <dependency> <groupId>net.logstash.logback</groupId> <artifactId>logstash-logback-encoder</artifactId> <version>7.3</version> </dependency> 使用 检查索引：curl http://localhost:9201/_cat/indices?v3 打开 Kibana：浏览器访问 http://localhost:5601，新建 索引模式（如 app-log-*），即可在 Discover/Visualize 中查看与分析日志。
项目
zy123
6月20日
0
21
1
2025-06-17
强化学习
强化学习 Q-learning 核心更新公式 $$ \boxed{Q(s,a) \gets Q(s,a) + \alpha\left[r + \gamma\,\max_{a'}Q(s',a') - Q(s,a)\right]} $$ - $s$：当前状态 - $a$：当前动作 - $r$：执行 $a$ 后获得的即时奖励 - $s'$：执行后到达的新状态 - $\alpha\in(0,1]$：学习率，决定“这次新信息”对旧值的影响力度 - $\gamma\in[0,1)$：折扣因子，衡量对“后续奖励”的重视程度 - $\max_{a'}Q(s',a')$：新状态下可选动作的最大估值，表示“后续能拿到的最大预期回报” 一般示例 环境设定 状态集合：${S_1, S_2}$ 动作集合：${a_1, a_2}$ 转移与奖励： 在 $S_1$ 选 $a_1$ → 获得 $r=5$，转到 $S_2$ 在 $S_1$ 选 $a_2$ → 获得 $r=0$，转到 $S_2$ 在 $S_2$ 选 $a_1$ → 获得 $r=0$，转到 $S_1$ 在 $S_2$ 选 $a_2$ → 获得 $r=1$，转到 $S_1$ 超参数：$\alpha=0.5$，$\gamma=0.9$ 初始化：所有 $Q(s,a)=0$ 在 Q-Learning 里，智能体并不是“纯随机”地走，也不是“一开始就全凭 Q 表拿最高值”——而是常用一种叫 $\epsilon$-greedy 的策略来平衡： 探索（Exploration）：以概率 $\epsilon$（比如 10%）随机选一个动作，帮助智能体发现还没试过、可能更优的路径； 利用（Exploitation）：以概率 $1-\epsilon$（比如 90%）选当前状态下 Q 值最高的动作，利用已有经验最大化回报。 下面按序进行 3 步“试—错”更新，并在表格中展示每一步后的 $Q$ 值。 步骤 状态 $s$ 动作 $a$ 奖励 $r$ 到达 $s'$ $\max_{a'}Q(s',a')$ 更新后 $Q(s,a)$ 当前 Q 表 初始 — — — — — — $Q(S_1,a_1)=0,;Q(S_1,a_2)=0$ $Q(S_2,a_1)=0,;Q(S_2,a_2)=0$ 1 $S_1$ $a_1$ 5 $S_2$ 0 $0+0.5,(5+0-0)=2.5$ $Q(S_1,a_1)=2.5,;Q(S_1,a_2)=0$ $Q(S_2,a_1)=0,;Q(S_2,a_2)=0$ 2 $S_2$ $a_2$ 1 $S_1$ $到达S_1状态后选择最优动作：$$\max{2.5,0}=2.5$ $0+0.5,(1+0.9\cdot2.5-0)=1.625$ $Q(S_1,a_1)=2.5,;Q(S_1,a_2)=0$ $Q(S_2,a_1)=0,;Q(S_2,a_2)=1.625$ 3 $S_1$ $a_1$ 5 $S_2$ $\max{0,1.625}=1.625$ $2.5+0.5,(5+0.9\cdot1.625-2.5)\approx4.481$ $Q(S_1,a_1)\approx4.481,;Q(S_1,a_2)=0$ $Q(S_2,a_1)=0,;Q(S_2,a_2)=1.625$ 第1步：从 $S_1$ 选 $a_1$，立即回报5，更新后 $Q(S_1,a_1)=2.5$。 第2步：从 $S_2$ 选 $a_2$，回报1，加上对 $S_1$ 后续最优值的 $0.9$ 折扣，得到 $1+0.9\times2.5=3.25$，更新后 $Q(S_2,a_2)=1.625$。 第3步：再一次在 $S_1$ 选 $a_1$，这次考虑了 $S_2$ 的最新估值，最终把 $Q(S_1,a_1)$ 提升到约 4.481。 通过这样一步步的“试—错 + 贝尔曼更新”，Q-Learning 能不断逼近最优 $Q^*(s,a)$，从而让智能体在每个状态都学会选出长期回报最高的动作。 训练结束后，表里每个状态 $s$ 下各动作的 Q 值都相对准确了，我们就可以直接读表来决策： $$ \pi(s) = \arg\max_a Q(s,a) $$ 即“在状态 $s$ 时，选 Q 值最高的动作”。 状态 \ 动作 $a_1$ $a_2$ $S_1$ 4.481 0 $S_2$ 0 1.625 DQN 核心思想：用深度神经网络近似 Q 函数来取代表格，在高维输入上直接做 Q-learning，并通过 经验回放（写进缓冲区 + 随机抽样训练”） + 目标网络（Target Network） 两个稳定化技巧，使 时序差分（TD ）学习在非线性函数逼近下仍能收敛。 TD 学习 = 用“即时奖励 + 折扣后的未来估值”作为目标，通过 TD 误差持续修正当前估计。 训练过程 1. 初始化 主网络（Online Network） 定义一个 Q 网络 $Q(s,a;\theta)$，随机初始化参数 $\theta$。 目标网络（Target Network） 复制主网络参数，令 $\theta^- \leftarrow \theta$。 目标网络用于计算贝尔曼目标值，短期内保持不变。 经验回放缓冲区（Replay Buffer） 创建一个固定容量的队列 $\mathcal{D}$，用于存储交互样本 $(s,a,r,s')$。 超参数设置 学习率 $\eta$ 折扣因子 $\gamma$ ε-greedy 探索率 $\epsilon$（初始值） 最小训练样本数阈值 $N_{\min}$ 每次训练的小批量大小 $B$ 目标网络同步频率 $C$（梯度更新次数间隔） 2. 与环境交互并存储经验 在每个时间步 $t$： 动作选择 $$ a_t = \begin{cases} \text{随机动作} & \text{以概率 }\epsilon,\ \arg\max_a Q(s_t,a;\theta) & \text{以概率 }1-\epsilon. \end{cases} $$ 环境反馈 执行动作 $a_t$，得到奖励 $r_t$ 和下一个状态 $s_{t+1}$。 （需预先定义奖励函数） 存入缓冲区 将元组 $(s_t, a_t, r_t, s_{t+1})$ 存入 Replay Buffer $\mathcal{D}$。 如果 $\mathcal{D}$ 已满，则丢弃最早的样本。 3. 批量随机采样并训练 当缓冲区样本数 $\ge N_{\min}$ 时，每隔一次或多次环境交互，就进行一次训练更新： 随机抽取小批量 从 $\mathcal{D}$ 中随机采样 $B$ 条过往经验： $$ {(s_i, a_i, r_i, s'i)}{i=1}^B $$ 计算贝尔曼目标 对每条样本，用目标网络 $\theta^-$ 计算： $$ y_i = r_i + \gamma \max_{a'}Q(s'_i, a'; \theta^-) $$ 算的是：当前获得的即时奖励 $r_i$，加上“到了下一个状态后，做最优动作所能拿到的最大预期回报” 预测当前 Q 值 将当前状态-动作对丢给主网络 $\theta$，得到预测值： $$ \hat Q_i = Q(s_i, a_i;\theta) $$ 算的是：在当前状态 $s_i$、选了样本里那个动作 $a_i$ 时，网络现在估计的价值 构造损失函数 均方误差（MSE）损失： $$ L(\theta) = \frac{1}{B}\sum_{i=1}^B\bigl(y_i - \hat Q_i\bigr)^2 $$ 梯度下降更新主网络 $$ \theta \gets \theta - \eta \nabla_\theta L(\theta) $$ 4. 同步/软更新目标网络 硬同步（Fixed Target）： 每做 $C$ 次梯度更新，就执行 $$ \theta^- \gets \theta $$ （可选）软更新： 用小步长 $\tau\ll1$ 平滑跟踪： $$ \theta^- \gets \tau \theta + (1-\tau) \theta^-. $$ 5. 重复训练直至收敛 重复步骤 2-4 直至满足终止条件（如最大回合数或性能指标）。 训练过程中可逐步衰减 $\epsilon$（ε-greedy），从更多探索过渡到更多利用。 示例 假设设定 动作空间：两个动作 ${a_1,a_2}$。 状态向量维度：2 维，记作 $s=(s_1,s_2)$。 目标网络结构（极简线性网络）： $$ Q(s;\theta^-) = W^-s + b^-, $$ $W^-$ 是 $2\times2$ 的权重矩阵 （行数为动作数，列数为状态向量维数） $b^-$ 是长度 2 的偏置向量 网络参数（假定已初始化并被冻结）： $$ W^- = \begin{pmatrix} 0.5 & -0.2\ 0.1 & ;0.3 \end{pmatrix},\quad b^- = \begin{pmatrix}0.1\-0.1\end{pmatrix}. $$ 折扣因子 $\gamma=0.9$。 样本数据 假设我们抽到的一条经验是 $$ (s_i,a_i,r_i,s'_i) = \bigl((0.0,\;1.0),\;a_1,\;2,\;(1.5,\,-0.5)\bigr). $$ 当前状态 $s_i=(0.0,1.0)$，当时选了动作 $a_1$ 并得到奖励 $r_i=2$。 到达新状态 $s'_i=(1.5,-0.5)$。 计算过程 前向计算目标网络输出 $$ Q(s'_i;\theta^-) = W^-,s'_i + b^- \begin{pmatrix} 0.5 & -0.2\ 0.1 & ;0.3 \end{pmatrix} \begin{pmatrix}1.5\-0.5\end{pmatrix} + \begin{pmatrix}0.1\-0.1\end{pmatrix} \begin{pmatrix} 0.5\cdot1.5 + (-0.2)\cdot(-0.5) + 0.1 \[4pt] 0.1\cdot1.5 + ;0.3\cdot(-0.5) - 0.1 \end{pmatrix} \begin{pmatrix} 0.75 + 0.10 + 0.1 \[3pt] 0.15 - 0.15 - 0.1 \end{pmatrix} \begin{pmatrix} 0.95 \[3pt] -0.10 \end{pmatrix}. $$ 因此， $$ Q(s'_i,a_1;\theta^-)=0.95,\quad Q(s'_i,a_2;\theta^-)= -0.10. $$ 取最大值 $$ \max_{a'}Q(s'_i,a';\theta^-) = \max{0.95,,-0.10} = 0.95. $$ 计算目标 $y_i$ $$ y_i = r_i + \gamma \times 0.95 = 2 + 0.9 \times 0.95 = 2 + 0.855 = 2.855. $$ 这样，我们就得到了 DQN 中训练主网络时的"伪标签" $y_i=2.855$，后续会用它与主网络预测值 $Q(s_i,a_i;\theta)$ 计算均方误差，进而更新 $\theta$。 改进DQN： 一、构造 n-step Transition 维护一个长度为 n 的滑动队列 每步交互（状态 → 动作 → 奖励 → 新状态）后，都向队列里添加这条"单步经验"。 当队列中积累到 n 条经验时，就可以合并成一条"n-step transition"了。 合并过程（一步一步累加） 起始状态：取队列里第 1 条记录中的状态 $s_t$ 起始动作：取第 1 条记录中的动作 $a_t$ 累积奖励：把队列中前 n 条经验的即时奖励按折扣因子 $\gamma$ 一步步加权累加： $$ G_t^{(n)} = r_t + \gamma,r_{t+1} + \gamma^2,r_{t+2} + \cdots + \gamma^{n-1}r_{t+n-1} $$ 形成一条新样本 最终你得到一条合并后的样本： $$ \bigl(s_t,;a_t,;G_t^{(n)},;s_{t+n},;\text{done}_{t+n}\bigr) $$ 然后把它存入主 Replay Buffer。 接着，把滑动队列的最早一条经验丢掉，让它向前滑一格，继续接收下一步新经验。 二、批量随机采样与训练 随机抽取 n-step 样本 训练时，不管它是来自哪一段轨迹，都从 Replay Buffer 里随机挑出一批已经合好的 n-step transition。 每条样本就封装了"从 $s_t$ 出发，执行 $a_t$，经历 n 步后所累积的奖励加 bootstrap"以及到达的末状态。 计算训练目标 对于每条抽出的 n-step 样本 $(s_t,a_t,G_t^{(n)},s_{t+n},\text{done}_{t+n})$， 如果 $\text{done}{t+n}=\text{False}$，则 $$ y = G_t^{(n)} + \gamma^n,\max{a'}Q(s_{t+n},a';\theta^-); $$ 如果 $\text{done}_{t+n}=\text{True}$，则 $$ y = G_t^{(n)}. $$ 主网络给出预测 把样本中的起始状态-动作对 $(s_t,a_t)$ 丢给在线的 Q 网络，得到当前估计的 $\hat{Q}(s_t,a_t)$。 更新网络 用"目标值 $y$"和"预测值 $\hat{Q}$"之间的平方差，构造损失函数。 对损失做梯度下降，调整在线网络参数，使得它的预测越来越贴近那条合并后的真实回报。 VDN 核心思路：将团队 Q 函数写成各智能体局部 Q 的线性和 $Q_{tot}=\sum_{i=1}^{N}\tilde{Q}_i$，在训练时用全局奖励反传梯度，在执行时各智能体独立贪婪决策。 CTDE 指 Centralized Training, Decentralized Execution —— 在训练阶段使用集中式的信息或梯度（可以看到全局状态、联合奖励、各智能体的隐藏变量等）来稳定、加速学习；而在执行阶段，每个智能体只依赖自身可获得的局部观测来独立决策。 采用 CTDE 的好处： 部署高效、可扩展：运行时每个体只需本地观测，无需昂贵通信和同步，适合大规模或通信受限场景。 降低非平稳性：每个智能体看到的“环境”里不再包含 其他正在同时更新的智能体——因为所有参数其实在同一次反向传播里被一起更新，整体策略变化保持同步；对单个智能体而言，环境动态就不会呈现出随机漂移。 避免“懒惰智能体”：只要某个行动对团队回报有正贡献，它在梯度里就能拿到正向信号，不会因为某个体率先学到高收益行为而使其他个体“无所事事”。 核心公式与训练方法 值分解假设 $$ Q\bigl((h_1,\dots,h_d),(a_1,\dots,a_d)\bigr);\approx;\sum_{i=1}^{d},\tilde{Q}_i(h_i,a_i) $$ 其中 $h_i$ 为第 $i$ 个智能体的历史观测，$a_i$ 为其动作。每个 $\tilde{Q}_i$ 只使用局部信息；训练时通过对联合 $Q$ 的 TD 误差求梯度，再"顺着求和"回传到各 $\tilde{Q}_i$ 。这样既避免了为各智能体手工设计奖励，又天然解决了联合动作空间呈指数爆炸的问题。 Q-learning 更新 $$ Q_{t+1}(s_t,a_t);=;(1-\eta_t),Q_{t}(s_t,a_t);+;\eta_t\bigl[r_t+\gamma\max_{a}Q_{t}(s_{t+1},a)\bigr] $$ 论文沿用经典 DQN 的 Q-learning 目标，对 联合 Q 值 计算 TD 误差，然后按上式更新；全局奖励 $r_t$ 会在反向传播时自动分摊到各 $\tilde{Q}_i$ 。 训练过程 使用LSTM:让智能体在「只有局部、瞬时观测」的环境中记住并利用过去若干步的信息。 1. 初始化 组件 说明 在线网络 为每个智能体 $i=1\ldots d$ 建立局部 $Q$ 网络 $\widetilde Q_i(h^i,a^i;\theta_i)$。最后一层是 值分解层：把所有 $\widetilde Q_i$ 相加得到联合 $Q=\sum_i\widetilde Q_i$ 目标网络 为每个体复制参数：$\theta_i^- \leftarrow \theta_i$，用于计算贝尔曼目标。 经验回放缓冲区 存储元组 $(h_t, \mathbf a_t, r_t, o_{t+1}) \rightarrow \mathcal D$，其中 $\mathbf a_t=(a_t^1,\dots,a_t^d)$。 超参数 Adam 学习率 $1\times10^{-4}$，折扣 $\gamma$，BPTT 截断长度 8，Eligibility trace $\lambda=0.9$ ；小批量 $B$、目标同步周期 $C$、$\varepsilon$-greedy 初始值等。 网络骨架：Linear (32) → ReLU → LSTM (32) → Dueling (Value + Advantage) 头产生 $\widetilde Q_i$ 。 2. 与环境交互并存储经验 局部隐藏状态更新（获得 $h_t^i$） 采样观测 $o_t^i \in \mathbb R^{3\times5\times5}$（RGB × 5 × 5 视野） 线性嵌入 + ReLU $x_t^i = \mathrm{ReLU}(W_o,\text{vec}(o_t^i)+b_o),; W_o!\in!\mathbb R^{32\times75}$ 递归更新 LSTM $h_t^i,c_t^i = \text{LSTM}{32}(x_t^i,;h{t-1}^i,c_{t-1}^i)$ （初始 $h_0^i,c_0^i$ 置零；执行期只用本体状态即可） 动作选择（分散执行） $$ a_t^i=\begin{cases} \text{随机动作}, & \text{概率 } \varepsilon,\ \arg\max_{a}\widetilde Q_i(h_t^i,a;\theta_i), & 1-\varepsilon. \end{cases} $$ 环境反馈：执行联合动作 $\mathbf a_t$，获得单条 团队奖励 $r_t$ 以及下一组局部观测 $o_{t+1}^i$。 重要：此处不要直接把 $h_{t+1}^i$ 写入回放池，而是存下 $(h_t^i, a_t^i, r_t, o_{t+1}^i)$。 之后在训练阶段再用同样的“Step 0” 方式，离线地把 $o_{t+1}^i\rightarrow h_{t+1}^i$。 这样可避免把梯度依赖塞进经验池。 写入回放池：$(h_t, \mathbf a_t, r_t, o_{t+1}) \rightarrow \mathcal D$。 3. 批量随机采样并联合训练 对缓冲区达到阈值后，每次更新步骤： 采样 $B$ 条长度为 $L$ 的序列。 假设抽到第 $k$ 条序列的第一个索引是 $t$。 依次取出连续的 $(h_{t+j}, a_{t+j}, r_{t+j}, o_{t+j+1}), j=0, \ldots, L-1$。 先用存储的 $o_{t+j+1}$ 离线重放"Step 0"得到 $h_{t+j+1}$，这样序列就拥有 $(h_{t+j}, h_{t+j+1})$ 前向计算 $$ \hat Q_i^{(k)} = \widetilde Q_i(h^{i,(k)}_t,a^{i,(k)}t;\theta_i), \quad \hat Q^{(k)}=\sum{i}\hat Q_i^{(k)} . $$ 贝尔曼目标（用目标网络） $$ y^{(k)} = r^{(k)} + \gamma \sum_{i}\max_{a}\widetilde Q_i(h^{i,(k)}_{t+1},a;\theta_i^-). $$ 损失 $$ L=\frac1B\sum_{k=1}^{B}\bigl(y^{(k)}-\hat Q^{(k)}\bigr)^2 . $$ 梯度反传（自动信用分配） 因为 $\hat Q=\sum_i\widetilde Q_i$，对每个 $\widetilde Q_i$ 的梯度系数恒为 1， 整个 团队 TD 误差 直接回流到各体网络，无需个体奖励设计 。 参数更新：$\theta_i \leftarrow \theta_i-\eta\nabla_{\theta_i}L$。 4. 同步 / 软更新目标网络 硬同步：每 $C$ 次梯度更新后执行 $\theta_i^- \leftarrow \theta_i$。 软更新：可选 $\theta_i^- \leftarrow \tau\theta_i+(1-\tau)\theta_i^-$。 5. 重复直到收敛 持续循环步骤 2–4，逐步衰减 $\varepsilon$。 训练完成后，每个体只需本地 $\widetilde Q_i$ 就能独立决策，与中心最大化 $\sum_i\widetilde Q_i$ 等价 。
论文
zy123
6月17日
0
3
0
上一页
1
2
3
4
...
12
下一页
