redis

Redis简介

REmote DIctionary Server(Redis) 是一个由SalvatoreSanfilippo写的key-value存储系统。

Redis是一个开源的使用ANSI C语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

它通常被称为数据结构服务器，因为值（value）可以是字符串(String), 哈希(Map), 列表(list), 集合(sets) 和有序集合(sorted sets)等类型。

Redis特点

Redis 是完全开源免费的，遵守BSD协议，是一个高性能的key-value数据库。

Redis 与其他 key - value 缓存产品有以下三个特点：

Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。

Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。

Redis支持数据的备份，即master-slave模式的数据备份。

Redis 优势

性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s 。

丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。

原子 – Redis的所有操作都是原子性的，同时Redis还支持对几个操作全并后的原子性执行。

丰富的特性 – Redis还支持 publish/subscribe, 通知, key 过期等等特性。

Redis与其他key-value存储有什么不同？

Redis有着更为复杂的数据结构并且提供对他们的原子性操作，这是一个不同于其他数据库的进化路径。Redis的数据类型都是基于基本数据结构的同时对程序员透明，无需进行额外的抽象。

Redis运行在内存中但是可以持久化到磁盘，所以在对不同数据集进行高速读写时需要权衡内存，应为数据量不能大于硬件内存。在内存数据库方面的另一个优点是，相比在磁盘上相同的复杂的数据结构，在内存中操作起来非常简单，这样Redis可以做很多内部复杂性很强的事情。同时，在磁盘格式方面他们是紧凑的以追加的方式产生的，因为他们并不需要进行随机访问。

Redis是一个基于key-value的高速缓存系统，类似于memcached，但是支持更复杂的数据结构List、Set、Sorted Set，并且有持久化的功能。

由于近期工作很多地方都用到了它，所以花了不少时间来阅读文章、编码实验，了解一下Redis都能做些什么，能有什么样的性能表现。

首先遇到的第一个问题就是，Redis究竟是什么？

这个问题看似可笑，其实不然，我很赞同Timyang的观点，架构者对Redis的理解不同、定位也不同，决定了Redis在整个系统结构中会扮演什么样的角色。我总结一下，主流有3种理解：

1.key value store.是一个以key-value形式存储的数据库，定位直指MySQL，用来作为唯一的存储系统。

2.memory cache.是一个把数据存储在内存中的高速缓存，用来在应用和数据库间提供缓冲，替代memcachd。

3.data structrue server.把它支持对复杂数据结构的高速操作作为卖点，提供某些特殊业务场景的计算和展现需求。比如排行榜应用，Top 10之类的。

目前更多的人还是把它定位为一个memcached的升级版，提供更多的数据结构操作，仍然是一个cache。

传统的memcached在类似于SNS社区这样的业务场景下，有一些弊端。比如存储好友关系，不得不使用特殊字符分隔的长字符串来保存。在好友关系没有上限的业务需求下，操作性能低下，达不到缓存系统应有的性能水平。而且从数据库中的关系型结构映射到cache中的长字符串形式，很明显也是架构中很蹩脚的一个环节。

而Redis提供的List、Set和Sorted Set就可以很好的业务模型映射到相应的数据结构上，契合度很高。按我的理解，关系数据库理论几乎可以照搬到Redis的应用中来。

Redis官方教程中的仿Twitter案例就是一个非常好的入手点。用Set结构来存储follower和following，用List结构来保存每个人的所有post，再加上一些普通的key-value来存储用户基本信息，很直观和清晰。

我再来举一个好友关系的业务场景来描述一下我的理解，标准关系型数据库结构是怎么和Redis存储结构实现一一映射的。

数据库中有3张表：

1.用户表有两列：id、昵称

2.好友关系表有列：用户id、好友id、好友所属分组id、好友备注、添加好友时间

3.分组表：分组id、分组名称、所属用户id

增加、删除一个好友，就是在好友关系表里insert或delete一条记录。

获取某用户的所有好友分组，及分组内的好友数：

1 2 3 4 5

select g.gid, g.gname, count(f.fuid) from groups g left join friends f on g.gid=f.gid where g.uid=#uid# group by g.gid, g.gname

获取某用户某分组下的好友列表：

1 2 3 4 5 6

select f.fuid, u.nickname, f.remark, f.time from friends f left join users u on f.fuid=u.id where f.uid=#uid# and f.gid=#gid# order by f.time limit #start#, #count#

再来看看Redis如何实现类似的业务场景。

用户昵称：uid:xxxxx:nickname，以String结构存储，相当于user表

分组名称：gid:yyyyy:gname，以String结构存储

用户所有分组：uid:xxxxx:groups，以Set结构存储gid的集合

分组下好友：gid:yyyyy:friends，以Set结构存储，保存fuid的集合

好友：uid:xxxxx:fuid:zzzzz:gid、uid:xxxxx:fuid:zzzzz:remark、uid:xxxxx:fuid:zzzzz:time各自使用String结构存储，相当于friends表的每个字段

添加一个好友需要把uid:xxxxx:fuid:zzzzz:gid、uid:xxxxx:fuid:zzzzz:remark、uid:xxxxx:fuid:zzzzz:time这三个字段set好，再sadd gid:yyyyy:friends zzzzz，把好友加到这个组的集合内

获取某用户的所有好友分组，及分组内的好友数，需要用smembers获取uid:xxxxx:groups集合中的gid，再用这些gid来分别scard gid:yyyyy:friends获取该分组下有多少好友。

获取用户123456在分组1001下的好友列表：

1 2 3 4 5 6 7

sort gid:1001:friends by uid:123456:fuid:*:time limit 0 10 get # get uid:*:nickname get uid:123456:fuid:*:remark get uid:123456:fuid:*:time

很有意思是不是，很像sql语句，key中的*符号是个占位符，可以被sort出的结果替换，进而get到动态key里面的value。

我们可以总结一下，传统的关系型数据库，处理一对多的问题，需要把外键放在多的一端，因为RDBMS理论中没有集合这个直接概念。而使用Redis，我们可以很直觉的在一的一端来管理一对多的关系，使用Set。

这只是使用上的区别，而理论上，RDBMS的理论完全可以套用在Redis上，所有用关系型数据库理论可以描述的结构，用Redis的数据结构，都可以实现。

最关键的是，如果使用MySQL，当数据规模非常大时，上面两个查询操作都需要借助表关联技术，而大表间的join在大型系统中是需要极力避免的操作。相反Redis的每个操作都会局限在一个较小的数据集范围内，而且key-value的存储形式，定位key只是一个复杂度为O(1)的操作。在very huge的数据量下，Redis性能效果非常优异，这就是NoSQL的优势所在！