《从双十一看天猫订单数据对接及订单流程优化》由会员分享，可在线阅读，更多相关《从双十一看天猫订单数据对接及订单流程优化（30页珍藏版）》请在金锄头文库上搜索。
1、ArchSummit 全球架构师峰会（北京）2014 从双十一看天猫订单数据对接 及订单流程优化 Outline 第一部分：小米电商与天猫对接方案分享 第二部分：小米电商订单流程优化分享 第三部分：小结订单的处理 双十一天猫数据对接的那些事儿 接到天猫入住需求-开发第一版 确认一个最小化数据模型 能够受理用户购买和退款即可 和已有系统做好业务隔离 其实就是要解耦 逐步增加复杂业务支持 时间人手都不够 核心是没有做过 第一版的缺点 丢消息 设计上的硬伤，不管消息是哪个环节丢的都不好搞，只能天天对数据。 慢 有活动更慢 怎么改？ 目标是什么 实时消化销售峰值（全天的销售计划的80%前一个小时完成来
2、估算） 可选方案？ 聚石塔服务 需要配套天猫聚石塔中很多服务（成本提高，架构要変更） 天猫直通港 正在犹豫聚石塔的时候，天猫JDP抛出的橄榄枝。 评估 第二版的缺点？ 不维护了！ 怎么办？ 需要一个终极方案 关键环节需要把握在自己手里 系统：快、稳定、吞吐能力强、横向可扩展 运维：方便，容灾 目标：按前一年的三倍数据量设计。 技术选型 购买的服务 RDS 数据库 ECS 云主机 SLB 负载均衡 通过聚石塔调用淘宝API 升级对接系统 订单流程优化 先说系统拆分 系统优化，没有最好的只有更适合自己的 项目 资源 高效 优化的基本点及优先级 首先然后做结构解耦 对业务发展的理解 调整代码结构便于
3、分层分组 相互制约的代码需要尽量分到不同的组 其次优化架构及中间件 做细 长连接 Cache Queue 最后是优化代码 - 基本功 逻辑 Cache的使用 慢查询 优化效果的检验 压力测试 线上检验 权衡资源综合各项指标调优 瓶颈系统（db ） 开发资源 运维资源 保留性能（比如说20%） Cache & Queue 这两个虽说很重要但是结合业务模型及依赖程度，我们没有做性能参考 我们需要总结测试结果 订单生成/订单校验/订单推送等后端业务流转操作都是针对同一数据库的同一个表做操 作，在实际的应用场景中会存在数据库资源争抢的情况，所以针对多场景的联合测试 很有必要。 在测试过程中发现，系统主
4、要的瓶颈在数据库方面(24core的cpu最高可达约70%的资 源占用率)，同时从库的延迟会达到2分钟以上。 在单场景的测试过程中可以看出订单推送的消费能力低于订单的生产能力，队列会存 在少量的阻塞， 有了这个结果我们就可以放心的做生产线实际演练了。 项目上线需要考虑什么？ 降低配置（当然包括所有相关系统都需要做好各自的准备） 运维 备用资源 容灾及灾备 Dba 业务模型限制，灾备第一。 健康监控 慢查询0容忍 Cache & Queue 做好前期沟通调配好资源 小结订单处理 内部流程环节要不断作优化，提升性能 第三方接入，需要找出适合自己特点的最优方案 杨大伟 软件工程师| 小米科技 MP: + Email: yangdawei yangdawei
