阿里云基于NVM的持久化高性能Redis数据库

摘要：背景 redis作为一款简洁、高效的开源k/v数据库，可以被用于内存缓存、持久化存储等不同场景，大量服务于各类互联网应用。同时也提供了丰富的功能配置，客户可以根据各自业务需求，在读写性能、缓存容量、数据可靠性等方面作出灵活的选择。
背景
redis作为一款简洁、高效的开源k/v数据库，可以被用于内存缓存、持久化存储等不同场景，大量服务于各类互联网应用。同时也提供了丰富的功能配置，客户可以根据各自业务需求，在读写性能、缓存容量、数据可靠性等方面作出灵活的选择。
redis提供了rdb和aof两种持久化方式供选择，4.0中更是引入了rdb-aof混合持久化的方式，整合rdb和aof的优势，提供更实时的数据持久化保证、更快的恢复速度和更紧凑的空间使用。针对aof的写入，redis提供了两种选项供选择：
• always：aoflog实时写入落盘，保证写入数据的安全性，但写入性能下降严重。
• everysec：buffer写入aoflog，后台定期刷盘，可以很好的保证写入性能，但在failure场景下，需要承担秒级新写入数据丢失的风险。
这两种模式需要用户在性能和数据安全性之间做出取舍，鱼和熊掌无法兼得。对一些对数据安全性有更高要求的场景，需要应用层协同来保证数据安全，会给系统设计和实现带来一定的复杂度。另一方面，在redis发生failover的时候，会有一个缓存预热重建的过程，期间对应用会有一个可感知的不可服务时间、以及访问延时抖动。
关于上述问题，很重要的一个原因在于目前dram和ssd（请忽略hdd）之间巨大的性能鸿沟。近几年，备受学术界和工业界关注的nvm（non-volatile memory）技术，给这类问题的解决带来了新的机遇。
图1：nvm产品的存储层次结构
目前已有的nvm产品，对上层应用提供dimm形态的访问接口。作为一种nvm设备，相比于dram具备掉电不丢数据的特性，容量上也会比dram高出一个数量级，成本优势明显。相比于传统ssd，不但读写速度更快（百ns量级），而且具备字节寻址的能力。同时也要看到，nvm产品仍然存在读写不对称、顺序和随机访问不对称等特征。
从应用场景上来看，nvm产品可以定位于替代部分dram功能，支撑持久memory或in-memory应用。具体来说可被应用在如下场景：
• 持久化内存：作为数据持久层，对数据一致性要求很高的持久化系统，同时兼顾数据可靠性和数据读写性能。
• 内存数据库：作为数据in place空间，提供数据运行和持久化存储空间。
• 系统日志卷：作为日志卷，例如，在hpc系统中通常采用checkpointing实现对计算中间状态进行持久化保存，这是一个耗时、耗系统吞吐量的过程。
基于nvm产品提供的字节寻址、持久化、高性能的能力，以及考虑到其读写、顺序和随机访问不对称等特性，对redis作了细致的设计和深度的定制化改造，针对上面几个问题取得非常好的测试效果。
性能分析前面提到redis的always模式通过实时flush操作确保aof文件的实时持久化，但这会导致性能大幅下降。everysec模式通过大幅减少flush操作的频率，基于page cache缓冲对设备的读写访问大幅提升qps性能，但是这会引入秒级的数据丢失风险。而基于nvm产品提供的持久化能力可以非常优雅地解决这个问题，兼顾性能和可靠性。整个的数据流图如下：
图2: 基于nvm产品的数据读写流程
首先将aof文件直接放在基于nvm产品的pmem-aware filesystem上（比如ext4 dax模式），通过mmap将aof文件映射到用户态地址空间，之后对aof的访问操作就变成了非常轻量的直接load/store方式，而且要确保数据持久化也仅需要在用户态执行persist操作（主要是cache flush）。可见，基于nvm产品的aof持久化机制相比传统的io栈要轻量的多：
b• bypass整个传统io栈（block层->设备驱动等），实现直接load/store操作。
• 通过cache flush操作即可实现持久化，取代了flush系统调用。
aof机制的另一个问题是aof文件的持续增大会造成巨大的空间浪费，所以阿里云redis团队通过后台线程的方式按照一定的策略（考虑吞吐和资源占用量等）对aof文件进行replay操作。即根据aof命令在nvm产品上构造持久化的kv数据结构，然后完成回放的aof文件就可以删除，从而解决了aof占用空间的问题。
之所以选择后台线程异步replay的方式在nvm上构建持久化数据结构，是因为该过程需要通过事务操作来保证写操作的原子性和数据结构的一致性，耗时较大，所以数据先写到ddr的方式可以保证客户端写操作的qps不下降。考虑到nvm拥有出色的读性能，数据异步replay到nvm之后，会根据数据冷热和内存占用量释放部分value比较大的内存副本，转而直接基于nvm提供读服务。所以dram逐渐演变为nvm的写cache和热数据的读cache，以充分发挥nvm的读性能和成本优势，同时规避nvm写性能（相对）的短板问题。
在两台96核/384gb神龙服务器上，实测string数据结构的set操作，从结果数据来看几乎与everysec模式的性能持平，同时兼顾了always模式的数据安全性和everysec模式的高性能。
图3：redis写入性能对比
redis在重启时需要进行数据恢复操作。原生redis重启后都需要从rdb和aof中加载数据到内存，完成加载后才可以正常提供服务。经过实测，10gb左右数据的rdb加载时间大概为53秒左右，这段时间内redis服务处于不可用状态。而在基于nvm的方案中，redis重启后可以先基于nvm的持久化数据结构直接提供读服务，dram数据结构重建完成后即可提供完整的读写服务。同样针对10gb左右的数据集，系统shutdown save后重启，实测1秒内可以提供只读服务，35秒内可以提供完整读写服务，整个数据恢复时间大幅下降。如下图所示：
图4: redis recovery时间对比
另外，原生redis通过fork一个子进程来保存全量db数据到rdb或aof文件，即使相比上次保存的数据仅有一个key的变更，也依然会全量保存整个db，显然这不是一种高效的实现方式。并且该过程会对redis带来较大的性能抖动。而基于nvm的方案是一种持续增量持久化的方式，更加高效和平滑，这点对于在线服务来说至关重要。
nvm相比dram能提供更高的存储密度和更大容量的数据存储空间，因此可以有效降低单位数据存储成本。基于nvm的字节寻址能力和与dram的速度差异，我们设计了nvm非易失性内存和dram易失性内存间的数据换入与换出策略，能在不影响redis基本性能的前提下，提高数据的存储容量并节约成本。
结束语整个方案中，充分发挥了nvm的字节寻址、持久化等能力，借助dram做cache来弥补nvm读写不对称的问题，从而实现了高可靠、高性能、低成本的redis数据库，从测试数据可以看出nvm对redis在持久化以及其他性能方面提升效果非常显著。
除此之外，nvm相比dram能提供更高的存储密度和更大容量的数据存储空间，因此可以有效降低单位数据存储成本。在不影响redis基本读写性能的前提下，基于nvm和dram的动态数据输入换出，是我们下一步工作的方向之一。
当然，目前方案仍存在一些待优化的点，比如：对于高写入场景，replay性能跟不上dram写入速度；failover时候，需要等dram重建完成才能提供写服务等。后续会继续跟进这些问题，结合技术和产品来一起合理改进。
原文链接
本文为云栖社区原创内容，未经允许不得转载。