谈谈Redis的持久化
谈谈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的数据持久化这块有没有独到的经验。
