1. 亿级粉丝大 V 下的交易 高性能架构与成本优化 快手电商 / 张钦贤

2.

3. 个人介绍 & 演讲目录 张钦贤 · 快手电商 · 技术专家 演讲目录 负责快手电商正向交易的架构升 Ø 快手电商交易大V直播流量特点 级、稳定性保障、成本性能优化 Ø 快手电商交易架构面临的核心挑战 等工作，2021 年 11 月入职后成 功完成多项重大项目，包括交易 订单模型升级、交易平台化架构 建设、高可用稳定性保障、白盒 Ø 快手电商交易架构高性能解决方案 Ø 如何高性能高并发扣减库存？ Ø 如何高性能实现分布式事务？ 化成本性能优化等，将交易系统 Ø 如何高性能管理下游依赖调用？ 的稳定性和性能提升到电商领域 Ø 如何设计高性能的数据访问接口？ 第一梯队。 Ø 如何在业务高速增长同时优化成本？

4. 快手电商交易大V直播流量特点 快手直播电商：不定时、脉冲式超高秒杀交易流量 1亿+ 粉丝 近500w人 同时在线 近100w每 秒下单请求

5. 快手电商交易架构面临的性能和成本挑战 架构原则&目标：保持牢固稳定性、流畅性能体验、追求低成本 Ø1、单热点商品库存扣减难度大 Ø2、下单分布式事务性能要求高 Ø3、依赖服务多编排调用复杂 交易下单需要扣减库存 等资源，然后保存订单 快手某大V有1亿+高粘性粉丝，经常推出库存为几 百万的1元低价商品，造成业界最高的单热点商品 扣减流量，远大于友商 到数据库，是一个典型 的分布式事务问题，面 临CAP和高性能的挑战 Ø4、业务体量增长带来成本上升 交易依赖几十个下游业务的上百个依赖方法，依赖 管理复杂性高，串行调用会导致RT累积，影响系统 的稳定性和用户体验 Ø5、订单承载信息多，模型和接口扩展性要求高 业务持续高速发展，随着 随着电商业务的不断高速发展，定制业务需求数量快速增长，交易订单模型和 时间积累，数据量成指数 数据访问接口要求能够快速高性能支撑各种灵活的定制逻辑 级增长，数据量的提升也 必将带来一系列问题，例 如成本升高、性能变差

6. 快手电商交易架构针对上述挑战的整体解决方案 Ø 高性能API流量管理： 精准流量预估&限流避 直播 API网关 短视频 买家首页 流量 店铺 安全防刷单避免黑产攻击 多端入口支持 Native RN 免流量超限，请求排队提供良好的限流用户体验， 活动 请求排 队能力 精准限 流模块 H5 安全防刷 单模块 Ø 高性能库存扣减： Redis和DB容灾双活能力， 最大限度保障稳定性和高性能 交易服务 购物车 订单确认 下单 订单管理 超时任务 Ø 高性能分布式事务： 下单同步扣减下游资源、 高性能库存扣减 Mysql 库存扣减 高性能分布式事务 Redis 库存扣减 同步扣减 容灾&热点商品切换 交易存储 异步回退 废单消息&数据对账 订单库 买家索引库 扩展字段 订单打标 商品查询 店铺查询 营销校验 库存扣减 限购扣减 保存订单… 卖家索引库 高性能可扩展的订单模型和数据接口 主子单 失败异步回退，废单消息保障一致性和高性能 高性能依赖管理调用 卖家ES Hive/Redis Ø 高性能下游依赖调用： 下游依赖分级保障稳定 性，异步调用编排实现高性能 Ø 高性能订单模型和数据接口： 订单主子单模型 +扩展字段灵活支持业务，按需查询提升性能 冷热数据归档优化成本 按需查询 在线库 历史库 定时归档 联合查询 Ø 冷热数据归档优化成本： 在线库数据定时同步 到历史库，提供联合查询能力对业务透明

