注意：以下文档只适用于TOP接口，请谨慎使用！
注意：以下文档只适用于TOP接口，请谨慎使用！
在电商场景下，交易订单作为电商系统的"纽带"贯穿了整个系统的关键流程，承载着所有购买信息与支付信息。在618、双11等各种大促的高流量下，不论是独立品牌商家，还是聚石塔内的各大电商服务商，极高并发的订单查询请求，给整个订单系统的对接效率、处理能力、灾备能力，系统互通效率，都带来了极大的考验。
与此同时，大规模业务数据带来的是，更为复杂的日志分析与系统运维工作。如何收集分散在各层的日志、指标数据，进行集中的收集存储、并完成后续的分析监控，快速搭建整套日志平台，以保障整体业务的平稳运行，也是电商行业发展过程中所持续面临的问题。
1）海量数据带来性能和稳定性瓶颈：电商行业遇到诸如大促的业务高峰期，会产生高达百万、千万级的订单数据量，面对这样的高流量、高并发查询，关系型数据库有天然的处理瓶颈，对整体系统稳定性的巨大挑战。
2）复杂字段与查询条件导致查询效率低：电商订单往往包含复杂的商品信息、优惠、用户、地址等多维度字段信息。在商家进行订单查询过程中，往往存在大量的模糊查询场景，如不完整的卖家地址或昵称等。DB在复杂条件下查询能力弱，对模糊匹配的处理效率低，仅仅依靠关系型数据库，无法满足订单系统的检索需求。
3）面对流量波动缺乏灵活伸缩能力：为顺利承载活动带来的流量，电商行业具有明显的业务波动，一方面，高峰流量所需要的临时扩容，带来了极大的人力运维成本；另一方面，业务低峰期的闲置机器也是极大的资源成本浪费。
1）基础设施与架构复杂带来大量数据：随着各大服务商服务升级、技术升级，整体架构越来越复杂，包含多种服务器、存储、网络设备、安全设备，产生大量日志数据。
2）服务的分布化导致数据的集中和追溯困难：各层业务服务之间的调用错综复杂，由此带来全链路的监控诉求，而服务的分布化，增加了链路上各个环节的故障分析排查难度。
3）开发运维结合对有更高的技术要求：随着大数据应用发展，开发与运维环节紧密结合，共享同样的信息来源，更需要对日志、指标、APM进行立体、统一观察分析， 通过“全观测”打破数据与工具之间的壁垒。
聚石塔Elasticsearch服务100%兼容开源Elasticsearch，是构建于Apache Lucene搜索引擎库之上的分布式全文搜索和分析引擎，提供搜集、分析、存储数据三方面能力，提供包含全托管Beats、Logstash、Kibana的整套Elastic Stack产品生态组件。
在检索能力上，Elasticsearch作为业内最主流的全文检索引擎，在DB-Engine指数排行上是全球热度No.7的数据库、No.1的检索引擎。可在PB级数据中找到匹配信息，并具备ms级数据时效性，能够快速处理文本、数字、日期、IP 以及地理数据等各类数据类型。可作为关系型数据库二级索引，弥补传统关系型数据库在大数据量、高并发查询的局限性，混合应用实现能力互补；
在运维监控全观测方面，Elastic Stack具备对多种数据类型和数据来源的采集能力、同时可灵活的进行数据结构化处理，并通过最终的可视化分析与监控。充分利用分散在系统各层的日志、指标、APM数据，搭建一套完善的智能诊断与分析、智能监控报警的全观测平台，更好的发挥数据价值。
聚石塔Elasticsearch服务对比开源自建更有全方位的能力升级优化，诸如：
1）免费提供每个节点价值6000美元的X-Pack商业插件；
2）集成阿里达摩院分词插件、向量检索插件，提供文本、视频、音频、图像，提供最全面的信息检索能力；
3）全面对齐等保2.0要求，企业级数据安全能力；
4）阿里日志增强版内核，100%成本降低，100%性能提升。
某淘宝商家服务商立足于电子商务行业，是基于淘宝服务平台的最早一批应用软件与信息技术服务提供商之一。专注为淘宝电商商家提供包含订单处理、商品管理、分销供应、数据分析、营销打折等功能的软件产品，服务于400万淘宝商家。在该商家服务商原本的技术架构中，使用MySQL数据库和PostgreSql数据库搭建订单及相关检索系统；随着业务规模扩大，逐渐面临性能瓶颈，迫切寻求技术上的升级，最终在短短3个月内对接使用聚石塔Elasticsearch产品，对整体订单系统和日志运维平台升级改造完成。
该淘宝商家服务商，在订单检索系统中面临一下几个主要问题：
1）峰值并发查询压力大，延迟高体验不好，严重影响稳定性，无法达到为用户承诺的查询时效性
2）订单字段复杂，商家用户的查询维度多，和模糊搜索意图强，传统数据库方案无法实现满意的查询效果和性能
3）双十一、618等购物节业务压力暴涨，难以快速扩容
4）数据可用性、安全、权限粒度要求高，数据敏感影响巨大。
聚石塔Elasticsearch对应提供了在订单检索及日志分析场景下，产品能力及解决方案如下：
① PB级数据准实时搜索引擎，查询结果毫秒级返回；索引限流插件，保障系统高稳定性；
② 支持多种数据结构的复杂查询，及字段的全文匹配和模糊匹配，并集成了如阿里达摩院NLP分词器等多种分词插件，性能效果双保障；
③ 集群一键平滑扩缩容，变更对业务0影响，灵活应对流量峰谷；
④ 数据自动备份、多种安全认证、字段级别权限管控。
关于整体的订单检索方案详细说明：
在整个系统链路中，业务应用服务系统将全部商家的全量订单数据存入MySql数据库，对订单数据用商家ID取模的形式进行分库分表，作为持久化存储；同时将需要检索的字段和基础属性字段存入Elasticsearch，提供可以应付维度膨胀的订单数据，在复杂查询、模糊匹配场景下借助Elasticsearch的检索能力，必要时反查MySql获取订单完整信息。
通用方案是MySQL向ES进行全增量数据同步，当业务系统产生业务表信息变更时，由增量数据更新的方式补充/变更ES中的数据。增量更新主要是以mysql binlog订阅的方式，利用DTS、Canal、Logstash或DataWorks等多种工具实现。考虑到通过MySQL到ES增量同步会有一定的延迟，当RDS主库产生较大负载，会无法保证ES的数据写入；而Canal在实际的测试过程中有数据延迟和数据丢失，需要每天晚上再手动做一次同步。
为保证数据的时效性，另一种方案，是直接通过业务系统实现对MySQL和ES双写，自行保证两条链路的质量。并在业务端通过补偿脚本，保证两条链路的数据均写入成功才算写入成功，否则会回滚重试，以保证一致性。
在订单检索场景下，将需要检索的字段和基础属性字段存入Elasticsearch。在这个流程中，对于海量数据而言，通常通过hash映射将海量数据分割成相应的小块数据，然后再针对各个小块数据通过hash_map进行统计或其它操作。
如果将所有数据均分在几十个节点中，虽然能保证写入无法满足实时高效的查询要求。因此，在整个订单数据索引中可以采用双分片处理，首先对商家ID进行哈希处理，将商家ID聚集在某个小片的集合里，再通过相应的routing设置。同时，再对订单进行哈希，从而保证整体查询的高效性。
通过阿里云Elasticsearch方案，该服务商实现了订单查询服务的整体架构的升级改造，不仅借助Elasticsearch作为数据库二级索引，达到了毫秒级数据时效性的准实时查询，带来了近一倍的IOPS大幅提升；也降低了MySql主数据库的查询压力，避免了高并发查询下造成的写入数据丢失风险。
与初始的MySQL+PostgreSQL架构方案相比，在资源方面降低了50%的成本。最终基于Elasticsearch的检索能力、数据权限体系进行封装，为各个商家提供在客户端、移动端的订单管理。
如有疑问欢迎加钉钉群（群号：32917331）咨询。
