有赞订单管理的三生三世与“十面埋伏”
有赞订单管理主要承接有赞所有订单搜索及详情展示功能，系统随着业务的不断发展经历了多次飞升之路。下面简单介绍下有赞订单管理系统的三生三世与“十面埋伏”。
第一世：凡人飞升小仙之路 - 分库分表
随着业务发展，单库单表所能承载的数据量局限性越发严重。
历劫：单库单表数据量承载局限
渡劫：分库分表
分库分表的维度针对系统买卖家查询的需求，分片键为买家 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 变更自增号
- 消息有序：对于一些强依赖消息有序或者业务乐观锁不好设定时候，消息端的有序变得尤为重要，可以给根据业务唯一键（如订单号）进行机器取模，保证同一笔订单的变更数据会被推送到同一台机器上消费。
其中业务乐观锁使用简单高效，无需额外存储乐观锁字段，而消息强有序每次需要使用取模计算，性能多少会有些影响，不过经过压测数据显示性能差别不大，这边采用业务乐观锁 + 消息有序共用的方案。目前线上运行良好。
无论是十里桃林凉凉月色恬静中的怡然，还是浅浅岁月十面埋伏中惊悚后的酣畅，都是一种体验，经历了就是经验，愿我们一起把握每一个重要而幸运的经历。