Redis数据库常见的键值设计有哪些

这篇文章将为大家详细讲解有关redis数据库常见的键值设计有哪些，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。

成都创新互联公司科技有限公司专业互联网基础服务商，为您提供成都服务器托管，高防服务器租用，成都IDC机房托管，成都主机托管等互联网服务。

用户登录系统

记录用户登录信息的一个系统，我们简化业务后只留下一张表。

关系型数据库的设计

MySQL>select*fromlogin;

+---------+----------------+-------------+---------------------+

|user_id|name|login_times|last_login_time|

+---------+----------------+-------------+---------------------+

|1|kenthompson|5|2011-01-0100:00:00|

|2|dennisritchie|1|2011-02-0100:00:00|

|3|JoeArmstrong|2|2011-03-0100:00:00|

+---------+----------------+-------------+---------------------+

user_id表的主键，name表示用户名，login_times表示该用户的登录次数，每次用户登录后，login_times会自增，而last_login_time更新为当前时间。

REDIS的设计

关系型数据转化为KV数据库，我的方法如下：

key表名：主键值：列名

value列值

一般使用冒号做分割符，这是不成文的规矩。比如在php-adminforredis系统里，就是默认以冒号分割，于是user:1user:2等key会分成一组。于是以上的关系数据转化成kv数据后记录如下：

Setlogin:1:login_times5

Setlogin:2:login_times1

Setlogin:3:login_times2

Setlogin:1:last_login_time2011-1-1

Setlogin:2:last_login_time2011-2-1

Setlogin:3:last_login_time2011-3-1

setlogin:1:name”kenthompson“

setlogin:2:name“dennisritchie”

setlogin:3:name”JoeArmstrong“

这样在已知主键的情况下，通过get、set就可以获得或者修改用户的登录次数和最后登录时间和姓名。

一般用户是无法知道自己的id的，只知道自己的用户名，所以还必须有一个从name到id的映射关系，这里的设计与上面的有所不同。

set"login:kenthompson:id"1

set"login:dennisritchie:id"2

set"login:JoeArmstrong:id"3

这样每次用户登录的时候业务逻辑如下(python版)，r是redis对象，name是已经获知的用户名。

#获得用户的id

uid=r.get("login:%s:id"%name)

#自增用户的登录次数

ret=r.incr("login:%s:login_times"%uid)

#更新该用户的最后登录时间

ret=r.set("login:%s:last_login_time"%uid,datetime.datetime.now())

如果需求仅仅是已知id，更新或者获取某个用户的最后登录时间，登录次数，关系型和kv数据库无啥区别。一个通过btreepk，一个通过hash，效果都很好。

假设有如下需求，查找最近登录的N个用户。开发人员看看，还是比较简单的，一个sql搞定。

select*fromloginorderbylast_login_timedesclimitN

DBA了解需求后，考虑到以后表如果比较大，所以在last_login_time上建个索引。执行计划从索引leafblock的最右边开始访问N条记录，再回表N次，效果很好。

有哪些常见Redis数据库键值的设计

过了两天，又来一个需求，需要知道登录次数最多的人是谁。同样的关系型如何处理?DEV说简单

select*fromloginorderbylogin_timesdesclimitN

DBA一看，又要在login_time上建立一个索引。有没有觉得有点问题呢，表上每个字段上都有素引。

关系型数据库的数据存储的的不灵活是问题的源头，数据仅有一种储存方法，那就是按行排列的堆表。统一的数据结构意味着你必须使用索引来改变sql的访问路径来快速访问某个列的，而访问路径的增加又意味着你必须使用统计信息来辅助，于是一大堆的问题就出现了。

没有索引，没有统计计划，没有执行计划，这就是kv数据库。

redis里如何满足以上的需求呢?对于求最新的N条数据的需求，链表的后进后出的特点非常适合。我们在上面的登录代码之后添加一段代码，维护一个登录的链表，控制他的长度，使得里面永远保存的是最近的N个登录用户。

#把当前登录人添加到链表里

