redis学习笔记——应用场景

最近在看redis入门指南，现在就自己的学习情况说说自己的理解。

字符串类型（String）

字符串类型是Redis中最基本的类型，能存储任意形式的字符串，包括二进制数据。如一张照片也可以用字符串类型存储。注意字符串类型键允许存储的数据最大容量是512M。

Strings 数据结构是简单的key-value类型，value其实不仅是String，也可以是数字。除了get、set、incr、decr 等操作外，Redis还提供了下面一些操作：

获取字符串长度；
往字符串append内容；
设置和获取字符串的某一段内容；
设置及获取字符串的某一位（bit）；
批量设置一系列字符串的内容；

所以字符串类型用来保存字符串和计数都是非常方便的。就拿一篇博客来说：实现文章访问量的统计、生成自增ID、被评论多少次，转发多少次，赞多少次，被浏览多少次，有多少个好友等等同时包括存储文章的内容都只需要使用字符串类型便可以实现。

散列类型(hash)

散列就是hash，散列类型用于存储比如用户的昵称、年龄、性别、积分等是非常方便的，都能实现只有O（1）的复杂度。同时对这些内容的修改也会非常方便。

就比如：关系数据库中如果要存储汽车对象，存储结构如下表所示：

如果想为 ID 为 1 的汽车增加生产日期属性，就需要把数据表更改为如下表所示的结构：

对于 ID 为 2 和 3 的两条记录而言 date 字段是冗余的。可想而知当不同的记录需要不同的属性时，表的字段数量会越来越多以至于难以维护。

但是在redis中就没有这样的情况。当然redis在我看来也会形成很大的浪费，就像上面的例子：如果汽车的数量太多的话，那每一辆车都有一个color、name、price这些字符需要去保存，虽然后面有精简键名的方法那也是很浪费啊。

其实还有一个疑问：redis上面列举的例子都是一层关系模型，那多层的时候redis是将多层进行分解吗？

列表类型(list)

list是用链表实现的，而且是双向链表。这样的话很显而易见的就是在两端插入和删除是非常方便的O(1)，所以list提供的操作基本操作lpush、rpush、lpop、rpop。

同时不难看出list很容易实现栈和队列。

基于上面的这些原因：list主要运用于取最新N个数据的操作，如社交网站上的新鲜事，最新的新闻，最新更新的博客这些使用list实现可以事半功倍。

有个问题一直想不清楚：书上说列表是有序的字符串列表，所谓的有序难道是push 时间的先后吗？？

集合类型

集合我们首先应该注意到的是：存储不重复的键，注意不重复也就是唯一的意思。

我们也应该注意到集合是用值为空的散列表实现的，呵呵，那么其实他实现不重复的原理其实就是使用了散列表(hash)的键值(key)唯一的特性。

既然他是一种特殊形式的散列表，那么散列表快速访问——O（1）的特性同样存在与集合之中。所以访问集合的时间复杂度就是O(1)咯。

好了我们来看看集合主要用在一些什么地方呢？

uniq的特性——Uniq操作，获取某段时间所有数据排重值；

简单粗暴的并交叉操作——比如在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。Redis为集合提供了求交集、并集、差集等操作，可以非常方便的实现如共同关注、共同喜好、二度好友等功能，对上面的所有集合操作，你还可以使用不同的命令选择将结果返回给客户端还是存集到一个新的集合中；

有序集合

有序集合是按照某种分数的高低来排序。

有序集合是利用散列表和跳跃表来实现的。

主要运用：比如一个存储全班同学成绩的Sorted Sets，其集合value可以是同学的学号，而score就可以是其考试得分，这样在数据插入集合的时候，就已经进行了天然的排序。这就是：排行榜应用，取TOP N操作。

另外还可以用Sorted Sets来做带权重的队列，比如普通消息的score为1，重要消息的score为2，然后工作线程可以选择按score的倒序来获取工作任务，让重要的任务优先执行。这就是传说中的：构建有优先级的队列系统。

需要精准设定过期时间的应用——如你可以把上面说到的sorted set的score值设置成过期时间的时间戳，那么就可以简单地通过过期时间排序，定时清除过期数据了，不仅是清除Redis中的过期数据，你完全可以把Redis里这个过期时间当成是对数据库中数据的索引，用Redis来找出哪些数据需要过期删除，然后再精准地从数据库中删除相应的记录。

其他的

Pub/Sub构建实时消息系统——Redis的Pub/Sub系统可以构建实时的消息系统，比如很多用Pub/Sub构建的实时聊天系统的例子，我觉得qq消息里面@all就可以用这个实现；

其他的比较高大上的运用的话你不妨参考：http://www.csdn.net/article/1970-01-01/2817107