卡盟微信平台官网,快手点赞赚钱群

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

第一世:凡人渡劫小仙之路-分库分表

随着业务发展,单库单表所能承载的数据量局限性越发严重。

历劫:单库单表数据量承载局限

飞升:分库分表

分库分表的维度针对系统买卖家查询的需求,分片键为卖家id和店面id,其余订单扩充信息表属于数据组装信息,均以店面id为分片键。

结果:分库分表后,数据业务量的承载质的提高。

第二世:小仙渡劫上仙之路-引入ES搜索引

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

历劫:跨表查询越来越多,系统慢查频频报出

飞升:引入ES搜索引擎

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

图片[1]-卡盟微信平台官网,快手点赞赚钱群-老王博客

结果:目前运行良好,统计的检索需求响应时间均值20ms以内,对于命中缓存的在1ms以内返回。因为多表联查的流量都进了ES,所以系统慢查被清0。

两个问题须要注意下:

1.单Type与多Type的选择(ES6.X以上版本一个索引只容许有一个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.幂等性保障:假如不能保证业务消费的幂等性,这么消息的正序,数据的重放监控补偿等等都会很被动。这儿简单提供几种幂等思路:

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论