B站会员购交易系统架构演进

来源：https://mp.weixin.qq.com/s/H6XBE0utoJGz3XwTINX5VA

B站会员购交易系统架构演进主要围绕性能优化和数据库扩展两大核心挑战展开，通过系统性改造支撑了业务快速增长和高并发场景。以下是详细总结：

---

一、背景与挑战

• 业务复杂性提升：会员购从初期预售/现货模式扩展到全款预售、盲盒、众筹等多类售卖方式，并覆盖猫耳、QQ小程序、漫画等多渠道。

• 流量压力：拜年纪、公司周年庆（626）、会员购周年庆（919）等大促活动带来数百倍瞬时流量爆发，系统面临高并发、低延迟的稳定性挑战。

---

二、性能优化

1. 调用链路优化

• 问题：初版下单接口串行调用依赖服务（商品、店铺、活动等），耗时高达400ms，QPS瓶颈明显。

• 优化措施：

  • 责任链模式重构：将下单流程拆解为可并行执行的独立模块。

  • 并发调用：对无逻辑依赖的服务（如商品、用户信息）并行请求。

  • 冗余调用削减：推动下游服务接口合并，确保每个基础数据仅请求一次。

  • 超时与重试优化：设置200ms超时，部分接口99分位耗时允许上浮100%。

  • 弱依赖异步化：如关注店铺、缓存手机号等操作通过MQ或异步处理。

• 效果：下单耗时从300ms降至100ms，用户体验和系统吞吐量显著提升。

2. 异步下单优化（应对秒杀场景）

• 问题：大库存秒杀（如5000件拜年祭手办）时，同步下单导致数据库行锁竞争激烈，QPS瓶颈在600+。

• 解决方案：

  • 消息队列削峰：用户请求通过Databus消息队列缓冲，后端消费者批量处理（最多20单/批次）。

  • 异步链路设计：

    • 前端提交请求后提示“下单中”，轮询查询结果（30秒超时兜底）。

    • 批量操作库存冻结、优惠券扣减、订单入库，减少数据库压力。

  • 降级与容错：

    • Databus异常时降级为同步下单。

    • 批量操作失败后拆解为单订单重试。

    • 下单结果优先查询Redis，异常时降级至数据库。

• 效果：系统支持4000+ TPS，成功支撑拜年祭等大促活动。

3. 分库分表

• 动机：订单数据每半年翻倍，单表千万级导致查询慢、主从延迟、DDL风险高。

• 技术选型：采用Sharding-JDBC（Client模式），轻量级且运维成本低。

• 分片策略：

  • 分片键：以用户ID（mid）和订单ID（order_id）为核心，order_id嵌入mid基因（mid%512）。

  • 路由规则：4集群×4库×16表=256表，库路由=mid%16，表路由=(mid%512)/32。

• 数据迁移：

  • 历史数据保留老库，新数据按分片规则写入。

  • 通过双写+Binlog同步确保数据一致性。

• 效果：解决数据库存储与并发瓶颈，提升系统可扩展性和稳定性。

---

三、总结与展望

• 成果：通过链路优化、异步化改造、分库分表，系统成功支撑历年大促高并发场景。

• 未来方向：继续对票务系统等历史模块进行架构升级，进一步提升用户体验。

---

关键优化效果对比

优化阶段	核心问题	优化手段	效果
调用链路优化	串行调用耗时400ms	责任链模式+并发调用+异步化	耗时降至100ms
异步下单	秒杀场景QPS瓶颈600+	MQ削峰+批量处理+降级容错	TPS提升至4000+
分库分表	单表千万级数据瓶颈	Sharding-JDBC+基因分片+双写迁移	数据库水平扩展，支撑亿级数据

此架构演进体现了从局部优化到系统性重构的升级路径，通过技术手段平衡性能、可用性与业务复杂度，为类似高并发电商系统提供了重要参考。

数据迁移是怎么做的?

 

在B站会员购交易系统的分库分表改造中，数据迁移采用了一种不停机、平滑过渡的策略，以确保业务连续性和数据一致性。具体步骤如下：

数据迁移步骤

1. 历史数据归档​

   • 老数据（分库分表前的订单数据）保留在原数据库中，不做迁移。所有对老数据的读写操作仍路由到老库。

   • 新数据（分库分表后生成的订单）根据分片规则（如mid分片）直接写入新库。这减少了迁移工作量，并避免了初期数据清洗的风险。

2. 切读写流量​

   • 通过双写机制，逐步将读写请求从老系统切换到新系统：

     • 先开启双写：应用层同时向老库和新库写入数据，但读请求仍主要走老库。

     • 验证新库数据准确性后，逐步将读请求切换到新库（如按用户ID分段切换）。

     • 最终完全切流，新库成为主库，老库仅用于历史查询或备份。

3. 数据回写与校验​

   • 使用Binlog监听工具（如Can