腾讯健康码 16 亿亮码背后的 Elasticsearch 系统调优实践

微信邦

Elasticsearch（以下简称 ES）是近年来炙手可热的开源分布式搜索分析引擎，通过简单部署，就可以轻松实现日志实时分析、全文检索、结构化数据分析等多重诉求，并将挖掘数据价值的成本大幅降低。
之前分享过一篇相关文章：

腾讯万亿级 Elasticsearch 技术解密

本文将深入介绍腾讯云  Elasticsearch Service（以下简称腾讯云 ES）在“防疫健康码”应用落地过程中，遇到的挑战、优化思路、优化成果，希望能为开发者们提供参考。

2 月 9 日，腾讯联合各方推出“防疫健康码”，民众只需要通过微信申请涵盖自身健康信息的二维码，获得电子出行凭证，就可以在疫情期间便捷地出入公共场所。目前，腾讯防疫健康码已落地北京、广东、四川、云南、上海等 20 个省级行政区，覆盖 300 多个市县，累计亮码超过 16 亿人次，覆盖超过 9 亿人口，累计访问量破 60 亿。

作为防疫健康码的架构和开发者，如何在种类繁多的存储产品中选择出最合适业务的一款，如何能在有限的时间内高效地支持系统的快速迭代开发，另外，在突发的全国疫情应急背景下，如何快速应对万亿级数据访问挑战，本文就为大家揭秘健康码背后 Elasticsearch 的系统调优实践。

1 选型 Elasticsearch 及技术考量

防疫健康码涉及的应用场景繁多，包括社区互扫，卡口通行，居家隔离等等。因此，在数据类型方面，需要支持常见的如通行时间，车辆信息等这样的结构化信息查询，也有如街道/社区/小区名这样的长文本信息。另外，伴随着疫情防控的需要的调整，还需具备快速调整增删字段的功能；在查询方面，不仅需要支持传统的结构化信息的查询，还需要支持关键字的搜索技术、海量数据的聚合分析技术以及地理位置区域计算技术。

在数据存储选型过程中，我们做了一些主流产品的对比和思考：

如传统的关系数据库 MySQL，在事务型应用及多业务多表关联查询方面有着出色的表现，但是面对健康码系统复杂繁多的数据类型，特别是文本关键字搜索能力时显得捉襟见肘。腾讯云 ES 基于 lucene 查询引擎构建，通过倒排索引结构，可以快速的通过搜索关键字找到所需要的记录，在万亿级海量数据规模性，依然能达到毫秒级的查询响应。相比于使用传统关系型数据库的 like 命令进行匹配查找，搜索查询效率提升了近百倍。

腾讯健康码 16 亿亮码背后的 Elasticsearch 系统调优实践

倒排索引结构

对于比较热门的 NoSQL 类产品 MongoDB，虽然和 ES 一样，能满足多样化的数据类型的支持，且可以根据业务的需要随时动态的增加字段且不影响业务正常的查询写入，但是同样缺少文本关键字的检索能力。且相比于 ES 来说，缺少海量数据的分析聚合能力及图形化的 UI 组件。腾讯云 ES 通过 doc_value 列存结构及聚合框架，支持包括按关键字分桶、时间分桶、距离分桶、求平均值、求和、求地理位置边界等等，多达 60 种聚合算子。

配合 kibana 组件的 UI 能力，可以通过图形化的方式进行海量数据的分析。同时，通过配置图形报表等形式，简化运营分析人员的开发复杂度，最终能使防疫相关的部门及人员，通过 ES 的数据分析能力，做到对于疫情防控的情况了如指掌。

在海量数据的存储方面，虽然相当多的大数据产品，如 hive 数仓、Hbase 等，拥有海量的数据存储能力，且具备一定的数据分析能力，但是相比于 ES 来说，不仅整个技术栈及架构比较重，需要维护的开源组件繁多，通常需要一支专门的运维团队进行集群的日常维护。对于开发人员来说，开发方法及接口较为复杂，对于初次接触大数据平台的开发者来说需要具备相当多的基础知识后才能开始上手开发。

腾讯云 ES 使用 Restful 风格的 API，在上手调试方面要简单很多，且提供了多达 10+的官方 SDK 及 20+的社区 SDK，基本覆盖了市面上所有的主流开发语言。社区生态十分活跃，文档齐全，生态组件丰富。通过 SDK 及生态组件的整合，减少了大量的编码工作，极大的加快了开发的流程，可以高效的应对紧急业务开发上线的需求。

2 业务数据极速增长，如何快速扩容

随着疫情防控在全国范围内的铺开，接入健康码的省市自治区快速的增加，截止目前已扫码次数达 16 亿次，覆盖 9 亿用户。如何应对业务急速的数据查询增长，对数据存储系统构成了极大的挑战。

