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

Elasticsearch | 作者 blogsit | 发布于2018年12月14日 | | 阅读数:1588

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

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

具体解决方案:

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

elasticsearch1.png

       通用数据存储模型

elasticsearch2.png


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

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

       
elasticsearch3.png

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

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


elasticsearch4.png


3、系统伸缩性
      elasticSearch中索引设置了8个分片,目前Es单个索引的文档达到到1.4亿,合计达到2亿条数据占磁盘大小64G,集群机器磁盘容量240G。

 
 
 

[尊重社区原创,转载请保留或注明出处]
本文地址:http://elasticsearch.cn/article/6197


2 个评论

硬件方面只写了磁盘,能不能把内存和CPU都写一下。硬盘是SSD还是普通的硬盘?
ES不支持事务,请问下是如何保证订单表数据完整的导入到es中的?

要回复文章请先登录注册