丝析发解丨zStorage 的尾延迟优化

想象一下，您正在某宝上抢购限时秒杀商品。正当您兴奋地点击“立即购买”，准备享受这场购物盛宴时，却发现页面反应迟钝，等待时间异常漫长。最终，当页面加载完毕时，您错失了抢购机会。这种沮丧的体验，很可能是由于背后数据库的“尾延迟”问题所造成的。

#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) 处理条件的判断：

1. 1. 收集 Leader 之前处理过的一定数量的读请求时延数据，计算 P95 时延，当读请求的时延超过 P95 时延时，Leader将读请求转发到 Follower。这样可以避免过于频繁地转发读请求，同时也能保证系统的性能。

   2. 这里选择 P95 时延而不是 P99 时延，是因为根据《The Tail at Scale》[CACM2013]中统计数据显示对于单个随机请求，其99分位数的延迟是10毫秒。然而，当考虑所有请求时，99分位数的延迟升至140毫秒，而95%的请求在99分位数的延迟为70毫秒。这表明，最慢的5%的请求贡献了总99分位数延迟的一半。因此针对这些慢请求进行优化，可以对整体时延有巨大影响。

      

   3. 收集与计算 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年，是业界领先的“智能的数据技术提供商”。公司以“数据驱动，成就未来”为使命，致力于将创新的数据技术产品和解决方案带给全球的企业和组织，帮助客户构建安全、高效、敏捷且经济的数据环境，持续增强客户在数据洞察和决策上的竞争优势，实现数据驱动的业务创新和升级发展。

自成立以来，云和恩墨专注于数据技术领域，根据不断变化的市场需求，创新研发了系列软件产品，涵盖数据库、数据库存储、数据库云管和数据智能分析等领域。这些产品已经在集团型、大中型、高成长型客户以及行业云场景中得到广泛应用，证明了我们的技术和商业竞争力，展现了公司在数据技术端到端解决方案方面的优势。