这个项目我专门做了三项可量化验证，目标是证明风控、降级和消息一致性不是“接了就完”，而是有结果闭环。
1）责任链风控拦截率
我把交易锁单接口当作压测入口，固定构造一批“非法/受限请求”样本，循环发起 200 次请求，统计返回码。
最终结果是 200 次全部被拦截，拦截率 100%。
接口是
lock_market_pay_order样本是固定受限用户 + 合法结构参数（避免参数非法导致误判）
每次更换
outTradeNo，避免幂等缓存影响统计
为什么可信：
我不是看日志主观判断，而是按“总请求数/被拦截数”程序化计数，直接算比例。
2）动态降级开关下 QPS / P95
我通过 DCC 接口动态切换 downgradeSwitch=0/1，在同一个接口、同一套请求体、同一压测工具参数下跑 A/B 对比。
最终拿到：
降级关闭：
14.00 QPS，P95=27ms降级开启：
1010.23 QPS，P95=15ms
我重点强调两点：
这是“同口径对比”（同接口、同请求体、同并发参数），不是两次不同场景硬比。
压测过程中有过网络长尾，我只采用“完整跑完且参数一致”的结果作为最终口径。
为什么可信：
有明确开关变量（只变一个因子），并且结果同时体现吞吐提升 + 尾延迟改善，不是单指标偶然抖动。
3）本地消息表投递成功率
我直接从本地消息表 notify_task 做状态统计，不靠业务口头描述。
统计口径：成功条数 / 总条数，其中成功状态是 notify_status=1。
结果是 4/4，成功率 100%。
为什么可信：
这是数据库落表后的最终状态统计，属于结果数据，不是中间过程日志。
你如果继续追问“怎么保证可复现？”
我会这样回答：
环境固定：Docker 起 MySQL/Redis，应用使用同一版本配置启动。
入口固定：交易锁单接口作为统一压测入口。
变量隔离：性能测试只切
downgradeSwitch，其余参数不变。统计可追溯：
风控：请求计数脚本输出拦截比例
性能：AB 原始报告（QPS、P95）
消息：SQL 聚合结果
异常处理透明：出现库表不一致/依赖超时时先修复再测，不把异常环境下的数据当最终结论。
一句话高密度版本（面试收尾）
我对这个项目做了结果闭环验证：责任链风控拦截率 100%（200/200）、动态降级开关把接口从 14.00 QPS / P95 27ms 提升到 1010.23 QPS / P95 15ms、本地消息表最终投递成功率 100%（4/4）；并且三项都是按固定口径可复现统计出来的。