https://img-blog.csdnimg.cn/2018122217352470

腾讯云 ES 采用分布式架构，索引数据通过分区算法，分割为多个数据分片（shard），平均的分布在集群的多个节点上。通过节点和数据分片的能力，可以线性的扩展索引数据写入查询的吞吐，这个是传统的单实例数据库所不具备的。

由于健康码系统内部的数据，随着疫情的进展会持续的增长且很难预测数据的最终量级，需要能比较灵活的增加 ES 的存储空间。在用户自建的集群上，如果需要节点的配置升级，通常需要采购插拔新的存储设备，或者需要将新的节点加入到集群中，等待数据从老的节点上进行迁移。这个过程通常会持续小时到天之久，通常由集群的数据规模所决定。

腾讯云 ES 构建于基础 IaaS 层之上，使用 CVM 及 CBS 云硬盘，具有一定的存储计算分离能力。存储空间可以动态的扩展，对于 ES 节点来说完全是透明的，无感知的。类似健康码这样的数据规模不断增长的需求，一次存储空间的扩展操作从过去的小时或天的级别降低到了秒级，且所有的集群变更操作都可以在腾讯云控制台上进行，极大的降低了集群配置变更的运维复杂度，把后台业务人员从繁重的运维工作中解脱出来。

3 腾讯云 ES 服务高可用技术架构

在疫情防控任务面前，任何环节不容有失，需要存储系统能 7*24 小时不间断的提供服务，提高服务可用性，保证整个健康码系统的稳定性。

腾讯健康码 16 亿亮码背后的 Elasticsearch 系统调优实践

腾讯云ES支持多可用区集群容灾功能

https://ask.qcloudimg.com/draft/2187473/z51prcixbi.png?imageView2/2/w/1620

腾讯云 ES 服务支持多可用区容灾的功能，当一个可用区因为机房电力、网络等故障的原因导致不可用时，另外一个可用区的节点仍然能稳定、不间断的提供服务，保障客户业务的可靠性。

这也是基于 ES 的分布式原理，当用户选择使用支持多可用区容灾的腾讯云 ES 集群后，系统会为用户在多个可用区部署节点，且节点会平均的部署到各个可用区机房中。由于索引数据是可以进行分片，且设置副本。根据 ES 的分片分配原理，所有的分片及副本会平均的分布在所有的节点之上。这就保证了，如果设置的副本数和可用区数目一致，当有一个节点乃至一个可用区机房不可用，剩余节点中的分片仍是一份完整的数据，且主从分片可以自动切换，集群仍然可以持续的对外提供写入查询服务。

防疫工作机构及人员需要每天及时掌握疫情的防控情况，需要不定时的对数据进行汇总分析查询。然而，在全国海量的防疫数据场景下，集群很容易由于不严谨的聚合分析语句导致大量的数据在节点内存中进行分桶，排序等计算，从而使节点发生 OOM 的问题，造成节点乃至整个集群的雪崩。

为了防止此类情况发生导致的集群不可用，腾讯云 ES 在存储内核上开发了基于实际内存的熔断限流机制。当集群发现部分节点的 JVM 使用率超过设定的熔断阀值，会进行服务降级，梯度的拦截部分查询的请求，直至 JVM 使用率超过 95%会最终熔断，阻止所有的查询请求。这个熔断的请求拦截机制会覆盖 Rest 层及 Transport 层，通过将熔断提前至 Rest 层，可以尽早的将请求进行拦截，降低集群在熔断状态下的查询压力。通过这些措施，保证了健康码小程序海量查询下的服务可用性及查询性能。

4、数据安全，万无一失

近年来，海内外数据泄露事件频出。健康码系统使用的腾讯云 ES 在安全方面做了最高级别的优化，包括支持配置内外网访问黑白名单，支持集群权限认证功能。极大的提高了数据的安全性。并且，不同用户集群之间通过 VPC 进行网络隔离，杜绝了潜在的黑客入侵的风险。

腾讯云 ES 支持基于 COS 的增量数据备份功能，用户可以通过 ES 原生的索引生命周期管理功能，定时增量的备份底层的数据文件到腾讯云对象存储 COS。当需要的时候，可以随时将数据备份恢复至任意的集群，保证了数据的安全可靠性，做到数据的万无一失。

结语：

腾讯防疫健康码目前已广泛应用于机场、火车站、高速公路、商业区、小区等防疫检查卡口，有效帮助卫生防疫部门全面排查疑似患者，阻击疫情的快速传播。健康码能如此稳定安全的支撑 10 亿级别的数据访问，腾讯云 ES 在数据搜索查询、高并发、弹性扩展以及安全领域的技术功不可没，后续腾讯云将继续针对用户需求，不推打磨技术和产品，为更多用户提供稳定安全可靠的 Elasticsearch 服务。