ret=r.lpush("login:last_login_times",uid)

#保持链表只有N位

ret=redis.ltrim("login:last_login_times",0,N-1)

这样需要获得最新登录人的id，如下的代码即可

last_login_list=r.lrange("login:last_login_times",0,N-1)

另外，求登录次数最多的人，对于排序，积分榜这类需求，sortedset非常的适合，我们把用户和登录次数统一存储在一个sortedset里。

zaddlogin:login_times51

zaddlogin:login_times12

zaddlogin:login_times23

这样假如某个用户登录，额外维护一个sortedset，代码如此

#对该用户的登录次数自增1

ret=r.zincrby("login:login_times",1,uid)

那么如何获得登录次数最多的用户呢，逆序排列取的排名第N的用户即可

ret=r.zrevrange("login:login_times",0,N-1)

可以看出，DEV需要添加2行代码，而DBA不需要考虑索引什么的。

TAG系统

tag在互联网应用里尤其多见，如果以传统的关系型数据库来设计有点不伦不类。我们以查找书的例子来看看redis在这方面的优势。

关系型数据库的设计

两张表，一张book的明细，一张tag表，表示每本的tag，一本书存在多个tag。

mysql>select*frombook;

+------+-------------------------------+----------------+

|id|name|author|

+------+-------------------------------+----------------+

|1|TheRubyProgrammingLanguage|MarkPilgrim|

|1|Rubyonrail|DavidFlanagan|

|1|ProgrammingErlang|JoeArmstrong|

+------+-------------------------------+----------------+

mysql>select*fromtag;

+---------+---------+

|tagname|book_id|

+---------+---------+

|ruby|1|

|ruby|2|

|web|2|

|erlang|3|

+---------+---------+

假如有如此需求，查找即是ruby又是web方面的书籍，如果以关系型数据库会怎么处理?

selectb.name,b.authorfromtagt1,tagt2,bookb

wheret1.tagname='web'andt2.tagname='ruby'andt1.book_id=t2.book_idandb.id=t1.book_id

tag表自关联2次再与book关联，这个sql还是比较复杂的，如果要求即ruby，但不是web方面的书籍呢?

关系型数据其实并不太适合这些集合操作。

REDIS的设计

首先book的数据肯定要存储的，和上面一样。

setbook:1:name”TheRubyProgrammingLanguage”

Setbook:2:name”Rubyonrail”

Setbook:3:name”ProgrammingErlang”

setbook:1:author”MarkPilgrim”

Setbook:2:author”DavidFlanagan”

Setbook:3:author”JoeArmstrong”

tag表我们使用集合来存储数据，因为集合擅长求交集、并集

saddtag:ruby1

saddtag:ruby2

saddtag:web2

saddtag:erlang3

那么，即属于ruby又属于web的书?

inter_list=redis.sinter("tag.web","tag:ruby")

即属于ruby，但不属于web的书?

inter_list=redis.sdiff("tag.ruby","tag:web")

属于ruby和属于web的书的合集?

inter_list=redis.sunion("tag.ruby","tag:web")

简单到不行阿。

从以上2个例子可以看出在某些场景里，关系型数据库是不太适合的，你可能能够设计出满足需求的系统，但总是感觉的怪怪的，有种生搬硬套的感觉。

尤其登录系统这个例子，频繁的为业务建立索引。放在一个复杂的系统里，ddl(创建索引)有可能改变执行计划。导致其它的sql采用不同的执行计划，业务复杂的老系统，这个问题是很难预估的，sql千奇百怪。要求DBA对这个系统里所有的sql都了解，这点太难了。这个问题在oracle里尤其严重，每个DBA估计都碰到过。对于MySQL这类系统，ddl又不方便(虽然现在有onlineddl的方法)。碰到大表，DBA凌晨爬起来在业务低峰期操作，这事我没少干过。而这种需求放到redis里就很好处理，DBA仅仅对容量进行预估即可。

关于“Redis数据库常见的键值设计有哪些”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。