【一】缓存

    作为Key-Value形态的内存数据库，Redis 最先会被想到的应用场景便是作为数据缓存。而使用 Redis 缓存数据非常简单，只需要通过string类型将序列化后的对象存起来即可，不过也有一些需要注意的地方：

   · 必须保证不同对象的 key 不会重复，并且使 key 尽量短，一般使用类名（表名）加主键拼接而成。

   · 选择一个优秀的序列化方式也很重要，目的是提高序列化的效率和减少内存占用。

   · 缓存内容与数据库的一致性，这里一般有两种做法：

        1.只在数据库查询后将对象放入缓存，如果对象发生了修改或删除操作，直接清除对应缓存（或设为过期）。

        2.在数据库新增和查询后将对象放入缓存，修改后更新缓存，删除后清除对应缓存（或设为过期）。

【二】时间轴（Timeline）

    list作为双向链表，不光可以作为队列使用。如果将它用作栈便可以成为一个公用的时间轴。当用户发完微博后，都通过lpush将它存放在一个 key 为LATEST_WEIBO的list中，之后便可以通过lrange取出当前最新的微博。

【三】好友关系

    这个场景最开始是是一篇介绍微博 Redis 应用的 PPT 中看到的，其中提到微博的 Redis 主要是用在在计数和好友关系两方面上，当时对好友关系方面的用法不太了解，后来看到《Redis 设计与实现》中介绍到作者最开始去使用 Redis 便是希望能通过set解决传统数据库无法快速计算集合中交集这个功能。后来联想到微博当前的业务场景，确实能够以这种方式实现，所以姑且猜测一下：

    对于一个用户 A，将它的关注和粉丝的用户 id 都存放在两个 set 中：

       · A:follow：存放 A 所有关注的用户 id

       · A:follower：存放 A 所有粉丝的用户 id

    那么通过sinter命令便可以根据A:follow和A:follower的交集得到与 A 互相关注的用户。当 A 进入另一个用户 B 的主页后，A:follow和B:follow的交集便是 A 和 B 的共同专注，A:follow和B:follower的交集便是 A 关注的人也关注了 B。

【四】分布式锁

    在 Redis 2.6.12 版本开始，string的set命令增加了三个参数：

       · EX：设置键的过期时间（单位为秒）

       · PX：设置键的过期时间（单位为毫秒）

       · NX | XX：当设置为NX时，仅当 key 存在时才进行操作，设置为XX时，仅当 key 不存在才会进行操作

        由于这个操作是原子性的，可以简单地以此实现一个分布式的锁，例如：

    set key "lock" EX 1 XX

    如果这个操作返回false，说明 key 的添加不成功，也就是当前有人在占用这把锁。而如果返回true，则说明得了锁，便可以继续进行操作，并且在操作后通过del命令释放掉锁。并且即使程序因为某些原因并没有释放锁，由于设置了过期时间，该锁也会在 1 秒后自动释放，不会影响到其他程序的运行。

【五】倒排索引

    倒排索引是构造搜索功能的最常见方式，在 Redis 中也可以通过set进行建立倒排索引，这里以简单的拼音 + 前缀搜索城市功能举例：

    假设一个城市北京，通过拼音词库将北京转为beijing，再通过前缀分词将这两个词分为若干个前缀索引，有：北、北京、b、be…beijin和beijing。将这些索引分别作为set的 key（例如:index:北）并存储北京的 id，倒排索引便建立好了。接下来只需要在搜索时通过关键词取出对应的set并得到其中的 id 即可。

【六】一些建议

    Redis 速度快是建立在内存数据库基础上的，但是一台服务器的内存要比磁盘金贵许多，所以在项目初期不要想什么都往 Redis 里放，这样当数据量上来后很快内存就会不够用，反而得不偿失。合理的利用有限的内存，将读（写）频繁的热数据放在 Redis 中才能更好感受到它带来的性能提升。

    Redis 虽然提供了RDB和AOF两种持久化方式，但是普遍还是认为 Redis 的持久化并不是很靠谱。这也是我一直不敢尝试彻底的用 Redis 去实现第三点（好友关系）的原因。

    虽然 Redis 在 3.0 之后才推出官方的集群方案，但是也有很多不错的开源方案，比如Codis。