docker-compose:
```yml
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:
```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`)，需重启容器生效：
```bash
docker compose restart group-buy-market-front
```
**Java 后端服务 (`group-buying-sys`)**
- **代码位置**：通过镜像构建（`build` 指定了 Dockerfile 路径）。
- 修改影响
- 如果修改了 Java 代码或依赖（如 `pom.xml`），**必须重建镜像**：
```bash
docker compose up -d --build group-buying-sys
```
**其他服务（MySQL/Redis/RabbitMQ/Nacos）**
- **代码位置**：均使用官方镜像，无业务代码。
- 修改影响
- 修改配置文件（如 ./redis/redis.conf）需重启容器：
```bash
docker compose restart redis
```
- **无需 `--build`**（除非你自定义了它们的镜像）。
## 系统备忘录
本系统涉及微信和支付宝的回调。
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非空，指明是拼团成功通知还是用户退单通知。
若为拼团成功通知，小商场将订单中相应拼团的status都设置为deal_done，然后小商场内部也再发一个'支付成功'消息，主要用于通知这些拼团对应的订单进入下一环节：发货（感觉'支付成功'取名不够直观）。
若为用户退单通知，小商场需处理退款业务。
## 系统设计
### **库表设计**
- 首先，站在**运营**的角度，要为这次拼团配置对应的**拼团活动**。那么就会涉及到；给哪个渠道的**什么商品**ID配置拼团，这样用户在进入商品页就可以看到带有拼团商品的信息了。之后要考虑，这个拼团的商**品所提供的规则信息**，包括：折扣、起止时间、人数等。还要拿到折扣的一个**试算金额**。这个试算出来的金额，就是告诉用户，通过拼团可以拿到的最低价格。
- 之后，站在**用户**的角度，是参与拼团。首次**发起一个拼团**或者**参与已存在的拼团**进行数据的记录，达成拼团约定拼团人数后，开始进行**通知**。这个通知的设计站在平台角度可以提供回调，那么任何的系统也就都可以接入了。
- 另外，为了支持拼团库表，需要先根据业务规则把符合条件的用户 ID 写入 Redis，并为这批用户打上可配置的**人群标签**。创建拼团活动时，只需关联对应标签，即可让活动自动面向这部分用户生效，实现精准运营和差异化折扣。
- 那么，拼团活动表，为什么会把**折扣拆分**出来呢。因为这里的折扣**可能有多种**迭代到一个拼团上。比如，给一个商品添加了直减10元的优惠，又对符合的人群id的用户，额外打9折，这样就有了2个折扣迭代。所以拆分出来会更好维护。这是对常变的元素和稳定的元素进行设计的思考。
#### **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 | 回调种类 |
| 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架构：**
## 价格试算
```java
@Service
@RequiredArgsConstructor
public class IndexGroupBuyMarketServiceImpl implements IIndexGroupBuyMarketService {
private final DefaultActivityStrategyFactory defaultActivityStrategyFactory;
@Override
public TrialBalanceEntity indexMarketTrial(MarketProductEntity marketProductEntity) throws Exception {
StrategyHandler在 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）。 ### 人群标签过滤 白名单。 **无 tagId**（没配标签）→ 不限人群，全部放行（`visible=true, enable=true`）。 **有 tagId 且位图存在** → **位图里的人可以参加**（白名单）。 **有 tagId 但位图不存在** → 现在的实现是**默认全放行**（把“未配置位图”当作“不限制”），因为真实场景中由外部系统统计用户行为=>将符合条件的用户放入位图中，这里暂时没有模拟。 ## 拼团交易锁单  下单到支付中间有一个流程，即锁单，比如淘宝京东中，在这个环节（限定时间内）选择使用优惠券、京豆等，可以得到优惠价，再进行支付；拼团场景同理，先加入拼团，进行锁单，然后优惠试算，最后才付款。 ## 拼团结算
## 对接商城和拼团系统
### 拼团锁单
**1.用户下单**（小型支付商城发起）
- 检查是否存在未支付订单：
- 有 `pay_url` → 返回该支付链接
- 无 `pay_url` → 进入创建订单流程
**2.创建订单**
- 如果存在订单但未支付（无 `pay_url`）→ 继续创建支付
- 进入 **营销锁单**（判断是否有营销活动参与，调用拼团系统中的责任链校验：活动有效性、用户参与活动次数、剩余库存数校验，校验通过即可获取营销优惠；否则只能原价购买商品！！！）
- 超时订单关闭（由任务调度触发）
**3.营销锁单**（调用拼团交易平台接口）
- 请求 Nginx 负载，转发至拼团交易平台的**营销锁单模块**
- 拼团交易平台内部执行：
1. 锁单目标
2. 优惠试算
3. 规则过滤（活动有效性、用户参与活动次数、剩余库存数校验）
4. 写入记录（数据库）
5. 返回结果：订单ID、原价、折扣金额、支付金额、订单状态
**返回商城**
- 小型商城获取优惠后的价格信息
- 创建支付订单
### 支付完成与组队结算
**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` 即可引用该模块，如下所示：
```xml
逆向的流程，要分析用户是在哪个流程节点下进行退单行为。包括3个场景；
**已锁单、未支付**：redis恢复量+1，mysql中锁单量-1
**已锁单、已支付，但拼团未成团**：redis恢复量+1，mysql中锁单量、完成量-1，退款
**已锁单、已支付，且拼团已成团**：redis恢复量无需+1，因为成团之后不开放给别人；mysql中锁单量、完成量-1，退款，拼团设置为'已完成含退单'状态，但拼团中所有人都退单，更新为失败！
### 核心流程说明
#### 阶段一：退单操作流程
1. 客户**主动提交**退单请求
2. 通过责任链模式处理：数据加载Node（查询订单） → 重复检查Node（防止重复退单） → 策略执行Node
3. 策略选择
根据订单状态和拼团状态选择对应退单策略（三种之一）
4. 执行退单
更新**数据库**操作（锁单量、完成量、拼团状态、订单状态...）
5. 消息通知 + 任务补偿
发送MQ退单消息通知（未支付退单、已支付未成团...三种消息 notify_category）
将消息写入notify_task表，定时任务扫描未成功处理的消息，以做补偿兜底。
#### 阶段二：库存恢复流程
6. 消息监听
MQ**监听器接收**退单成功消息
7. 服务调用
调用恢复库存服务
8. 策略选择
根据退单类型选择对应策略（已成团的无需恢复了，反正新用户也无法再参与该拼团）
9. 库存恢复
执行Redis库存恢复操作（带分布式锁保护）
---
### 设计模式应用
1. **责任链模式**
`TradeRefundRuleFilterFactory` 构建的过滤链：
`DataNodeFilter` → `UniqueRefundNodeFilter` → `RefundOrderNodeFilter`
2. **策略模式**
- 策略接口：`RefundOrderStrategy`
- 实现策略：
`Unpaid2RefundStrategy`（未付款退单的流程）
`Paid2RefundStrategy`（已付款退单）
`PaidTeam2RefundStrategy`（已成团退单）
3. **工厂模式**
`TradeRefundRuleFilterFactory` 负责组装责任链
4. **模板方法模式**
`AbstractRefundOrderStrategy` 提供：
- 公共方法封装 （发送退单MQ消息、库存恢复redis）
- 依赖注入支持
### 退单触发入口
1）用户主动退单
2）定时任务，定时任务扫描锁单但未结算的订单，若支付时间超过设定值，对这笔订单执行退单操作。
注意：小型支付商城中的订单可能有些是普通订单，有些是拼团订单。
对于普通订单，无需调用拼团系统中的退单接口，自己本地退单，对于CREATE或PAY_WAIT状态的订单，直接修改订单状态为CLOSED；对于PAY_SUCCESS（个人支付完成）、DEAL_DONE，额外调用支付宝退款。
对于拼团订单，RPC调用拼团系统的退单接口，调用成功后设置订单为WAIT_REFUND，然后由MQ消息回调调用支付宝退款。
## MQ消息通知
有三种MQ消息：
1.退款成功通知
2.拼团组队成功通知
3.订单支付成功消息
退款成功消息：拼团系统发送，拼团订单。小型商城和拼团系统都接收，各自执行退单流程。
组队成功消息：拼团系统发送，拼团订单。主要是小型商城接收，更新订单状态；拼团系统仅仅是简单的打印一下'通知成功'消息。
订单支付成功消息：小型商城发送，拼团订单+普通订单。小型商城接收，更新订单状态=>模拟发货。
不仅在相关接口完成的时候自动发送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 | 更新时间 |
## 收获
### 实体对象
实体是指具有唯一标识的业务对象。
在 DDD 分层里，**Domain Entity ≠ 数据库 PO**。
在 `edu.whut.domain.*.model.entity` 包下放的是**纯粹的业务对象**，它们只表达业务语义（团队 ID、活动时间、优惠金额……），对「数据持久化细节」保持**无感知**。因此它们看起来“字段不全”是正常的：
- 它们不会带 `@TableName` / `@TableId` 等 MyBatis-Plus 注解；
- 也不会出现数据库的技术字段（`id`、`create_time`、`update_time`、`status` 等）；
- 只保留聚合根真正**需要的**业务属性与行为。
```java
@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 能唯一标识这个实体。
### 多线程异步调用
如果某任务比较耗时（如加载大量数据），可以考虑开多线程异步调用。
```java
// Runnable ➞ 只能 run()，没有返回值
public interface Runnable {
void run();
}
// Callable
#### 核心思路
**动态开关管理**
- 使用 `@DCCValue("rateLimiterSwitch:open")` 从配置中心动态注入全局开关，支持热更新。
- 当开关为 `"close"` 时，直接放行所有请求，切面不再执行限流逻辑。
**AOP 切面拦截**
- 通过自定义注解 `@RateLimiterAccessInterceptor` 标记需要限流的方法。
- 注解参数 `key` 用于指定限流维度（如 `userId` 表示按用户限流，`all` 表示全局限流）。
- 切面在运行时解析这个字段的值，动态生成 Redis 限流器 Key，例如：
```java
//添加拦截注解
@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
```
**限流与黑名单**
- 使用 `RRateLimiter` 实现分布式令牌桶，每秒放入 `permitsPerSecond` 个令牌。
- 取不到令牌时：
- 如果配置了 `blacklistCount`，用 `RAtomicLong` 记录该 Key 的拒绝次数；
- 拒绝次数超限后，将 Key 加入黑名单 24 小时。
- 命中黑名单或限流时，调用注解里的 `fallbackMethod` 执行降级逻辑。
**令牌桶算法（Token Bucket）**
- **工作原理**：按固定速率往桶里放“令牌”（tokens），例如每秒放 N 个。每次请求到达时，必须先从桶中“取一个令牌”，才能通过；如果取不到，则拒绝或降级。
- **特点**：支持流量平滑释放和突发流量吸纳，桶最多能存储 M 个令牌。
```text
方法调用
↓
AOP 切面拦截（匹配 @RateLimiterAccessInterceptor）
↓
检查全局限流开关（@DCCValue 注入）
↓
解析注解里的 key → 获取对应参数值（如 userId）
↓
黑名单检查（RAtomicLong）
↓
分布式令牌桶限流（RRateLimiter.tryAcquire）
↓
├─ 成功 → 执行目标方法
└─ 失败 → 累加拒绝计数 & 调用 fallbackMethod
```
| 对比维度 | 本地限流 | 分布式限流 |
| ----------------- | ---------------------------------------------------- | ------------------------------------------------------------ |
| 实现复杂度 | **低**：直接用 Guava `RateLimiter`，几行代码即可接入 | **中高**：依赖 Redis/Redisson，需要注入客户端并管理限流器 |
| 性能开销 | **极低**：全程内存操作，纳秒级延迟 | **中等**：每次获取令牌需网络往返，存在 RTT 延迟 |
| 限流范围 | **单实例**：仅对当前 JVM 有效，多实例互不影响 | **全局**：多实例共享同一套令牌桶，合计速率可控 |
| 状态持久化 & 容错 | **无**：服务重启后状态丢失；实例宕机只影响自身 | **有**：Redis 存储限流器与黑名单，可持久化；需保证 Redis 可用性 |
目前本项目采用 **分布式限流**，使用 **Redisson** 实现跨实例令牌桶，确保全局限流控制。
### 日志系统
#### 输出流向一览
输出到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:
```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配置：
```yml
#
# ** 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配置:
```conf
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}"
}
}
```
自己的项目：
```java