7. 1、高性能高并发秒杀库存扣减 快手有1亿+粉丝的大V，经常推出库存几百万单的1元低价福利商品， 造成业界最高的单热点商品扣减流量，远大于友商。 日常大V没有开播的 情况下又会恢复到较低的流量，这种脉冲式流量对库存存储架构的稳定性、性能、一致性带来了极大挑战。 库存存储方案选型 优点 缺点 全部使用Mysql 数据可靠性要高，主从切换可以做到不丢数据 单key写入能力大幅低于Redis，需要搭建从库来支撑 读能力，成本较高 全部使用Redis 能支持超高的单key查询和扣减、性能高、存 在主从切换、主备切换时存在数据丢失的可能 储成本低 大V直播期间全部使用 非高峰期间不需要担心数据丢失，高峰期间可 切换时，需要停写，会影响所有商品的售卖，导致切 Redis，非高峰期使用 以支撑热点商品库存扣减，保障下单成功率 换时间GMV跌零 大V售卖热点商品使用 非大V售卖热点商品不需要担心数据丢失，大V 需要提前获得大V售卖的热点福利商品，通过白名单 Redis，其他商品使用 售卖商品可以支撑热点商品库存扣减，保障下 方式维护, 在操作时需要对这部分商品停写, 实现逻辑 MySQL 单成功率，切换停写只影响部分商品售卖 会复杂 MySQL 出于数据可靠性、保障GMV这两个关键指标，选用方案4，并对MySQL进行深度优化，将单行 更新能力提升至10w/s+

8. 1、高性能高并发秒杀库存扣减 快手交易秒杀库存应对方案 访问端 业务 服务 快手APP 快手极速版 导购场景 Ø 双存储优势结合： 提前获取到大V售卖的商品id，当这些商品下单时使用Redis进行 快手商家后台 快手开放平台 管理场景 导购场景 商详 小黄车 提单页 下单 localcache localcache localcache 商品 管理 库存 领域 服务 库存 存储 读请求 写请求 MySQL库 存数据 Redis binlog 覆盖Redis，如果商品为大V售卖商品，则修改MySQL。 Ø 数据一致性对账： 定期全量扫描DB和Redis全量对账，借助B端和C端的库存变更消 息，延迟核对DB和Redis数据一致性。 Ø MySQL深度优化： 通过SQL合并、算子合并、锁冲突优化等措施，深度优化MySQL， 数据实时性要求不高的，增加localcache MySQL为主存储链路 扣减，其他商品使用MySQL扣减；在处理异步消息时，如果商品为非大V售卖商品，则 Redis为主存储链路 容灾降级 热点商品秒杀 写请求 MQ Consumer MySQL库 存数据 读请求 Redis 单热点行更新能力提升至10w/s+。

9. 2、高性能下单分布式事务 交易下单需要扣减库存等资源，然后保存订单到数据库，要么全部成功，要么全部失败，是一个典型的分布式事务问题，面临CAP和高性能的挑战。 快手福利品秒杀的场景下，存在大量请求下单失败， 成单率甚至低于1%，对资源一致性和性能提出了更大的挑战。 传统TCC分布式事务存在的问题 下单 同步调用 正向资源 扣减 库存扣减 限购扣减 权益扣减 营销扣减 权益回退 营销 成单失败 1、XA两阶段提交：存储层将事务提交分为prepare、commit两个阶段，协议简单， 服务超时 业务失败 系统异常 下单失败 逆向资源 回滚 库存回退 同步调用 限购回退 但是性能较差，不适合C端大流量场景 2、本地消息表/事务消息模式：将需要处理的任务通过消息的方式来异步确保执 行，适用于可异步执行、且后续无需回滚操作的业务流程 下单失败的一次请求中，会调用同一个服务正向扣减，逆向回退2个方法， 极端情 3、最大努力通知：发起通知方通过一定的机制最大努力将业务处理结果通知到接 况下游流量会翻倍 ，回退流量无差别挤占下单容量，影响下单稳定性，按照2倍 收方，适用于业务通知类型 扩容又会增加服务器成本

