一、背景

公司业务订单数据增量大概在 4 亿每月，订单在数据库中存量保存 3 个月数据，一共 12 亿文档 1 TB 数据。平时读 QPS 在 2500 左右，写 QPS 在 1000 左右，订单写入为单条写入方式，查询为根据订单 ID 查询。迁移 ES 之前，数据存放在 MongoDB 中，以主备方式部署，机器配置 16 核 128 g，2 * 1.6 t 本地 SSD。在写入 QPS 在 3、400 时，MongoDB 的负载还算正常，一旦写入 QPS 增高时，MongoDB 负载飙升，一直处于较高状态，比较危险。为了解决该问题，我们打算替换存储系统，经过多方考虑，我们选择了 Elasticsearch。

二、Elasticsearch 压测

为了验证 Elasticsearch 在订单场景下的性能表现，我们对 Elasticsearch 进行了压测。测试数据为线上订单数据，导入 6 亿条数据（250g）。机器配置 16 核 128 g，2 * 16 t 本地 SSD，机器规模 3 节点 ，分配 31 g 堆内存，其余内存留给操作系统。Elasticsearch 版本为 7.5.2，Index 设置如下：

settings" : {
      "index" : {
        "codec" : "best_compression",
        "refresh_interval" : "5s",
        "number_of_shards" : "24",
        "number_of_replicas" : "1",
        "translog" : {
          "sync_interval" : "5s",
          "durability" : "async"
        }
      }
    }

由于支持实时查询订单数据，因此我们使用 ES 的 GET Api，以订单 ID 作为 docid。主要测试 GET 和 单条 INSERT 的性能。
GET-测试结果

从上面的结果可以看出，ES 的 Get 性能表现很好，随着并发数的增加，qps 基本保持成倍增加。当并发数达到 64 时，测试机器的 cpu 负载基本跑满，导致 ES 性能压不上去，可以预计 ES 的 Get 性能还有很大的上升空间。

INSERT（以 orderid 作为 docid 写入）-测试结果

从上述结果可以看出，插入 QPS 达到 13826 左右，机器性能达到瓶颈。

总体来看，ES 的性能表现良好，足以满足我们的业务需求。

三、线上使用及踩坑

经过压测后，我们已经确定 ES 的性能能够很好的满足业务需求，于是果断将数据从 MongoDB 迁移到 Elasticsearch，并将查询切到 ES。本以为可以愉快地使用 Elasticsearch 来做订单查询了，但是一看监控，发现 ES 的负载很高，和 MongoDB 对比起来没啥优势，而且和测试结果出入很大。百思不得其解，于是通过 GET _nodes/hot_threads 查看线程堆栈，如下：

