 Zhou Weidong
|
8fb1f52777
|
fix(config): 调度线程池扩到 4 条，避免落库与其它定时任务互相排队
|
2026-10-28 18:51:52 +08:00 |
|
|
Zhou Weidong
|
3e2d6a06d9
|
perf(playback): 观看进度上报异步化（Redis write-behind 批量落库）
- POST /app/watch/progress 只写 Redis 缓冲立即返回（p95 75ms→2ms），
WatchProgressFlusher 每 2s 把 watch:pg:dirty 队列按身份合并批量 UPSERT，
Redis 异常自动回退同步写库，接口契约不变
- 读接口用缓冲覆盖 DB 行保证读己之写；Caffeine 缓存剧集校验免去上报路径两条 DB 查询
- 落库按「新增进度/新增流水/更新行」分组攒批（MyBatis BATCH 只合并连续同形状语句），
配合 reWriteBatchedInserts 多值 INSERT，12.4 万积压 45 秒消化完，
1650 QPS 持续压测队列稳态归零
|
2026-10-28 14:59:09 +08:00 |
|
|
Vicky
|
272aa62434
|
feat: phase1 UI prep — P1 安全(XFF防护), P2 规模化(平台索引+region保护), P3 文档补全
P1 安全: WebUtils.getClientIp 改为 remoteAddr 优先 + 可信代理 CIDR 配置
P2 规模化: DISTINCT ON 查询补匹配排序的部分索引 (migrate-k113)
P2 一致性: syncCountryByIp regionCode 同语言/时区/币种加保护，不覆盖用户自定义
P3 文档: api-phase1.md 新增 platform 参数说明, IpRegionService 新增集成测试 + VERSION
新增: CountryProfile 52 国映射 + IpRegionService 离线 ip2region 解析
平台筛选: app-users/favorites/likes/watch-history 按最近一次会话 ANDROID/IOS 筛选
|
2026-10-27 15:45:15 +08:00 |
|
|
Zhou Weidong
|
32710c2e06
|
feat: 接入 Prometheus 监控（放行 /actuator/prometheus + 指标暴露 + compose 编排）
|
2026-10-21 06:28:11 +08:00 |
|
|
Zhou Weidong
|
fa4977a71d
|
feat: C2 Redis 接入 + 接口限流（RedisService + @RateLimit，验证码/登录防刷）
|
2026-10-21 06:24:55 +08:00 |
|
|
Zhou Weidong
|
35d92c0148
|
fix(backend): 后台注册限流配置优先并保留注入兜底
|
2026-10-17 23:39:48 +08:00 |
|
|
Zhou Weidong
|
f1aaaee814
|
fix(backend): 改为后台配置注册限流阈值
|
2026-10-17 23:29:25 +08:00 |
|
|
Zhou Weidong
|
758eb69f55
|
feat(backend): 注册限流阈值改为可配置
|
2026-10-17 23:22:28 +08:00 |
|
|
jianghaifeng
|
b567365460
|
feat(deploy): D1 后端部署就绪（配置外置 + prod fail-fast + 自包含 Compose + 冒烟/回滚）
为什么：用户下午要部署，但全仓没有任何部署产物；且生产漏配密钥会静默使用代码里的 dev 默认值，
属上线阻塞项（04-部署架构 / 12-上线检查清单）。
- 配置外置（三件）：DB_URL、JWT 双密钥（**发现 app-secret 此前没外置，一直用 dev 默认值**）、
MEDIA_SIGNATURE_SECRET、MEDIA_SIGNATURE_REQUIRED、CORS_ALLOWED_ORIGINS、MEDIA_ROOT_DIR
- 新增三份 application-prod.yml：签名强制开启、CORS 收紧、媒资指向挂载点、日志级别
- 新增 ProdSecretGuard（@Profile("prod")）：密钥缺失/仍是 dev 默认值/不足 32 位、签名未开、
DB_URL 或 CORS 为空 → 一次列全并终止启动（exit 1）
- 新增 /healthz 轻量健康端点：查明 /actuator/health 的"超时"是旧 jar 未重启所致，项目本就
没有 actuator 依赖，故不引新依赖；同时把 /healthz 加进安全白名单
- Docker 化：多阶段 Dockerfile（非 root、tini、依赖层缓存、ffmpeg 只给 worker）、.dockerignore、
自包含 docker-compose.yml（含 PostgreSQL 18 + Redis + 命名卷 + 按序初始化 sql + healthcheck）
- tools/smoke.sh（失败非 0 退出）+ DEPLOY.md（Compose 主线 / 裸 jar 兜底 / 回滚 / 故障速查）
- 实测：mvn test 83 条全过；两入口 package 通过；prod 缺密钥退出码 1 且报错明确、配齐后正常启动；
冒烟脚本全 PASS；本机无 Docker，镜像与 compose 未经构建验证（已在回执如实标注）
|
2026-10-16 13:01:08 +08:00 |
|
|
Zhou Weidong
|
db897d50d6
|
feat(commerce): Google Play 票据校验闭环（校验→建单→发权益 + 幂等/防重放）
为什么：风险清单 R-03 把支付票据校验列为上线阻塞项；/app/orders/verify 此前只有 disabled
占位，且 verifyAndDeliver 要求订单事先存在——而 IAP 没有下单接口，接了校验也走不通。
- 新增 GooglePlayStoreVerifier（校验 purchaseState/productId/orderId）+ StorePlatforms（平台归一化）
- 新增 GooglePlayPurchaseClient 端口与 HttpGooglePlayPurchaseClient：JDK HttpClient + 服务账号
RS256 JWT 换 token，不引入 Google SDK 依赖；token 按过期缓存
- StoreVerifier 实现由 fruitshorts.commerce.store.verifier 选择，默认 disabled，无凭据时对外行为不变
- OrderService 补齐闭环：校验通过后按 (platform, storeProductId) 找商品建单、写 store_receipt 审计、
发金币并推进到 DELIVERED；幂等键 (platform, storeTransactionId) 与唯一索引双保险
- 防重放：重复提交同用户返回既有订单且不再发币；票据已被他人使用返回 403；校验失败不写任何数据
- 凭据只走配置/环境变量（packageName + service account JSON），不入库不提交
- 契约同步 docs/api-phase1.md §1.8；金额微单位换算与回退价有单测覆盖
- 实测：mvn test 54 条全过（commerce 13 + app-api 41，M2 的 37 条未被打红）；
两个入口 package 通过；默认 disabled 端到端返回 200003 且 orders 表零行
|
2026-10-16 11:03:33 +08:00 |
|
|
Zhou Weidong
|
27e689c771
|
fix(config): 修复合并后 app-api 重复的 springdoc 配置键
|
2026-10-16 10:52:17 +08:00 |
|
|
Vicky
|
5ce6de1e3b
|
Merge remote-tracking branch 'origin/main'
|
2026-10-16 10:51:15 +08:00 |
|
|
Vicky
|
c6fcfcc6ea
|
docs(backend): S1 接口文档在线化——补 springdoc 配置 + 39 个 Controller 中文注解
为什么：前端联调依赖在线接口文档。S1 条目要求两个端口的 /v3/api-docs 能看、
且每个接口有中文分组与中文 summary。
诊断（与 PM 初步定位不同，有硬证据）：app-api 的 /v3/api-docs、/doc.html、/、
/error 全部"挂住"（8s 超时 0 字节），根因不是 Spring Security 拦截，而是
运行中的进程握着一个被重新打包替换掉的旧 jar——spring-boot:repackage 把原 fat jar
原地改名为 .jar.original（同一 inode）再写新 jar，进程再去加载"启动后未加载过的类"
就必然 NoClassDefFoundError（日志里连 logback 的 ThrowableProxy 都加载不到），
线程直接死掉、既不响应也记不了日志。SecurityConfig.PUBLIC_PATHS 本来就包含
/doc.html、/swagger-ui/**、/v3/api-docs/**，未改任何安全配置。
- app-api 的 application.yml 补 springdoc.swagger-ui.path: /doc.html
- 39 个 Controller（app-api 10 + admin-api 29）补 @Tag(name=中文分组)
与 @Operation(summary=中文描述)，共 172 个接口；描述取自 api-phase1.md 与既有 Javadoc
- 两个入口类加 @OpenAPIDefinition：文档标题 + 顶层 tags 清单（springdoc 默认顶层 tags 为空）
- 纯新增 357 行、删除 0 行：业务逻辑、路径、字段零改动
- 实测：mvn test 37 条契约测试全过；两个入口 package BUILD SUCCESS；
两端口 /v3/api-docs 中文 tags + 中文 summary，/doc.html 可打开，
非白名单路径 5ms 内返回 {"code":401,...} 不再挂住
|
2026-10-16 10:44:37 +08:00 |
|
|
Zhou Weidong
|
66e6fc1555
|
feat: app-api 启用 Swagger 在线接口文档 (springdoc /doc.html)
|
2026-10-16 10:13:47 +08:00 |
|
|
Vicky
|
37c9a141d3
|
feat: S0 主键改雪花（DDL 去 identity + 实体 ASSIGN_ID + 雪花配置）
为什么：自增主键把 ID 分配锁在单库序列上，分库分表时无法横向扩展。趁线上业务数据
近零（只有系统种子表有量）先改，代价最低。
- sql/schema.sql、sql/schema-phase1.sql、sql/partition-maintenance.sql：61 处
GENERATED BY DEFAULT AS IDENTITY 去掉，主键改 BIGINT 无默认值
- 52 个实体 @TableId IdType.AUTO -> IdType.ASSIGN_ID；两个入口 id-type: assign_id，
并加 global-config.sequence.worker-id/datacenter-id（单机固定值，多实例需按实例分配）
- 新增 sql/migrate-s0-snowflake.sql：存量库幂等迁移，走 DROP IDENTITY 保留数据，不重建表
- 实测：三份建表脚本在新库连跑两遍幂等；线上 57 张表 identity 归零；
watch_history/playback_ticket/order_event 的主键与唯一索引仍含分区键
|
2026-10-16 09:00:38 +08:00 |
|
|
Zhou Weidong
|
35be37c193
|
style: 全量补充作者标识 // Author: fruit.com.cn
|
2026-10-16 00:01:53 +08:00 |
|
|
Vicky
|
af1dc48494
|
feat: 06 互动与内容治理落地（评论 / 点赞 / 举报 / 敏感词 / 审核留证）
为什么：
1) 产品侧要先把内容治理闭环跑通才能谈上线：评论可发布、可翻页、可删除，
违规内容能在后台被审核与驳回，举报要有工单可追溯。本提交把这套补齐。
2) 审核不能只靠人肉：敏感词按 BLOCK/REPLACE/REVIEW 三档处置，
机审通过即发布（可配置为 PRE_REVIEW 全部先审后发），人审与机审的结论
都写进 content_audit_record，争议时可回答"当时凭什么放行/驳回"。
3) 举报处理必须与处置打通：结论成立会联动驳回被举报评论，并可选同时封禁被举报用户，
避免"工单处理完了但违规内容还挂着"。
4) 顺带修复一个真实缺陷：user_favorite / content_like 上有唯一索引，而全局配置会把
deleteById 改写成逻辑删除，导致取消收藏/点赞后旧的 deleted 行仍占位，
再次收藏或点赞直接撞唯一索引报错。关系类数据没有留证价值，改为显式物理删除，
并补了"取消后再来一次"的回归自测。
|
2026-10-15 12:03:32 +08:00 |
|
|
Vicky
|
b3179fc836
|
refactor: 后端标识统一为 FruitShorts，并落地 05 离线下载
为什么：
1) 产品已定名 FruitShorts，但后端仍是 reelshort 系列标识 —— Java 包 com.reelshort、
模块名与 jar 名 reelshort-*、spring.application.name、配置前缀 reelshort.*，
这些会出现在启动日志、命令行和 IDE 里，与产品名不一致。本次整体替换为 fruitshorts，
数据库连接名上一轮已改名，保持不变。
2) 第一阶段下一批第 1 步（05 离线下载）要求把下载授权（设备绑定/有效期/吊销）、
下载任务与断点续传、配额与过期清理、仅 Wi-Fi 规则做成完整接口，本提交一并落地。
3) 顺带修复：schema-phase1.sql 里 playback_ticket / order_event 仍按普通表定义唯一索引，
表分区化之后重跑脚本必定报错（分区表的唯一索引必须包含分区键）。改为在本脚本里就
按分区表定义，并验证脚本可重复执行。
|
2026-10-15 11:44:26 +08:00 |
|