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

发布于: 22 分钟前
腾讯健康码16亿亮码背后的Elasticsearch系统调优实践

【腾讯云Elasticsearch Service】高可用,可伸缩,云端全托管。集成X-Pack高级特性,适用日志分析/企业搜索/BI分析等场景


Elasticsearch(以下简称ES)是近年来炙手可热的开源分布式搜索分析引擎,通过简单部署,就可以轻松实现日志实时分析、全文检索、结构化数据分析等多重诉求,并大幅降低挖掘数据价值的成本。本文即将介绍腾讯云 Elasticsearch Service(以下简称腾讯云ES)在“腾讯防疫健康码”应用落地过程中,遇到的挑战、优化思路、优化成果,希望能为开发者们提供参考。

2月9日,深圳成为全国首个推出“健康码”的城市。随后,防疫健康信息码在全国遍地开花:目前,腾讯防疫健康码已落地北京、广东、四川、云南、上海等20个省级行政区,覆盖300多个市县。累计亮码超过16亿人次,覆盖超过9亿人口,累计访问量破60亿。

健康码的架构师和开发者,如何快速应对万亿级数据访问挑战?如何高效地支持系统的快速迭代开发?,本文将为大家一一揭晓。


选型Elasticsearch及技术考量

防疫健康码涉及的应用场景包括社区互扫,卡口通行,居家隔离等。因此,在技术选型时,需要考虑:

  • 支持常见的如通行时间,车辆信息等这样的结构化信息查询

  • 支持存储街道/社区/小区名这样的长文本信息

  • 支持快速调整增删字段,以应对疫情防控需要的调整。

  • 支持关键字的搜索、海量数据的聚合分析以及地理位置区域计算

在数据存储选型过程中,比对一些主流产品:

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

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

腾讯云ES的图形化UI组件:配合kibana组件的UI能力,腾讯云ES可以用图形化的方式分析海量数据。同时,通过配置图形报表等形式,简化运营分析需求的开发复杂度。这种ES的数据分析能力,最终能使防疫相关的部门及人员,对疫情防控情况了如指掌。

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

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

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

1个月左右的时间,腾讯防疫健康码就覆盖了9亿用户,累计亮码16亿次。如何应对业务急速的数据查询增长,是对数据存储系统的极大挑战。

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

腾讯云ES集群配置灵活、快速、简单:开发之初,很难预测健康码系统内部的数据的最终量级,因此希望选用的技术可以灵活增加存储空间。

在用户自建的集群上,如果需要节点配置升级,通常需要采购插拔新的存储设备,或者将新的节点加入到集群中,等待数据从老的节点上进行迁移。这个过程通常会持续小时到天之久,通常由集群的数据规模所决定。

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

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

疫情就是军情,任何环节都不容有失。这需要存储系统7*24小时不间断提供稳定服务。

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

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

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

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

数据安全,万无一失

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

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

结语

腾讯防疫健康码是人员通行的重要凭证,也是疫情防控查验的可靠依据。作为服务用户最多的健康码,它的普及与腾讯云ES在数据搜索查询、高并发、弹性扩展以及安全领域的技术能力密切相关。

这还不够,未来,腾讯云ES仍将不断迭代,针对用户需求,不推打磨技术和产品,持续输出稳定可靠的Elasticsearch服务。


Elasticsearch Service免费体验馆>>

关注“腾讯云大数据”公众号,技术交流、最新活动、服务专享一站Get~

用户头像

小小的一朵云

关注

还未添加个人签名 2020.06.19 加入

还未添加个人简介

评论

发布
暂无评论
腾讯健康码16亿亮码背后的Elasticsearch系统调优实践