redis数据备份怎么恢复
Memcached真的过时了吗?Redis与Memcached的比较？
Memcached真的过时了吗?Redis与Memcached的比较？
很多开发者都认为Redis不可能比Memcached快，Memcached完全基于内存，而Redis具有持久化保存特性，即使是异步的，Redis也不可能比Memcached快。但是测试结果基本是Redis占绝对优势。一直在思考这个原因，目前想到的原因有这几方面。
Libevent。和Memcached不同，Redis并没有选择libevent。Libevent为了迎合通用性造成代码庞大(目前Redis代码还不到libevent的1/3)及牺牲了在特定平台的不少性能。Redis用libevent中两个文件修改实现了自己的epoll event loop(4)。业界不少开发者也建议Redis使用另外一个libevent高性能替代libev，但是作者还是坚持Redis应该小巧并去依赖的思路。一个印象深刻的细节是编译Redis之前并不需要执行./configure。
CAS问题。CAS是Memcached中比较方便的一种防止竞争修改资源的方法。CAS实现需要为每个cache key设置一个隐藏的cas token，cas相当value版本号，每次set会token需要递增，因此带来CPU和内存的双重开销，虽然这些开销很小，但是到单机10G cache以及QPS上万之后这些开销就会给双方相对带来一些细微性能差别(5)。
redis备份策略？
redis持久化的两种方式：
RDB: 对内存中数据库状态进行快照
AOF: 把每条写命令都写入文件
RDB方式：将redis在内存中的数据库状态保存到磁盘里面，RDB文件是一个经过压缩的二进制文件，通过该文件可以还原生成RDB文件的数据状态。
AOF方式：是通过保存redis服务器所执行的写命令来记录数据库状态的AOF文件刷新方式，有三种：
always -- 每提交一个修改命令都调用fsync到AOF文件，非常慢，但是很安全；
everysec -- 每秒都调用fsyns刷新到AOF文件，很快但可能丢失一秒内的数据；
no -- 依靠OS进行刷新，redis不主动刷新AOF，这样最快但是安全性差；