【交易架构day4】京东到家交易系统的演进之路

背景

交易系统可能不是技术难度最深的，但是业务复杂度最高的，一个订单从提交到最后真正生产成功要经历几十个系统，涉及的接口交互，MQ等可能达上百个。任何一个环节出问题都会导致这一单的异常，而且交易不像单纯的资讯门户可以靠静态化或者缓存抗住大并发，交易系统里面涉及到大量的资源(库存，优惠券，优惠码等)消费，订单生成等需要写入持久化的操作不是单纯的异步或者缓存化可以解决的，而且对库存等敏感信息不能出现并发扣减等。

细节的设计非常多，下面挑出比较典型的一些方面，给大家介绍下京东到家交易系统的架构设计和关键问题的处理方案。

历程

系统Set化

初期的订单系统和首页，单品页，购物车业务逻辑层等都是在一个大项目里。非常适合初期人员少，业务复杂度低，快速迭代，不断探索试错的过程，但是随着业务的发展，出现了以下问题：

• 系统的流量和业务复杂度也越来越大，大家共用一个大项目进行开发部署，相互影响，协调成本变高；

• 不同的业务模块，流量和重要级别不同需要的部署策略和容灾降级限流等措施也不一样，要分而治之； 

  

解决方案
项目Set化，这个过程中要注意Set化的边界问题，粒度太大了效果不好，太小了设计过度了，反而会增加维护和开发成本； 

分库分表

问题
随着订单的并发量的不断攀升，特别是在双十一，618等大促的时候，单组DB(一主多从)存在着明显的压力，单个主库的连接数是有限的。大单量，大并发的时候，数据库越来越成为了我们的瓶颈。

解决方案
针对接单数据库我们采取的常规做法分库，根据订单号进行Hash分布到不同的多个数据库中，代码方面我们是继承了Spring的AbstractRoutingDataSource，实现了determineCurrentLookupKey方法。对业务代码只有很少的耦合。

另外下发到个人中心数据库的订单信息，每天不断的累计到DB中，存在以下风险：

• MySQL的单表容