10. 2、高性能下单分布式事务 下单资源扣减必须是强时效性的同步调用，但是资源回退对时效性要求没那么高，因此快手交易下单 采用正向同步扣减+逆向消息异步回 退的TCC分布式事务方案，保障最终一致性。 1、架构解耦 快 手 交 易 下 单 分 布 式 事 务 方 案 下单 资源回退解耦，避免不可预期的回 订单数据 同步调用 退流量影响下单稳定性 资源一致性对账 废单数据 资源扣减流水 2、消息最终一致性 下单失败发送废单消息/疑似废单 正向资源扣减 库存扣减 限购扣减 权益扣减 营销扣减 消息，下游监听消息回退 3、资源唯一键 将订单号作为资源唯一键，供下游 记录资源扣减流水 成单失败 服务超时 业务失败 系统异常 下单失败 废单消息/疑似废单消息 异步调用 4、资源对账 订单、废单、下游资源扣减流水， 多边实时&离线对账，保障一致性 各个下游监听消息 逆向资源回滚 库存回退 限购回退 权益回退 营销核销

11. 3、高性能下游依赖调用 交易依赖几十个下游业务方，上百个下游方法，需要进行合理分级加固，并建立应急预案流程和快速止损修复能力， 保障核心交易服务SLA 9999，最大程度减小故障影响。 多 级 依 赖 管 理 体 系 订单API服务 无损弱依赖 订单确认API 有损弱依赖 不涉资金 有损弱依赖 涉资金 订单管理API 小程序请求 强依赖 异 常 数 据 追 踪 快 速 修 复 H5请求 下单API 商品 查询 库存 扣减 限购 扣减 营销 扣减 地址 查询 行业 实名 加密 解密 运费 模板 权益 保障 分销 信息 超时 信息 商家 信息 用户 昵称 风控 支付 其他API 下单 开关执行降级 订单数据打标 1、依赖管理 下单聚合服务 Native请求 实时核对 异常订单 明细数据 OB/CK 2、依赖加固 配置合理的调用超时时间、限流隔板、熔断策略，做到“拖不 死、打不挂” 其他聚合服务同样的治理方案 Binlog 建立多级依赖管理体系，支持故障自动降级、手动有损降级 可视化 3、故障应急 运维平台 建立异常数据追踪快速修复能力，故障时降级的数据能够快速 检索完成修复 常态化日常预案演练 数据修复平台 灰度执行修复 OB/CK 验证数据修复结果 异常数据 数据修复脚本 批量执行修复 批量执行引擎 4、故障演练 完成 建立故障降级处理SOP，并配合常态化故障演练，让人人都具 备故障处理能力

12. 3、高性能下游依赖调用 交易依赖上百个下游方法，如果都是同步串行调用，会导致RT累积、CPU利用率低，进而影响用户的购买体验；采用全异步编程又会导致代码复杂度 增高， 如何在不影响代码复杂度的前提下优化接口耗时是交易依赖调用较大的挑战。 同步调用耗时原因：RPC调用模式没有与Netty异 步线程模型对齐 ReactivePipeline，一个上层按照串行编码、底层采用异步调用的依赖编排框架 Ø 上下文缓存：与传统的Context 的区别在于，缓存 Ø 依赖自编排：无需全局显示编排，每个依赖调用任务 的是求值过程（DataLoader）而不是值，调用下游 （DataLoader）仅需声明自身依赖即可，获取依赖数 接口的地方就不需要阻塞。 据也无需关注值是否已经准备好。

13. 4、高性能API流量管控 交易API直面用户大流量洪峰冲击，也是黑灰产攻击的重灾区， 需要具备高性能的流量管理防控能力， 既能保护后端服务不被打垮，又能有效防 控抢单、刷单、爬取数据等行为，保障正常商家和用户的权益。 快手交易黑灰产流量拦截体系 快手交易多层限流体系 请求 流量 Nginx限流 客 户 端 请 求 排 队 机 制 API接口限流 服务层多维限流 接口限流 主调限流 实例整体限流 CPU自适应限流 服 务 端 限 流 重 试 机 制

