Elasticsearch

Day 14 - 订单中心基于elasticsearch 的解决方案

blogsit 发表了文章 • 3 个评论 • 17672 次浏览 • 2018-12-14 15:24 • 来自相关话题

ElasticSearch分布式搜索储存集群的引入，主要是为了解决订单数据的存储与搜索的问题。

项目背景：
15年去哪儿网酒店日均订单量达到30w+，随着多平台订单的聚合日均订单能达到100w左右。原来采用的热表分库方式，即将最近6个月的订单的放置在一张表中，将历史订单放在在history表中。history表存储全量的数据，当用户查询的下单时间跨度超过6个月即查询历史订单表，此分表方式热表的数据量为4000w左右，当时能解决的问题。但是显然不能满足携程艺龙订单接入的需求。如果继续按照热表方式，数据量将超过1亿条。全量数据表保存2年的可能就超过4亿的数据量。所以寻找有效途径解决此问题迫在眉睫。由于对这预计4亿的数据量还需按照预定日期、入住日期、离店日期、订单号、联系人姓名、电话、酒店名称、订单状态……等多个条件查询。所以简单按照某一个维度进行分表操作没有意义。ElasticSearch分布式搜索储存集群的引入，就是为了解决订单数据的存储与搜索的问题。

具体解决方案：

1、系统性能
对订单模型进行抽象和分类，将常用搜索字段和基础属性字段剥离DB做分库分表。存储订单详情,ElasticSearch存储搜素字段。订单复杂查询直接走ElasticSearch。如下图：

通用数据存储模型

关键字段
■ 业务核心字段，用于查询过滤
系统字段
■ version 避免高并发操作导致数据覆盖
大字段
■ order_data订单详情数据(JSON)
■ 可灵活需要索引的字段返回的字段

2、系统可用性
系统可用性保障：双机房高可用如下图。

数据可用性保障：
一、异步多写保证数据一致性。

二、数据补充机制：
1、每天凌晨task扫描数据库热表数据与es数据版本进行比较。
2、将第三方推送过来数据中的，订单号即时插入订单同步队列表中。如果数据模型解析转换、持久化成功。删除队列中订单号。同时设置1分钟一次的task 扫描队列表。
3、推送第三方的数据也采用同样的方式。保证给第三方数据的准确性。