Home  >  Article  >  Database  >  谈谈Redis的数据持久化

谈谈Redis的数据持久化

WBOY
WBOYOriginal
2016-06-07 16:28:141257browse

我们的项目打算使用Redis来做一些缓存和计数的工作,加上redis本身就支持pub/sub模式,设计消息系统也变得简单。另外,还可以作为替代RabbitMQ等队列的方案。 考虑到我们项目微博卡以后的数据安全性问题,翻阅了很多关于持久化这块的资料。因为大家知道redis

我们的项目打算使用Redis来做一些缓存和计数的工作,加上redis本身就支持pub/sub模式,设计消息系统也变得简单。另外,还可以作为替代RabbitMQ等队列的方案。

考虑到我们项目微博卡以后的数据安全性问题,翻阅了很多关于持久化这块的资料。因为大家知道redis迅速流行起来的一个重要原因就是比memcache等纯内存键值系统来说多了原生的dump到持久化设备上的能力,具体来说就是以某种机制将内存中的数据镜像到硬盘上,结合起来看就是Memcached+Memcachedb。

现在我们来看这个将内存中数据dump到硬盘上的这个过程。这个操作过于频繁就会影响系统性能,但是间隔时间过长数据安全性就会大大降低,具体我们要通过业务上来进行判断。Redis为我们提供了两种方式:第一种是snapshot,也叫镜像;第二种是appendonlyfile,我们这些MySQL的玩家可以看为binlog(二进制日志)。第一种snapshot比较简单,就是允许我们指定一个时间范围,根据这个时间范围内redis的活跃程度来确定dump动作是否执行。比如

save 900 1

上面这个指令代表的意思是900秒,也就是十五分钟的时间内如果有一次key的更新操作,redis就会dump一次。redis默认有三个规则,具体大家可以查看文件。

第二种dump的方式就是appendonlyfile。我刚才说过了,就相当于MySQL的binlog。不过这里跟binlog设计上有点差别。MySQL的binlog随着文件越来越大,系统会根据时间和文件大小两个维度来确定是否生成新的文件,比如扩展名是1,2,3。。以此类推。而redis的这个日志文件只有一个,比如我们执行了100次写入操作,binlog会记录这100次操作的记录,redis只会以当前这100次操作后系统的现有数据作为日志文件。好处很简单,这100次操作可能修改的数据很少,比如我们的计数应用,连续100次进行incr操作,那日志就只有1条,而binlog就会有100条。每次写日志文件的时候会先fork一个子进程来写入一个临时文件之后修改文件名,但这种设计也不能避免二进制文件越来越大的问题。

现在最大的redis应用场景就是新浪微博这个项目,不知道新浪对redis的数据持久化这块有没有独到的经验。

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn