共计 4238 个字符，预计需要花费 11 分钟才能阅读完成。
这篇文章将为大家详细讲解有关 Redis 数据库常见的键值设计有哪些，丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
用户登录系统
记录用户登录信息的一个系统，我们简化业务后只留下一张表。
关系型数据库的设计
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 数据库常见的键值设计有哪些”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
