59 lines
3.5 KiB
Markdown
59 lines
3.5 KiB
Markdown
# 消费机创建订单分段耗时
|
||
|
||
外部接口 `/hard/hard-api/ad/create-order` 对应 hard 服务内部
|
||
`POST /hard-api/ad/create-order`。本次诊断仅观察该请求，不改变请求协议、
|
||
事务注解、分布式锁、支付顺序、重试和返回值。
|
||
|
||
## 日志策略与开销
|
||
|
||
- 通过 `System.nanoTime()` 和请求内存中的阶段表计时，不新增 SQL、Redis 或 Feign 请求。
|
||
- 正常且小于 1 秒的请求不新增摘要；慢请求、失败及阶段内被业务处理的异常输出一条 warning。
|
||
- 摘要在过滤器链返回或抛错后统一生成，不在扣款写事务中逐阶段输出日志。
|
||
- 专用 Logback 异步队列容量为 256，`neverBlock=true`。队列满时丢弃诊断摘要，不等待落盘。
|
||
- 使用已有 `debug.log` 文件；不写入 DTO、人员资料、金额、令牌、付款码、图片或异常消息。
|
||
|
||
计时与内存分配存在少量开销，不能承诺零开销。异步队列优先保障请求返回，
|
||
日志管道持续拥堵时可能缺少部分诊断记录。
|
||
|
||
## 取日志与匹配
|
||
|
||
部署包含 Java 代码和 `logback-spring.xml` 改动的 hard 服务后，在 `debug.log`
|
||
搜索 `|终端支付耗时|`。按 `androidOrderCode` 与消费机的 `|支付耗时|` 摘要、
|
||
原有订单 SQL 对齐；同号重试可通过不同的 `trace` 区分请求。
|
||
|
||
`outcome:failed` 是请求未正常完成，不能单凭这一字段判断钱包是否已经扣款；
|
||
仍需按原有订单对账逻辑确认。旁路通知或证据登记异常被业务自行处理时，
|
||
请求可能保持 `outcome:success`，异常类型保存在 `stageErrorTypes` 中。
|
||
|
||
## 主要阶段
|
||
|
||
| 字段 | 范围 |
|
||
| --- | --- |
|
||
| `pre_controller` | 请求监听器开始至 Controller 进入，含期间租户检查、认证、解析及校验 |
|
||
| `controller` | Controller 参数整理、Service 调用和返回对象创建 |
|
||
| `redis.lock` / `redis.unlock` | 原有 Redis 加锁、持锁检查及解锁 |
|
||
| `idempotency.lookup` / `idempotency.validate` | 原订单查询及重复请求一致性校验 |
|
||
| `prepare` | 下单准备整体，含下面的远程及本地查询 |
|
||
| `prepare.merchant` / `prepare.hardware` | 商户远程查询、设备本地查询 |
|
||
| `prepare.user` / `prepare.wallet` / `prepare.cart` | 用户、钱包及商品计价准备 |
|
||
| `transaction` | 原有代理事务调用，包含事务开始、提交及同步 afterCommit |
|
||
| `db.cart` / `db.orderInsert` | 购物车和订单写入 |
|
||
| `wallet.debit` | 原有钱包扣款远程调用 |
|
||
| `db.orderPaid` / `db.cartPaid` | 已支付状态更新 |
|
||
| `afterCommit.evidence` | 原有同步人脸证据元数据登记 |
|
||
| `postCommit.notify` | 原有提交后打印/播报分支 |
|
||
|
||
`stagesInclusiveMs` 单位为毫秒，父阶段包含子阶段，不能直接相加。
|
||
其他支付方式仍按原逻辑执行，日志可出现核销、库存及第三方支付阶段。
|
||
|
||
## 时间边界
|
||
|
||
监听器在 Servlet 过滤器之前记录起点，专用过滤器在原有租户过滤器之后、
|
||
安全过滤器之前绑定请求追踪，不调整已有过滤器顺序。
|
||
若请求在更早的租户过滤器中直接拒绝，尚未进入计时过滤器，则不会产生本摘要。
|
||
|
||
`totalMs` 截止过滤器链返回，不是客户端端到端耗时；不覆盖网关和入站网络、
|
||
容器调用请求监听器前的排队、最后的响应传输，以及客户端本地处理。
|
||
因此“客户端 4500ms、服务摘要 200ms”只能证明还需排查摘要计时区间之外的等待，
|
||
不能直接认定为 Flutter 程序卡顿。
|