RDB方式，也称作快照snapshotting，将内存中的数据以快照的方式写入到二进制文件dump.rdb中，这种方式也是redis的默认方式。可以在redis.conf中设置保存的策略。一句话：redis在N秒内如果超过M个KEY发生修改则自动做快照保存。
AOF
AOF，即Append-Only File。要知道RDB的方式，是在一定的时间间隔做一次，如果redis意外down掉，这将意味着会丢失最后一次快照后的所有修改数据，这在生产环境将不太可能接受。AOF比RDB有着更好的持久化方式，通过AOF，redis会将每一个收到的写命令都通过write函数追加到命令中，当redis重新启动时，会重新执行文件中保存的写命令来重建数据内容。
redis.conf:
在实际应用中，为了确保数据高可靠性，应该使用always策略。
发布与订阅消息
概念上比较简单，如果你订阅了频道，那么这个频道上发布的消息，你都会知道。实际中应用较多的是消息中间件（ActiveMQ,RocketMQ）的订阅发布模式（在以后的消息中间件专题再为大家介绍）。
Redis案例设计分析
我们先来看一个京东上进行商品搜索的图：
假设一个类似的场景，有几百万，甚至几千万的商品数据，考虑下如何快速实现搜索查询呢？当然，我们不可能直接查询MySQL，应该需要在MySQL上加一层，可以考虑加一层Redis。
将MySQL中的数据加载至Redis中，给定条件，直接遍历Hash数据进行查询。如果就这样简单的设计的话，对于京东这样的大流量平台，每天有非常多的人进行商品搜索，而且每个人搜索的条件还不一样，根本无法快速响应。
如上图所示，我们可以这样设计：
我们事先建立好一系列的SET，实际上这些Set都是各种分类的ProductID集合
用户的搜索条件，实际上就是各种SET进行交、并、补的运算而已
要知道SET进行运算后的结果，就是ProductID集合，此时范围已经有所缩小，比起直接遍历全部商品数据要小不少
上这里也可以看出，Redis虽然用起来简单，但是要综合运用，并根据业务场景进行设计，还是挺有意思的。到这里就结束了，我们下期Redis集群再见！
下面关于Redis的文章您也可能喜欢，不妨参考下：
Ubuntu 14.04下Redis安装及简单测试
Ubuntu 16.04环境中安装PHP7.0 Redis扩展
CentOS 7.0 安装Redis 3.2.1详细过程和使用常见问题