微信网站开发服务,网站设计网站设计公司价格,吴桥网站,网站建站报告摘要#xff1a; 背景 Redis作为一款简洁、高效的开源K/V数据库#xff0c;可以被用于内存缓存、持久化存储等不同场景#xff0c;大量服务于各类互联网应用。同时也提供了丰富的功能配置#xff0c;客户可以根据各自业务需求#xff0c;在读写性能、缓存容量、数据可靠性…摘要 背景 Redis作为一款简洁、高效的开源K/V数据库可以被用于内存缓存、持久化存储等不同场景大量服务于各类互联网应用。同时也提供了丰富的功能配置客户可以根据各自业务需求在读写性能、缓存容量、数据可靠性等方面作出灵活的选择。
背景
Redis作为一款简洁、高效的开源K/V数据库可以被用于内存缓存、持久化存储等不同场景大量服务于各类互联网应用。同时也提供了丰富的功能配置客户可以根据各自业务需求在读写性能、缓存容量、数据可靠性等方面作出灵活的选择。
Redis提供了RDB和AOF两种持久化方式供选择4.0中更是引入了RDB-AOF混合持久化的方式整合RDB和AOF的优势提供更实时的数据持久化保证、更快的恢复速度和更紧凑的空间使用。针对AOF的写入Redis提供了两种选项供选择
• alwaysaoflog实时写入落盘保证写入数据的安全性但写入性能下降严重。
• everysecbuffer写入aoflog后台定期刷盘可以很好的保证写入性能但在failure场景下需要承担秒级新写入数据丢失的风险。
这两种模式需要用户在性能和数据安全性之间做出取舍鱼和熊掌无法兼得。对一些对数据安全性有更高要求的场景需要应用层协同来保证数据安全会给系统设计和实现带来一定的复杂度。另一方面在Redis发生failover的时候会有一个缓存预热重建的过程期间对应用会有一个可感知的不可服务时间、以及访问延时抖动。
关于上述问题很重要的一个原因在于目前DRAM和SSD请忽略HDD之间巨大的性能鸿沟。近几年备受学术界和工业界关注的NVMNon-volatile Memory 技术给这类问题的解决带来了新的机遇。 图1NVM产品的存储层次结构
目前已有的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模式的高性能。 图3Redis写入性能对比
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重建完成才能提供写服务等。后续会继续跟进这些问题结合技术和产品来一起合理改进。
原文链接
本文为云栖社区原创内容未经允许不得转载。