14. 5、高性能可扩展的订单模型和数据接口 订单作为交易最核心的模型，记录各域关键数据，随着 电商业务的不断高速发展，定制业务需求数量快速增长， 交易订单模型要求能够快速支撑各种业务的灵活 定制逻辑，并提供高性能的访问接口。 可扩展的订单模型设计思想：结构化+非结构化 订单公共信息 订单商品信息 订单买家信息 订单卖家信息 订单优惠信息 订单履约信息 订单扩展信息 特殊玩法… 是否预售 制业务逻辑接入，降低研发成本，提 招商类型… 升复用度 售后扩展信息 履约扩展信息 拆单发货 通用扩展能力：设计面向各域的通用 扩展结构和订单标，快速支撑各类定 商品扩展信息 营销扩展信息 是否拼团 Ø 多段物流 退款状态 售后服务 Ø 属性规范管控：通过扩展字段和订单 标业务规范、长度约束、申请流程等， 其他扩展信息 实现有效管控，避免无序扩张

15. 5、高性能可扩展的订单模型和数据接口 订单数据读写接口 接口高性能查询实现方式：模块化按需加载 调用 流量 Ø  简单查询接口（查询接口协议统一，与业务场景无关） 请求入参 Ø 无状态更新接口（更新订单的静态属性，订单属性的变更，不会引起订单状态的变更） Ø  有状态更新接口（更新订单的状态属性，以及状态相关的附加属性，执行此操作会引起订单 状态的流转） 是否查询订单基 础信息 是否查询订单营 销信息 是否查询订单履 约信息 是否查询订单商 家信息 是否查询订单售 后信息 其他参数…… 订单存储模型 加载订单基础信 息 加载订单营销信 息 加载订单履约信 息 加载订单商家信 息 加载订单售后信 息 其他…… 返回调用上游 按需序列化

16. 6、冷热数据归档优化存储成本 电商业务持续高速发展，随着时间积累，数据量成指数级增长，数据量的提升也必将带来一系列问题 Ø 存储成本升高：存储成本和数据量成正比，数据量指数级增长带来了存储成本的指数级增加 Ø 查询性能下降：大量冗余数据堆积，单实例存储空间到达TB级以后查询性能将会急剧下滑 Ø 递延存量 自然增量 数十PB 几百TB/月 交易大部分业务都具有冷热数据 特性，即业务数据随着时间的推 移访问频次会越来越低 Ø 基于这一特性，可以使用「数据 库归档」策略来降低数据的存储 成本，同时提升业务对数据库的 访问效率

17. 6、冷热数据归档优化存储成本 订 单 数 据 归 档 流 程 订 单 数 读 写 询 流 程 Ø 归档规则： 订单完结后+N天后， 几乎不再有业务更新，可以归档 Ø bizId 归档流程： 基于离线表扫描出所有待归档订单， 发送kafka消息，应用接受到消息后，对订单加 锁，读取数据写入归档库，删除活跃库，释放锁 DAO内封装，外层调用无感知 开始 在线 库 订单号 订单读 写接口 订单库 DAO 否 当前订单号是否满足 归档规则 归档 库 是 有可能还未结转完成， 兜底回源一次活跃库 在线库 Mapper 归档库 Mapper 否 订单是否存在 是 通过订单号快速判断是否存 返回数据 结果 在于归档库，DAO内封装 联合读写能力，外层调用无 感知，内部自动完成路由

18. 7、混合云弹性调度优化计算成本 快手电商交易流量具备不定时、不可预期、脉冲式等特点，大V直播福利品秒杀下单的请求流量是日常的近100倍，这给资源部署带来了较大挑战， 集群服务器 部署少了无法应对大V不定时的抢购，部署多了又会消耗大量闲置成本。 全量自建IDC-动态扩缩容 启用弹性混合云资源 快手电商弹性 容器云+阿里 快 手 交 易 服 务 部 署 架 构 云的混合云模 式应对秒杀， 为其他业务未 来借助阿里云 解决资源成本 优势、快速扩 缩容提供了坚 实的基础

19. 总结—稳定性保障、性能提升、成本优化是工程架构永远的追求 更多快手电商技术，欢迎联系讨论，扫码关注快手技术团队，获取演讲PPT和干货内容

20.

21.