我们已经看到了一个常见的字符串使用案例,即通过关键字存储对象的实例。有时候,你会频繁地用到这类操作:
set users:leto "{name: leto, planet: dune, likes: [spice]}"
strlen <key>
能用来获取一个关键字对应值的长度;getrange <key> <start> <end>
将返回指定范围内的关键字对应值;append <key> <value>
会将value附加到已存在的关键字对应值中(如果该关键字并不存在,则会创建一个新的关键字-值对)。散列数据结构很像字符串数据结构。两者显著的区别在于,散列数据结构提供了一个额外的间接层:一个域(Field)。因此,散列数据结构中的set
和get
是:
hset users:goku powerlevel 9000
hget users:goku powerlevel
相关的操作还包括在同一时间设置多个域、同一时间获取多个域、获取所有的域和值、列出所有的域或者删除指定的一个域:
hmset users:goku race saiyan age 737
hmget users:goku race powerlevel
hgetall users:goku
hkeys users:goku
hdel users:goku age
如你所见,散列数据结构比普通的字符串数据结构具有更多的可操作性。我们可以使用一个散列数据结构去获得更精确的描述,是存储一个用户,而不是一个序列化对象。从而得到的好处是能够提取、更新和删除具体的数据片段,而不必去获取或写入整个值。
对于一个给定的关键字,列表数据结构让你可以存储和处理一组值。你可以添加一个值到列表里、获取列表的第一个值或最后一个值以及用给定的索引来处理值。列表数据结构维护了值的顺序,提供了基于索引的高效操作。为了跟踪在网站里注册的最新用户,我们可以维护一个newusers
的列表:
lpush newusers goku
ltrim newusers 0 50
(译注:ltrim
命令的具体构成是LTRIM Key start stop
。要理解ltrim
命令,首先要明白Key所存储的值是一个列表,理论上列表可以存放任意个值。对于指定的列表,根据所提供的两个范围参数start和stop,ltrim
命令会将指定范围外的值都删除掉,只留下范围内的值。)
4.集合(Sets)
集合数据结构常常被用来存储只能唯一存在的值,并提供了许多的基于集合的操作,例如并集。集合数据结构没有对值进行排序,但是其提供了高效的基于值的操作。使用集合数据结构的典型用例是朋友名单的实现:
sadd friends:leto ghanima paul chani jessica
sadd friends:duncan paul jessica alia
不管一个用户有多少个朋友,我们都能高效地(O(1)时间复杂度)识别出用户X是不是用户Y的朋友:
sismember friends:leto jessica
sismember friends:leto vladimir
而且,我们可以查看两个或更多的人是不是有共同的朋友:
sinter friends:leto friends:duncan
甚至可以在一个新的关键字里存储结果:
sinterstore friends:leto_duncan friends:leto friends:duncan
标记提供了排序(sorting)和秩划分(ranking)的功能。如果我们想要一个秩分类的朋友名单,可以这样做:
zadd friends:duncan 70 ghanima 95 paul 95 chani 75 jessica 1 vladimir
对于duncan
的朋友,要怎样计算出标记(score)为90或更高的人数?
zcount friends:duncan 90 100
如何获取chani
在名单里的秩(rank)?
zrevrank friends:duncan chani
(译注:zrank
命令的具体构成是ZRANK Key menber
,要知道Key存储的Sorted Set默认是根据Score对各个menber进行升序的排列,该命令就是用来获取menber在该排列里的次序,这就是所谓的秩。)
zrevrank
命令而不是
zrank
命令,这是因为Redis的默认排序是从低到高,但是在这个例子里我们的秩划分是从高到低。对于分类集合数据结构,最常见的应用案例是用来实现排行榜系统。
数据库读写分离(M/S)–>数据库使用多个Slave–>增加Cache (memcache)–>转到Redis
4.开发成本需求 : Cache和DB的一致性维护成本越来越高(先清理DB, 再清理缓存, 不行啊, 太慢了!)
5.开发需要跟上不断涌入的产品需求 : 硬件成本最贵的就是数据库层面的机器,基本上比前端的机器要贵几倍,主要是IO密集型,很耗硬件;
6.维护性复杂
一致性维护成本越来越高;
7.BerkeleyDB使用B树,会一直写新的,内部不会有文件重新组织;这样会导致文件越来越大;大的时候需要进行文件归档,归档的操作要定期做;
这样,就需要有一定的down time;