【交易架构day6】有赞订单交易系统的演进之路——如何存储海量订单数据

按：交易系统一般以订单为核心，状态机做流程驱动。最近十年我们对订单的看法是正向流程承载的单据，今天有一个新观点——交易契约。交易的业务状态及流转、高可用、零资损等，是其主要的挑战。订单的海量存储是一个普遍的挑战，因为每天都会产生、生命周期从一天至一年不等，冷热数据差异明显。本文来自有赞交易中心、王爷的分享。

有赞订单管理主要承接有赞所有订单搜索及详情展示功能，系统随着业务的不断发展经历了多次飞升之路。下面简单介绍下有赞订单管理系统的三生三世与“十面埋伏”。

第一世：凡人飞升小仙之路-分库分表

随着业务发展，单库单表所能承载的数据量局限性越发严重。
历劫：单库单表数据量承载局限
渡劫：分库分表
分库分表的维度针对系统买卖家查询的需求，分片键为买家 id 和店铺 id，其余订单扩展信息表属于数据组装信息，均以店铺 id 为分片键。
结果：分库分表后，数据业务量的承载质的提升。

第二世：小仙飞升上仙之路-引入ES搜索引擎

随着业务搜索维度的不断添加，使得跨表查询需求越来越多，系统的慢查不断报出，为此引入了 ES 搜索引擎。
历劫：跨表查询越来越多，系统慢查频频报出

渡劫：引入 ES 搜索引擎
ElasticSearch 是一个基于 Lucene 的搜索服务器,这里主要是通过将订单主表及辅表的索引字段同步到ES里，这些每张表单独的索引字段，汇总成一个联合索引，来实现多个表的跨表搜索。
结果：目前运行良好，统计的检索需求响应时间均值 20ms 以内，对于命中缓存的在 1ms 以内返回。由于多表联查的流量都进了 ES,所以系统慢查被清0。