核心内容摘要
《原神》的“黄化”现象
订单系统业务分析订单系统是电商平台最重要的子系统之一承载着用户交易的核心数据。
一个合格的订单系统必须保证数据绝对正确即使在复杂的分布式环境下也能保持一致性。
主要挑战包括代码正确性避免因Bug导致数据错误。
事务正确使用在微服务架构下不仅需要本地事务还需分布式事务支持。
异常情况处理如重复请求、并发更新等问题需特殊处理。
订单系统通常分为当前订单程序和历史订单处理程序数据存储也进行分库分表设计。
订单系统的核心功能和数据表核心功能包括填写并核对订单信息创建订单订单确认 订单提交更新订单状态支付、发货、收货等查询订单核心数据表至少4张订单主表oms_order保存订单基本信息。
订单商品表oms_order_item保存订单商品信息。
订单支付表保存支付与退款信息本系统简化至订单主表中。
订单优惠表保存优惠信息本系统未使用。
在本文所述系统中进行了适度简化取消独立优惠表支付状态直接保存在订单主表库存扣减由订单系统发起产品服务执行订单状态枚举0: 待付款1: 待发货2: 已发货3: 已完成4: 已关闭5: 无效订单
订单重复下单问题与解决方案问题描述用户重复点击“提交订单”按钮或因网络重试、RPC框架自动重试等机制导致重复创建订单。
解决方案幂等性设计幂等性定义多次执行与一次执行影响相同。
实现方法利用数据库主键唯一约束。
具体步骤前端预生成订单号调用generateOrderId服务提交订单时携带该订单号订单服务插入数据时使用该订单号作为主键重复插入将因主键冲突而失败时序图见文档Page 8text[前端] - [订单服务]: 获取订单号 [订单服务] - [前端]: 返回订单号 [前端] - [订单服务]: 提交订单携带订单号 [订单服务] - [数据库]: 插入订单主键订单号异常处理捕获DuplicateKeyException或SQLIntegrityConstraintViolationException直接返回“订单创建成功”。
订单ABA问题与解决方案问题描述在并发更新订单时可能出现状态回滚问题。
例如订单单号更新为666更新为888重试更新为666因第一次更新响应丢失导致数据错误。
解决方案版本戳机制在订单主表增加version字段查询订单时返回版本号更新时携带版本号执行条件更新sqlUPDATE orders SET tracking_number666, versionversion1 WHERE version?若版本号不匹配则更新失败需重新查询并重试。
注意事项比较版本号、更新数据、版本号1必须在同一事务中更新失败时应重试本系统未实现可自行扩展
读写分离与分库分表
1 读写分离适用场景读多写少读写比例可达9:1甚至几十:1架构一主多从主库写从库读好处提升并发能力易于实施数据不一致问题主从同步有微小延迟几毫秒可能导致更新后立即查询读到旧数据。
解决方案业务层面规避如支付完成后跳转至“支付成功页”而非直接返回订单页强制读主库将更新与查询放在同一事务中或指定查询主库
2 分库分表适用场景分表解决单表数据量过大导致的查询性能问题分库解决高并发请求压力拆分原则能少拆就少拆避免过度分散一般同时进行分库分表分片键选择订单表常用分片键为订单ID或用户ID挑战按不同条件查询如按用户ID、订单ID、店铺ID需不同分片策略解决方案订单ID中嵌入用户ID后缀支持按订单ID和用户ID分片查询数据同步至其他存储如只读库、HDFS支持复杂查询
商城订单服务的实现
1 数据量预估月订单量2000W年订单量
4亿每条约1KB单表建议不超过2000W行订单商品表平均每订单10商品年记录24亿
2 分表设计订单表32张订单商品表32张虽单表数据量达8000W但综合考虑关联查询性能选择32张表
3 分片键与算法订单表分片键id订单ID、member_id用户ID订单商品表分片键order_id分片算法哈希取模对32取模订单ID生成唯一ID 用户ID后两位拼接
4 技术实现Sharding-JDBC采用Sharding-JDBC组件配置读写分离与分库分表。
关键配置见文档Page
yamlspring: shardingsphere: datasource: names: ds-master rules: sharding: tables: oms_order: actual-data-nodes: ds-master.oms_order_$-{
.31} table-strategy: complex: sharding-columns: id,member_id sharding-algorithm-name: oms_order_table_alg oms_order_item: actual-data-nodes: ds-master.oms_order_item_$-{
.31} table-strategy: complex: sharding-columns: order_id sharding-algorithm-name: oms_order_item_table_alg分片算法类OmsOrderShardingAlgorithm根据订单ID或用户ID后两位取模定位表OmsOrderItemShardingAlgorithm根据订单ID后两位取模定位表
七、
总结订单系统设计核心要点幂等性是保证数据正确的关键通过预生成订单号和版本戳机制实现。
读写分离可有效提升读并发但需注意主从延迟问题。
分库分表是应对大数据量和高并发的终极手段需谨慎选择分片键。
Sharding-JDBC是较好的分库分表实现方案侵入性低性能稳定。
在实际项目中应根据业务规模和发展阶段选择合适的架构方案避免过度设计。
订单系统作为电商核心其稳定性和数据一致性永远是第一位的。