75.4% (377.2ms out of 500ms) cpu usage by thread 'elasticsearch[node-1][get][T#14]'
     3/10 snapshots sharing following 42 elements
       app//org.apache.lucene.codecs.lucene80.IndexedDISI.advance(IndexedDISI.java:384)
       app//org.apache.lucene.codecs.lucene80.IndexedDISI.nextDoc(IndexedDISI.java:459)
       app//org.apache.lucene.codecs.lucene80.Lucene80DocValuesProducer$SparseNumericDocValues.nextDoc(Lucene80DocValuesProducer.java:429)
       app//org.apache.lucene.index.ReadersAndUpdates$MergedDocValues.nextDoc(ReadersAndUpdates.java:469)
       app//org.apache.lucene.index.ReadersAndUpdates$2$1.nextDoc(ReadersAndUpdates.java:396)
       app//org.apache.lucene.index.SingletonSortedNumericDocValues.nextDoc(SingletonSortedNumericDocValues.java:53)
       app//org.apache.lucene.codecs.lucene80.Lucene80DocValuesConsumer.writeValues(Lucene80DocValuesConsumer.java:161)
       app//org.apache.lucene.codecs.lucene80.Lucene80DocValuesConsumer.addNumericField(Lucene80DocValuesConsumer.java:111)
       app//org.apache.lucene.codecs.perfield.PerFieldDocValuesFormat$FieldsWriter.addNumericField(PerFieldDocValuesFormat.java:109)
       app//org.apache.lucene.index.ReadersAndUpdates.handleDVUpdates(ReadersAndUpdates.java:373)
       app//org.apache.lucene.index.ReadersAndUpdates.writeFieldUpdates(ReadersAndUpdates.java:577)
       app//org.apache.lucene.index.ReaderPool.writeAllDocValuesUpdates(ReaderPool.java:230)
       app//org.apache.lucene.index.IndexWriter.writeReaderPool(IndexWriter.java:3311)
       app//org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:520)
       app//org.apache.lucene.index.StandardDirectoryReader.doOpenFromWriter(StandardDirectoryReader.java:297)
       app//org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:272)
       app//org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:262)
       app//org.apache.lucene.index.FilterDirectoryReader.doOpenIfChanged(FilterDirectoryReader.java:112)
       app//org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:165)
       app//org.elasticsearch.index.engine.ElasticsearchReaderManager.refreshIfNeeded(ElasticsearchReaderManager.java:66)
       app//org.elasticsearch.index.engine.ElasticsearchReaderManager.refreshIfNeeded(ElasticsearchReaderManager.java:40)
       app//org.apache.lucene.search.ReferenceManager.doMaybeRefresh(ReferenceManager.java:176)
       app//org.apache.lucene.search.ReferenceManager.maybeRefreshBlocking(ReferenceManager.java:253)
       app//org.elasticsearch.index.engine.InternalEngine.refresh(InternalEngine.java:1603)
       app//org.elasticsearch.index.engine.InternalEngine.refreshIfNeeded(InternalEngine.java:2744)
       app//org.elasticsearch.index.engine.InternalEngine.get(InternalEngine.java:698)
       app//org.elasticsearch.index.shard.IndexShard.get(IndexShard.java:943)
       app//org.elasticsearch.index.get.ShardGetService.innerGet(ShardGetService.java:169)
       app//org.elasticsearch.index.get.ShardGetService.get(ShardGetService.java:93)
       app//org.elasticsearch.index.get.ShardGetService.get(ShardGetService.java:84)
       app//org.elasticsearch.action.get.TransportGetAction.shardOperation(TransportGetAction.java:106)
       app//org.elasticsearch.action.get.TransportGetAction.shardOperation(TransportGetAction.java:45)
       ... ...

上面是GET 线程的堆栈信息，这里我们看到 GET Api 触发了 refresh 操作，而 refresh 又是一个比较耗的动作，看到这里我们可以确定导致负载高的原因大概率是 refresh 导致。那为什么会触发 refresh 呢？带着疑问，理了下 Elasticsearch-7.5.2 的源码，总结了下 GET Api 的大体流程如下：

GET 流程

从上图可以看到，ES 为了 GET 能够实时获取最新数据，会判断文档是否有 refresh（只有 refresh 后才能被检索），如果文档已经 refresh 便直接从 index 获取，否则执行 refresh 强制刷新，然后再从 index 查询。结合 GET 流程，再分析我们的业务场景，我们的订单一般都是写入后会立刻查询，因此大部分情况下文档还未 refresh 便进行检索，导致出现大量的 refresh 操作，消耗性能。

问题定位到了，但是该如何解决呢？首先想到的是官方最新版本是否有优化，于是查看 7.x 的 release note，很幸运，发现确实有优化：

release note

我们可以看到从 7.6 开始，ES 的 GET 流程改为首先从 translog 中读取数据，如果没有则读取 index，这样避免了 refresh 的开销，性能明显提升。

于是果断决定升级版本到 7.6.2，测试效果，如下：

image.png

可以看到，升级后，系统负载明显下降，效果非常明显。目前线上订单已成功迁移至 ES，并稳定运行提供服务。