有赞订单管理的三生三世与“十面埋伏”

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

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

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

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

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

历劫：跨表查询越来越多，系统慢查频频报出

渡劫：引入ES搜索引擎

ElasticSearch是一个基于Lucene的搜索服务器,这里主要是通过将订单主表及辅表的索引字段同步到ES里，这些每张表单独的索引字段，汇总成一个联合索引，来实现多个表的跨表搜索。

结果：目前运行良好，统计的检索需求响应时间均值20ms以内，对于命中缓存的在1ms以内返回。由于多表联查的流量都进了ES,所以系统慢查被清0。两个问题需要注意下：

1. 单Type与多Type的选择

ES里使用文档存储，一个Index可以理解为一个库，一个Type可以理解为一张表，那么订单及其扩展信息面临使用单Type还是多Type的抉择。

多Type优点： 可以做到索引字段与表结构一一对应, 数据同步隔离单一，直观简单。

多Type缺点：获取数据时候需要一次数据聚合，比如一次跨5张表索引联查，需要先分别取出5张表的数据，然后做一次交集。性能会有影响。类似于DB的跨表联查，而且当数据做冷热隔离，数据拆分时候，多Type的拆分和维护成本反而更高。

单Type优点：可以做到数据一次请求即可将目标信息全量返回，一个Type的数据拆分冷热隔离维护成本可控。

单Type缺点：数据同步成本高一些，要做好数据聚合一致性问题。 结合业务需求场景，这里采用的单Type方案。如下图所示。

2.索引字段数量控制

由于订单及其扩展信息字段较多，将这些信息全量同步到ES会导致索引字段过多，索引文件也会随之过大，检索效率会受到影响。所以这里采用了将订单及其扩展信息中强搜索需求的索引字段同步了进来，并没有做全量所有字段同步。

第三世：上仙飞升上神之路-引入Hbase

随着业务的不断发展，对系统性能的要求的不断提高，我们发现虽然数据检索的效率很高，但是数据组装的效率令人担忧，由于需要从ES中获取的订单号列表到各个扩展表去获取具体信息，也就是一次完整的订单列表拉取时间=数据检索时间+数据组装时间，而数据组装就算是批量获取，也要去取N（假如有N张订单扩展表）次，即使并行去取也不够高效，上文讨论过没有将订单的所有信息全部同步到ES的原因，这样一次完整的订单拉取时间=数据检索时间。

历劫：数据组装效率低下

渡劫：引入Hbase来为详情数据组装 Hbase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统。可以通过MapReduce来处理HBase中的海量数据。

这里将订单基本信息及其强依赖的扩展信息全量导入Hbase，其中历史数据采用BulkLoad导入，增量数据采用消息同步写入，以订单号为rowKey为订单号，这样通过一次请求，将该订单的基本信息及扩展信息一次性取出。

结果：订单管理架构被抽象成了DB+ES+HBASE的三层架构(如下图所示)，DB作为数据写入源头，ES负责搜索请求的parser解析及基本数据返回（即Es返回字段即可满足需求的场景），而Hbase作为订单详情详细信息的组装载体，两者配合提升整个订单列表搜索和详情组装的性能。同时Hbase的数据源也可以被复用到订单导出，数据统计等离线需求上。

写到这里可能很多朋友都看出，实现这一切还有一个非常重要的劫需要去渡。那就是数据同步的实时性和一致性。感兴趣的话后续文章可以重点写写数据同步以及踩过的坑和破局之道，这里简单抛砖引玉下。

历劫：数据同步的实时性与一致性
渡劫：链路白盒+幂等性保障

1. 链路白盒：整个同步链路是先监听binlog然后同步到消息队列中，业务消费处理同步到Es和Hbase，可以将整个同步链路监控起来，比如一个消息binlogTime->addMqTime->processTime->addEsOrHbaseTime,这个差值其实就是实时性的一个指标。一旦整个同步链路的白盒搭建好，那么对应的报警监控，失败重试补偿就都可以跟进配套完成。保证数据的完整性与实时性。同步链路及同步监控如下图所示。
   
   
   2.幂等性保障：如果不能保证业务消费的幂等性，那么消息的乱序，数据的重放监控补偿等等就会很被动。这里简单提供几种幂等思路：

• 业务乐观锁字段：比如订单状态的流转，应该是一个正向更新，即后一次更新的state一定大于等于前一次。
• version字段：表设计时候留一个version字段，每次数据库更新都会将该字段加1，作为乐观锁依据。
• sonwflake算法：可以根据业务需要定制自己的snowflake算法，比如毫秒级时间戳+binlog变更自增号
• 消息有序：对于一些强依赖消息有序或者业务乐观锁不好设定时候，消息端的有序变得尤为重要，可以给根据业务唯一键（如订单号）进行机器取模，保证同一笔订单的变更数据会被推送到同一台机器上消费。 其中业务乐观锁使用简单高效，无需额外存储乐观锁字段，而消息强有序每次需要使用取模计算，性能多少会有些影响，不过经过压测数据显示性能差别不大，这边采用业务乐观锁+消息有序共用的方案。目前线上运行良好。
  简单回顾了下有赞订单管理的“飞升之路”，至于是不是上神，还有待进一步考验，后面会重点发力在配置化编程，系统白盒监控最大化及系统性能的不断提升上，欢迎有志之士加入来一起飞升

无论是十里桃林凉凉月色恬静中的怡然，还是浅浅岁月十面埋伏中惊悚后的酣畅，都是一种体验，经历了就是经验，愿我们一起把握每一个重要而幸运的经历。