189 8069 5689
如何使用redis实现持久化？很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。
成都创新互联公司一直在为企业提供服务，多年的磨炼，使我们在创意设计，营销型网站建设到技术研发拥有了开发经验。我们擅长倾听企业需求，挖掘用户对产品需求服务价值，为企业制作有用的创意设计体验。核心团队拥有超过10年以上行业经验，涵盖创意，策化，开发等专业领域，公司涉及领域有基础互联网服务郑州服务器托管、成都APP应用开发、手机移动建站、网页设计、网络整合营销。
RDB
RDB就是持久化的一种手段，把内存中数据在某些条件下写到磁盘中去。那么在哪些条件下写入呢？不可能无脑写入，来一个写一个，影响性能，也不能等老半天才写一个，万一中间宕机了，数据全丢失，还不如用memcached。在redis的配置里有着这样的一段配置：
save 900 1
save 300 10
save 60 10000
很关键的一段配置，这时RDB持久化的核心。意思是：
1.如果900秒时，有1个key变化（插入或者更新），我就同步到磁盘一下
2.如果300秒时，有10个key变化（插入或者更新），我就同步到磁盘一下
3.如果60秒时，有10000个key变化（插入或者更新），我就同步到磁盘一下
这些时间点和变化的数量是怎么知道的，这时有另外两个极为关键的东西，一个叫dirty计数器，一个叫lastsave（上次save的时间），dirty计数器专门记录从上次save后变化key的数量，lastsave记录执行save的时间，举个例子刚开始时间是time1，dirty是0，这时有20个key发生了变化，dirty是20，然后现在的时间是time2，time2-time1 >= 300,满足第二个条件，这时内存中的数据会save一下，同时dirty清为0，然后再等待条件触发。
如果我60秒内有10万个key，那么问题来了，一下大量磁盘io来临，这时redis主进程就会阻塞，期间的所有的命令都不执行，这哪能行，于是就来了一个叫bgsave的，它是redis主进程fork出来的一个子进程，专门执行rdb的持久化工作的。
保存的文件格式是二进制格式的，万一数据库宕机，恢复不需要人为干预，redis会自动读取磁盘文件。
AOF
与RDB不同，AOF存储的是你执行的命令，当aof功能打开的时候，执行的更新命令不会直接写到aof文件中去，而是先写到一个aof buf中，我们知道不能一直往buf中写，buf也是内存啊，那么何时才能同步到磁盘中去呢？redis中也有这样一段配置
appendfsync always
appendfsync everysec
appendfsync no
意思是：
1.只要有更新的命令我就同步
2.如果上次同步时间距离现在超过一秒就同步
3.不同步，等待操作系统自己判断（什么时候我有空我才同步）
分析下，第一种io频繁，io压力大，但丢失数据的概率最小，第二种io压力不是很大，最多也就丢失1秒左右的数据，第三中io压力很小，丢失数据概率太大。综合考虑，一般第二种。但还有个问题，我执行了100次INCR num，按道理num就是100，aof中也有100个同样的命令，没毛病，那么请问执行100次INCR num和SET num 100有什么区别，同样的结果前者多了99倍的空间，很浪费啊，于是就出现了AOF重写，它是怎么做到的。很简单：首先从数据库读取现在的值，然后用一条记录代替，这就是AOF重写的原理。重写很花时间，所以也是子进程来处理。重写的过程中，如果有新的命令来临怎么办，老办法，写buf缓冲，重写完成后，把buf中的命令追加到新的aof中，然后用新的aof替代老的aof，就实现了重写。
看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注创新互联行业资讯频道，感谢您对创新互联的支持。