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秒内可以提供完整读写服务，整个数据恢复时间大幅下降。如下图所示：
