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

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

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

随着业务发展，单库单表所能承载的数据量局限性越发严重。
历劫：单库单表数据量承载局限
渡劫：分库分表
分库分表的维度针对系统买卖家查询的需求，分片键为买家 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 变更自增号
消息有序：对于一些强依赖消息有序或者业务乐观锁不好设定时候，消息端的有序变得尤为重要，可以给根据业务唯一键（如订单号）进行机器取模，保证同一笔订单的变更数据会被推送到同一台机器上消费。其中业务乐观锁使用简单高效，无需额外存储乐观锁字段，而消息强有序每次需要使用取模计算，性能多少会有些影响，不过经过压测数据显示性能差别不大，这边采用业务乐观锁+消息有序共用的方案。目前线上运行良好。

简单回顾了下有赞订单管理的“飞升之路”，至于是不是上神，还有待进一步考验，后面会重点发力在配置化编程，系统白盒监控最大化及系统性能的不断提升上，欢迎有志之士加入来一起飞升 wangye@youzan.com。

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

=>更多文章请参考：《中国互联网业务研发体系架构指南》https://blog.csdn.net/Ture010Love/article/details/104381157

=>更多TOP权威案例及行业标准资料请关注微信公众号：

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

【交易架构day4】京东到家交易系统的演进之路
背景交易系统可能不是技术难度最深的,但是业务复杂度最高的,一个订单从提交到最后真正生产成功要经历几十个系统,涉及的接口交互,MQ等可能达上百个.任何一个环节出问题都会导致这一单的异常,而且交易不像单 ...
【交易架构day8】洋码头交易系统的演进之路——先生存后发展
按:我们谈系统演化,本质上是一个动态进化的过程,谁先做.谁后做,第一枪打在哪.这是关键.先保生存.再发展是比较好的策略.本文来自洋码头架构师张志强.涂文杰两位的分享. 1. 交易1.0 和许多业务优先 ...
京东到家交易系统的演进之路
背景交易系统可能不是技术难度最深的,但是业务复杂度最高的,一个订单从提交到最后真正生产成功要经历几十个系统,涉及的接口交互,MQ等可能达上百个.任何一个环节出问题都会导致这一单的异常,而且交易不像单 ...
【商品架构day3】京东商品系统的演进之路 - 如何抗住亿级流量
本文来自京东尤凤凯老师的分享.商品,黄金交易流程最基础.最核心的环节,无商品不电商.商品数据无处不在,商家(采销.供应商)发布管理.供应商下采购单.仓储配送.促销.搜索.商详页展现.购物支付.财务结算 ...
架构周报：微信后台系统的演进之路
经典案例 \\ <阿里无线11.11 : Weex--关于移动端动态性的思考.实现和未来>--今天在移动端,尤其是像手机淘宝这样的 app 中,动态性问题逐渐成为一个比较棘手的问题.所谓动 ...
从编解码算法到全链路RTC架构，揭秘淘系直播技术演进之路
从2016年直播元年至今,纯粹的直播已经逐渐失去竞争力,越来越多形式创新映入眼帘,而众多企业开始走向内容垂直化--秀场.游戏.电商.广电等内容特点深度结合.伴随2020年疫情爆发,电商为人们日常生活提 ...
【商品架构day7】京东商品系统的演进之路：从0到10亿流量的挑战
本文来自京东赖晨东老师的分享.主要从POP商品简介.POP商品系统的架构演进.以及一些实战的架构珠玑3个方面来介绍京东POP商品系统. POP商品系统的特征是业务复杂,也是新业务的发源地,更是核心的基 ...
clickhouse hbase性能对比_QQ音乐PB级ClickHouse实时数据平台架构演进之路
OLAP(On-Line Analytical Processing),是数据仓库系统的主要应用形式,帮助分析人员多角度分析数据,挖掘数据价值.本文基于QQ音乐海量大数据实时分析场景,通过QQ音乐与腾 ...
抖音、美团等大厂千万级用户的Android客户端架构演进之路—
在移动开发中,对开发者来说不同的人具有不同的能力.就像读一本书一样,一千个读者,有一千个哈姆雷特.但不管怎样,只要你是个软件开发者你就必须学习windows或Linux等操作系统的运行原理.Andro ...
QQ音乐PB级ClickHouse实时数据平台架构演进之路
导语 | OLAP(On-Line Analytical Processing),是数据仓库系统的主要应用形式,帮助分析人员多角度分析数据,挖掘数据价值.本文基于QQ音乐海量大数据实时分析场景,通过Q ...

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

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

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

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

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

最新文章

热门文章