想象一下,您正在某宝上抢购限时秒杀商品。正当您兴奋地点击“立即购买”,准备享受这场购物盛宴时,却发现页面反应迟钝,等待时间异常漫长。最终,当页面加载完毕时,您错失了抢购机会。这种沮丧的体验,很可能是由于背后数据库的“尾延迟”问题所造成的。
#01
「 背景介绍 」
分布式存储系统,这是一种存储数据的方法,将数据分散存储在多个服务器节点的多个硬盘上,以横向扩展的方式(scale-out),构成一个巨大的存储资源池,提高数据的安全性和访问速度。
存储系统的尾延迟(Tail Latency)指的是在一组IO请求中,延迟最高的一部分请求的延迟时间。换句话说,它代表了在处理请求时出现的最大延迟。尾延迟以最慢的一小部分请求的延迟时间来衡量,最长用的是P99时延,如果99%的IO请求的时延都小于某个时长Lat,那么这个时长Lat就是P99时延。
但如果存在一小部分请求的延迟异常高,可能会对整体用户体验产生显著影响。尾延迟可以影响系统的稳定性、可预测性和用户满意度。
对于存储系统来说,降低尾延迟是非常重要的。本文探讨:系统设计和优化应该考虑如何减少尾延迟,以保持和提升用户满意度。
#02
「 问题阐述 」
尾延迟的存在,意味着虽然大多数请求能够迅速得到响应,但总有那么一小部分请求因各种原因(如网络延迟、服务器性能波动、硬盘响应慢等)而变得异常缓慢。在高并发场景下,这种情况尤为严重,足以导致整个应用响应迟缓,严重影响用户体验。
虽然 zStorage 处理一个IO请求只需要3-4个进程配合完成,但是NVMe SSD和网络本身存在尾延迟问题,尽量缓解这个问题,对 zStorage 依然很重要。
#03
「 解决方案 」
3.1
zStorage 的工作机制
3.2
优化奥秘
3.2.1 服务等级分类和请求优先队列
服务可以提供多个接口,并且这些接口可以根据它们的重要性被分配不同的优先级。这意味着,高优先级的接口会被优先处理,而那些优先级较低或对处理速度不敏感的接口则会排在后面执行。这种优先级设置确保了关键操作能够快速响应,同时对时间不敏感的任务不会阻塞紧急任务。
例如关系型数据库为了支持事务机制,通常使用写前日志(WAL),会有数据库日志写请求产生,那么就有不同等级的写请求产生。zStorage 是针对数据库场景的分布式存储系统,对这类场景有专门优化。
zStorage 可以区分写请求的优先级,提供两种不同识别优先级方式:
-
通过特定卷设置为高优先级卷,例如数据库将日志卷设置为高优先级卷。
支持智能识别数据库日志写请求,通过分析写请求,智能判断是否为高优先级写请求。
zStorage 提供请求优先队列,将高优先级的写请求放入优先队列,优先处理数据库日志写请求,并动态监控IO队列进行调整。
3.2.2 备份读请求
降低延迟波动的一个简单策略是同时向多个副本发送相同的请求,并采用最先返回的结果。一旦有结果返回,客户端就会取消所有其他未完成的请求。然而,这种直接的实现方式可能会导致负载增加几倍,因此需要进行优化。
在实现这个机制时,需要注意以下几点:
(1) 处理条件的判断:
-
收集 Leader 之前处理过的一定数量的读请求时延数据,计算 P95 时延,当读请求的时延超过 P95 时延时,Leader将读请求转发到 Follower。这样可以避免过于频繁地转发读请求,同时也能保证系统的性能。
这里选择 P95 时延而不是 P99 时延,是因为根据《The Tail at Scale》[CACM2013]中统计数据显示对于单个随机请求,其99分位数的延迟是10毫秒。然而,当考虑所有请求时,99分位数的延迟升至140毫秒,而95%的请求在99分位数的延迟为70毫秒。这表明,最慢的5%的请求贡献了总99分位数延迟的一半。因此针对这些慢请求进行优化,可以对整体时延有巨大影响。
收集与计算 P95 时延的过程需要一定的时间,因此需要合理地选择收集的数据量和计算的时间间隔,另外也需要选择合适的工业级算法,避免产生过多的计算开销和内存开销。这里给出一些常见的业界较为成熟的算法:
-
Rocksdb使用的histogram算法(https://github.com/facebook/rocksdb/blob/main/monitoring/histogram.cc)
folly/facebook使用的t-digest算法(https://github.com/facebook/folly/blob/main/folly/stats/TDigest.cpp)
(2) 选择合适的 Follower:
选择哪个 Follower 处理读请求是一个重要的问题。这需要根据 Follower 的当前负载、网络延迟等因素进行动态调整。
zStorage 是通过一些负载均衡算法,如轮询等等,来选择合适的 Follower。这些算法需要根据实际情况进行调整,以保证系统的性能。
(3) 降低网络开销与系统稳定:
虽然读请求的转发可以提高处理速度,但也会增加网络传输的开销。因此,需要通过合理的网络调度策略,如流量控制、优先级调度等,来降低这种开销。
zStorage 在某些场景/工作模式下,例如流控模式,可以通过限制读请求的转发数量,或者开启/关闭请求转发,来保证当前系统的稳定性。
#04
「 测试结果 」
通过一系列的性能测试,zStorage 展示了其卓越的优化效果。在引入我们的优化策略前后,P99时延得到了显著降低,IOPS(输入/输出操作每秒)性能也更加稳定,响应速度有了明显改善,尤其是在高负载环境下,用户体验得到了显著提升。
#05
「 结语 」
zStorage 通过降低尾延迟,提升了用户对应用的满意度。我们将继续探索新的技术和方法,进一步优化 zStorage。
关于zStorage
zStorage 是云和恩墨针对数据库应用开发的高性能全闪分布式块存储。三节点 zStorage 集群可以达到200万IOPS随机读写性能,同时平均时延<300μs、P99时延小于800μs。
zStorage 支持多存储池、精简配置、快照/一致性组快照、链接克隆/完整克隆、NVMeoF/NVMeoTCP、iSCSI、CLI和API管理、快照差异位图(DCL)、慢盘检测、亚健康管理、16KB原子写、2副本、强一致3副本、Raft 3副本、IB和RoCE、TCP/IP、后台巡检、基于Merkle树的一致性校验、全流程TRIM、QoS、SCSI PR、SCSI CAW。
zStorage 是一个存储平台,可作为数据库产品和存储产品的底座,欢迎发邮件至 marketing@enmotech.com 咨询。
关于作者
孙镇良,云和恩墨分布式存储开发工程师,负责 zStorage 的Raft 2副本、Raft纠删码等特性开发。
数据驱动,成就未来,云和恩墨,不负所托!
云和恩墨创立于2011年,是业界领先的“智能的数据技术提供商”。公司以“数据驱动,成就未来”为使命,致力于将创新的数据技术产品和解决方案带给全球的企业和组织,帮助客户构建安全、高效、敏捷且经济的数据环境,持续增强客户在数据洞察和决策上的竞争优势,实现数据驱动的业务创新和升级发展。
自成立以来,云和恩墨专注于数据技术领域,根据不断变化的市场需求,创新研发了系列软件产品,涵盖数据库、数据库存储、数据库云管和数据智能分析等领域。这些产品已经在集团型、大中型、高成长型客户以及行业云场景中得到广泛应用,证明了我们的技术和商业竞争力,展现了公司在数据技术端到端解决方案方面的优势。