我们的项目打算使用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的数据持久化这块有没有独到的经验。