Redis 是一个高性能的key-value数据库。 redis的出现，很大程度补偿了memcached这类key-value存储的不足，在部 分场合可以对关系数据库起到很好的补充作用。它提供了Python，Ruby，Erlang，PHP客户端，使用很方便。
1. 按照我们一般的使用Redis的场景应该是这样的：
也就是说：我们会先去redis中判断数据是否存在，如果存在，则直接返回缓存好的数据。而如果不存在的话，就会去数据库中，读取数据，并把数据缓存到Redis中。
适用场合：如果数据量比较大，但不是经常更新的情况（比如用户排行）
2. 而第二种Redis的使用，跟第一种的情况完成不同，具体的情况请看：
这里我们会先去redis中判断数据是否存在，如果存在，则直接更新对应的数据（这一步会把对应更新过的key记录下来，比如也保存到redis中比如：key为：save_update_keys【用lpush列表记录】），并把更新后的数据返回给页面。而如果不存在的话，就会去先更新数据库中内容，然后把数据保存一份到Redis中。后面的工作：后台会有相关机制把Redis中的save_update_keys存储的key，分别读取出来，找到对应的数据，更新到DB中。
优点：这个流程的主要目的是把Redis当作数据库使用，更新获取数据比DB快。非常适合大数据量的频繁变动（比如微博）。
缺点：对Redis的依赖很大，要做好宕机时的数据保存。（不过可以使用redis的快照AOF，快速恢复的话，应该不会有多大影响，因为就算Redis不工作了，也不会影响后续数据的处理。）
难点：在前期规划key的格式，存储类型很重要，因为这会影响能否把数据同步到DB。
目前就碰到这两种Redis的应用，有什么问题或不完善的地方，欢迎大家提出，交流。
阅读(...) 评论()如何在Redis里按模式删除数据_百度知道
如何在Redis里按模式删除数据
我有更好的答案
的IDE,c-&gt.;argv[3] = tryObjectEncoding(c-&gt,0,c-&argv[3]); setGenericCommand(c;argv[1],c-&argv[3],沿着setex(Set the value and expiration of a key)命令一窥究竟.用一个可以&quot： void setexCommand(redisClient *c) { c-&find reference&argv[
其他类似问题
为您推荐：
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁如何在Redis里按模式删除数据
一台Redis服务器在很短的时间里消耗了几十个G的内存，最终因为SWAP而宕机。因为这台服务器的社会背景比较复杂，所以一时无法判断犯罪嫌疑人到底是谁。
最开始的直觉是认为肯定有人保存了大体积的数据，于是问题就变成了找出哪些键占用的空间比较大，DBA同事用了等工具来分析数据文件。可惜的是虽然找到了一些大体积的键，但最终都排除了嫌疑，问题似乎陷入了僵局。
在被直觉带入死胡同之后，我们开始调整调查的角度：即便一个键本身占用的空间并不大，但是如果相同模式的键数量很多的话，那么合计起来一样会占用大量空间，于是问题就变成了找出哪些相同模式的键占用的空间比较大。这次我不想用什么工具，而是打算在测试服务器上一边删除可疑键一边查看内存变化情况：
shell& /path/to/redis-cli keys foo:* | xargs /path/to/redis-cli del
悲催的是一运行这个命令服务器就挂了！因为数据太多了，所以受不了。此时应该使用，它有游标的概念，每次迭代只涉及很少的数据。
直接在命令行使用SCAN有些麻烦，于是我用了：
$redis = new Redis();
$redis-&setOption(Redis::OPT_SCAN, Redis::SCAN_RETRY);
$match = 'foo:*';
$count = 10000;
while ($keys = $redis-&scan($it, $match, $count)) {
$redis-&del($keys);
在删除的同时注意监控内存变化情况，就能确认问题了：
shell& watch -d -n 1 '/path/to/redis-cli info | grep memory'
至于可疑键的获取，我是瞎蒙的，简单通过或者获取采样数据即可，另外从此案例看，监控键总数的变化幅度是很重要的，从里能拿到它。
整理，转载请保留以上信息; 如有侵犯您的版权, 请联系 @ 。
本文收录于
- 做一个有思想、没理想的 2B 技术青年！
- 搜寻思想的素材，探索地狱的大门。找死！孜孜不倦的...
- 佛说，从天而降的毛毛虫，容易被订在复活的十字架上
* 本站内容基本上来自互联网,
特别感谢各位原作者。 如有侵犯版权之处，烦请邮件联系
* All of the articles come from Internet, thanks to original authors, if anything about COPYRIGHT, or LEFT, please
* 之所以建站一方面是练练手，另外也是让自己跟得上技术的进步，形成自己的资料库和思想材料库；同时最好能跟有相同爱好的小伙伴们共同交流进步。
* 整理过程中，不一定每篇都看， 有条件和想法的时候会把自己的看法编辑进去；内容有时候也不局限于 web ， 各种好玩的都可能收藏过来。
* 想法很多，时间有限；一有空就不断完善中！
分享交流站关于Redis的一些常识
日期：作者：
开源项目SpringSide发起人肖桦（）在动手试用了Redis数据库一周之后，总结了一些关于Redis的常识，在这里分享给大家。　　1. Overview　　1.1 资料《》最好的入门小册子，可以先于一切文档之前看，免费版，会不时更新。《》(O'Reilly Media, 2011)《》MEAP版，只有放出来的第一章。　　1.2 优缺点非常非常的快, 有测评说比Memcached还快。丰富的数据结构，超越了一般的Key-Value数据库，组合使用各种结构，限制Redis用途的只会是你自己的想象力， 。因为是个人作品，Redis的代码量也就1万行左右，大多选择了比较Simple的做法，使得普通公司而不是文艺公司也可以吃透它。作者认为Redis 2.6版已经成熟，2013年的精力会放在HA和Scalable上，也就是Redis-Sentinel和Redis-Cluster了。　　1.3 八卦作者是意大利的Salvatore Sanfilippo(antirez)，又是VMWare大善人聘请了他专心写Redis。antirez和我一样不喜欢搞什么咨询服务，所以Commercial Support是不会有了。默认端口6379，是手机按键上MERZ对应的号码，意大利歌女Alessia Merz是antirez和朋友们认为愚蠢的代名词。　　2. 数据结构　　2.1 KeyKey 可以是任意类型,最后都存成byte[]Key 不能太长，比如1024字节，但作者也不追求太短，要表达清楚意思才好，作者建议用":"分隔表名，用"."作为单词间的连接。显示所有的key，支持通配符 "KEYS a*" , "keys a?c"，但不建议在生产环境大数据量下使用。，对集合按数字或字母顺序排序后返回，或者存到另一个List，还可以关联到外部Key等。因为会耗用CPU，有时会安排到slave上执行。////，关于Key超时的操作，默认以秒为单位，也有p字头的以毫秒为单位的版本。其他命令： EXISTS，DEL，RENAME/RENAMENX(仅当new key不存在时)，MOVE/MIGRATE(实例内从此db到彼db/从此实例到彼实例)，RANDOMKEY，TYPE/Object(Key的类型/对象编码类型，空置时间)，DUMP/RESTORE(value值的持久化)　　2.2 String　　最普通的key-value，除了支持最基本的get/set， Redis也很喜欢添加一些简便的指令，在服务端做起来是举手之劳，客户端便方便很多。incr/decr/incrby/incrbyfloat， 如果key还不存在时创建key并设原值为0。setEx/pSetEx， Set + Expire 的简便写法,p字头以毫秒为单位。setNx， key不存在时才put进去。getset， 设置新值，返回旧值。mget/mset/msetex， 一次get/set多个key。getbit/setbit/bitop/bitcount bitmap玩法，比如统计今天的访问用户，每个用户有一个offset，今天进来的话就把那个位为1。append/setrange/getrange，只对特定的数据格式比如字段定长的有用，json格式就没用。　　2.3 Hash　　Key-HashMap结构，相比2.2中的JSON格式Value，可以只读取/更新对象的某些属性，有些属性超长就让它一边呆着不动。。　　另一个用法是用来建索引。比如User对象，除了id有时还要按name来查询，可以建一个Key为user:index:name的Hash，在插入User对象时(set user:101 {"id":101,"name":"calvin"})， 顺便往这个hash插入一条(hset user:index:name calvin 101)，这时calvin作为hash里的一个key，值为101。按name查询的时候，用hget user:index:name calvin 就能从名为calvin的key里取出id。　　2.4 List　　Redis里可以当双向链表来用，还提供blocking版本的pop函数，可以当Message Queue来用。　　不过List并没有JMS的ack机制，如果消费者把job给Pop走了又没处理完就死机了怎么办? 解决方法之一是加多一个sorted set，以分发时间为score，用户把job做完了之后要去消掉它。　　除了List标准的双向POP/PUSH外，还支持对队列内容的直接操作，比如///。　　另外经常用LTRIM限制List的大小，比如只保留最新的20条消息。LRANGE不同于POP直接弹走元素，只是返回列表内一段下标的元素。LLEN获取列表的长度。　　2.5 Set　　Set就是Set，还提供一些交集，并集，差集的集合操作。　　2.6 Sorted Set　　有序集，元素放入集合的时候要同时提供该元素的分数。/按排名的上下限返回元素，正数与倒数。/按分数的上下限返回元素，正数与倒数。/按排名/按分数删除元素。统计分数上下限之间的元素个数。/显示某个元素的正倒序的排名。/显示元素的分数/增加元素的分数。////集合操作与SET相同，少了个差集的操作。　　2.7 事务　　用//实现， 隔离级别是这边事务一天不提交，那边另一个事务还是看到旧的值。 还有个Watch指令，起到CAS的效果，如果事务提交时，Key的值已被别的事务改变，事务会被打断。　　2.8 Lua Script　　Redis2.6内置的支持，可以在Redis的Server端一次过运行大量逻辑。整个Script默认是在一个事务里的。Script里涉及的所有Key尽量用变量，从外面传入，使Redis一开始就知道你要改变哪些key。EVAL每次传输一整段Script比较费带宽，可以先用载入script，返回哈希值。然后用执行。内置的LUA库里还很贴心的带了CJSON，可以处理JSON字符串。　　3. 性能速度太快了，用光了带宽也测不出极限。如果是本地socket直连，incr可以去到很吓人的几十万TPS。普通的get/set操作，经过了LAN，延时也只有1毫秒左右，可以放心使用，不用像调用REST接口和访问数据库那样，多一次外部访问都心痛。自带的redis-benchmark默认只是基于一个很小的数据集进行测试，但可调整命令行参数如 redis-benchmark -r
-d 128 -t SET,GET 就可以默认开50条线程，SET 6M条左右(random)key是21字节长，value是128字节长的数据进去, 再GET出来。如果要一次发送多条指令，PipeLining模式能让性能更快，因为它在设计上正视了网络往返的时间。更快的是Lua Script模式，还可以包含逻辑，直接在服务端又get又set的 (见2.8 Lua Script)。单线程单CPU架构，但作者认为CPU不是瓶颈，内存与网络带宽才是。，可配置执行超过多少时间的指令算是缓慢指令(默认10毫秒，不含IO时间)，可以用slowlog get 指令查看(默认只保留最后的128条)。单线程的模型下，某个请求占掉10毫秒是件大事情。　　4. 容量　　最大内存：一定要设置最大内存，否则物理内存用爆了就会大量使用Swap，写RDB文件时的速度慢得你想死。多留一倍内存是最安全的。重写AOF文件和RDB文件的进程(即使不做持久化，复制到Slave的时候也要写RDB)会fork出一条新进程来，采用了操作系统的Copy-On-Write策略(如果父进程的内存没被修改，子进程与父进程共享Page。如果父进程的Page被修改, 会复制一份改动前的内容给新进程)，留意Console打出来的报告，如"RDB: 1215 MB of memory used by copy-on-write"。在系统极度繁忙时，如果父进程的所有Page在子进程写RDB过程中都被修改过了，就需要两倍内存。按照Redis启动时的提醒，设置 vm.overcommit_memory = 1 ，使得fork()一条10G的进程时，因为COW策略而不一定需要有10G的free memory.当最大内存到达时，按照配置的Policy进行处理， 默认policy为volatile-lru， 对设置了expire time的key进行LRU清除(不是按实际expire time)。如果沒有数据设置了expire time或者policy为noeviction，则直接报错，但此时系统仍支持get之类的读操作。 另外还有几种policy，比如volatile-ttl按最接近expire time的，allkeys-lru对所有key都做LRU。原来2.0版的VM(将Value放到磁盘，Key仍然放在内存)，2.4版后又不支持了。　　内存占用：测试表明，stirng类型需要90字节的额外代价，就是说key1个字节，value一个字节时，还是需要占用92字节的长度，而上述的benchmark的记录就占用了239个字节。用make 32bit可以编译出32位的版本，每个指针占用的内存更小，但只支持最大4GB内存。　　Sharding：Jedis支持在客户端做分区，局限是不能动态re-sharding， 有分区的master倒了，必须用slave顶上。要增加分区的话，呃.....Redis-Cluster是今年工作重点，支持automatic re-sharding， 采用和Hazelcast类似的算法，总共有N个分区，每台Server负责若干个分区。客户端先hash出key 属于哪个分区，然后发给负责这个分区的Server。Re-sharding时，会将某些分区的数据移到新的Server上，然后各Server周知分区&-&Server映射的变化，因为分区数量有限，所以通讯量不大。 在迁移过程中，原server对于已经迁移走的数据的get请求，会回一个临时转向的应答。　　5. 高可用性　　5.1 持久化　　综述：，　　RDB文件：整个内存的压缩过的Snapshot，, 可以配置写Snapshot的复合触发条件，默认是60秒内改了1万次或300秒内改了10次或900秒内改了1次。RDB在写入过程中，会连内存一起Fork出一个新进程，遍历新进程内存中的数据写RDB。先写到临时文件再Rename，这样外部程序对RDB文件的备份和传输过程是安全的。而且即使写新快照的过程中Server被强制关掉了，旧的RDB文件还在。可配置是否进行压缩，方法是是字符串的LZF算法 和String形式的数字变回int形式存储。　　AOF文件：append only的操作日志，等于mysql的binlog，记录所有有效的写操作，格式是明文的的纯文本文件。一般配置成每秒调用一次fsync将数据写到磁盘，坏处是操作系统非正常关机时，可能会丢1秒的数据。 如果设为fsync always，性能只剩几百TPS，不用考虑。如果使用了AOF，重启时只会从AOF文件载入数据，不会管RDB文件。AOF文件过大时，会fork出一条新进程来将文件重写(也是先写临时文件再rename)， 遍历新进程的内存中数据，每条记录有一条的Set语句。默认配置是当AOF文件大小是上次rewrite后的大小的一倍时触发。Redis协议的内容，如set mykey hello， 将持久化成*3 $3 set $5 mykey $5 hello， 第一个数字代表这条语句有多少元，其他的数字代表后面字符串的长度。这样的设计，使得即使在写文件过程中突然关机导致文件不完整，也能自我修复，执行redis-check-aof即可。&&& RDB不会实时写入数据，而且如果同时使用两者，但服务器重启只会找AOF文件。那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。　　读写性能：AOF重写和RDB写入都是在fork出进程后，遍历新进程内存顺序写的，既不影响主进程，顺序写的速度也比随机写快，在普通PC服务器上把刚才的1.5G数据写成一个200M的RDB文件大约8秒， 启动时载入一个1.4G的AOF文件大约13秒。2.4版以后，lpush可以一次push多个值了，使得AOF重写时可以将旧版本中的多个lpush指令合成一个。有人建议设置no-appendfsync-on-rewrite 为 yes，aof rewrite时就不执行fsync了，先都存在内存里，减少IO资源争用。 当然这样会丢数据。Fork一个使用了大量内存的进程也要时间，大约10ms per GB的样子，。　　其他：正确关闭服务器：redis-cli shutdown 或者 kill，都会graceful shutdown，保证写RDB文件以及将AOF文件fsync到磁盘，不会丢失数据。 如果是Ctrl+C，或者kill -9 就会丢失数据。执行指令可触发rdb存盘，可触发aof重写。　　5.2 Master-Slave复制可以在配置文件、命令行参数、以及执行SLAVEOF指令的来设置。当前版本，一旦执行SlaveOF， slave会清掉自己的所有数据，执行一次全同步：Master要bgsave出自己的一个RDB文件，发给Slave。然后再增量同步: Master作为一个普通的client连入slave，将所有写操作转发给slave，没有特殊的同步协议。作者在2.8版本中将支持测试表明同步延时非常小。有建议只在Slave上写RDB和AOF文件，但这样master启动时就需要从slave copy文件，fail-over脚本也更复杂。只要有足够内存，master平时IO也不高的话，还是简化架构更好。　　5.3 Fail-Over　　5.3.1 概述　　是2.6版开始加入的另一组独立运行的节点, 提供自动Fail Over的支持。每秒钟对所有master，slave和其他sentinel执行ping，redis-server节点要应答+PONG或-LOADING或-MASTERDOWN.如果某一台Sentinel没有在30秒内(可配置得短一些哦)收到上述正确应答，它就会认为master处于sdown状态(主观Down)它向其他sentinel询问是否也认为master倒了(SENTINEL is-master-down-by-addr )， 如果quonum台(默认是2)sentinels在5秒钟内都这样认为，就会认为master真是odown了(客观Down)。此时会选出一台sentinel作为Leader执行fail-over, Leader会从slave中选出一个提升为master(执行slaveof none)，这台slave必须状态正常，而且INFO显示它与master的复制连接并没有断开太久。然后让其他slave指向它(执行slaveof new master)。&&& 5.3.2 master/slave 及 其他sentinels的发现　　master地址在sentinel的配置文件里, sentinel会每10秒一次向master发送INFO，知道master的slave有哪些。 如果master已经变为slave，sentiel会分析INFO的应答指向新的master。所以当sentiel重启时，它的配置文件里master的地址并没变，那它仍然会去找old master，然后被redirect到新的master。但如果old master还没起来，或者old master没把自己变成slave，悲剧就可能发生。　　另外，sentinel会在master上建一个pub/sub channel，通告各种信息，比如+sdown/-sdown， 而且sentinel们也是通过接收pub/sub channel上的+sentinel的信息发现彼此，因为每台sentinel每5秒会发送一次__sentinel__:hello，宣告自己的存在。　　5.3.3 自定义脚本sentinel在failover时还会执行配置文件里指定的用户reconfig脚本，让master变为slave并指向新的master。脚本在如下时机被调用： 1. slave开始提升成master，2.所有slave都已指向新master，3.各种原因提升被终止。脚本的将会在命令行按顺序传入如下参数： &master-name& &role(leader/observer)& &state(上述三种情况)& &from-ip& &from-port& &to-ip& &to-port&脚本返回0是正常，如果返回1会被重新执行，如果返回2或以上不会。 如果超过60秒没返回会被强制终止。　　另一种notify脚本在收到任何pub/sub信息时都会调用，让你去通知O&M系统。　　5.3.4 Client集成　　client中执行语句SENTINEL get-master-addr-by-name mymaster 可获得当前master的地址。 但是Jedis还没集成sentinel,只有一个热心网友提交了　　，使用了完全不同的思路，不基于Sentinel，而是多写随机读，学术名词是ReadOne-WriteAll-tx(see NoSQL数据库的分布式算法), 一开始就同步写入到所有节点，读的话随便读一个还活着的节点就行了。(但节点死掉重新起来后怎么重新同步?什么时候可以重新作为一个可选的master?)　　Redis作者也在博客里抱怨。　　5.4 Geographic-Redundancy　　一个方法是用rsync等工具同步RDB文件，但RDB文件是非常不实时的。　　如果要求更高，可以自己写程序读取AOF文件或MONITOR，把指令转发给远处的站点，反正里头的内容就是Redis协议。　　6. 维护　　配置　　可以在配置文件中编写， 也可以在启动时的命令行配置， 如redis-server --port 7777 --slaveof 127.0.0.1 8888，还可以在cli中执行CONFIG GET， 可以达到不重启服务的修改配置参数的效果。　　监控　　 有详细的介绍。　　将返回非常丰富的信息。着重监控检查内存使用，比如是否已接近上限，比如有无大量使用swap(used_memory - used_memory_rss)还有AOF与RDB文件的保存情况，master-slave的关系也要重点监控。STAT中信息还包括key命中率，所有命令的执行次数，所有client连接数量等，
可重置。　　其他SlowLog 检查慢操作(见2.性能)配置sentinel的notify.sh脚本对所有事件告警或自己用PING/INFO监控节点状态(见5.3.3)可以显示Server收到的所有指令，可以用于debug。， 基于Python的DashBoard，使用INFO和MONITOR获得系统情况和指令统计分析。Instagram的，基于Python，使用MONITOR对指令进行统计分析.基于Python，可以分析RDB文件，比如每条Key对应value所占的大小，还可以将RDB dump成文本文件然后进行比较，还可以将RDB输出成JSON格式。Redis作者自己写的，基于Ruby，统计数据分布情况。　　维护用redis-check-aof/redis-check-dump 修复烂掉的文件。在系统闲时调用 bgrewriteaof 重写AOF文件。　　7. 其他　　 ,过期数据的清除从来不容易，Redis使用了一种相对务实的做法当client主动get的时候会先进行判断。如果clien永远都不再get那条key呢? 它会在后台，每秒10次的执行如下操作： 随机选取100个key校验是否过期，如果有25个以上的key过期了，立刻随机选取下100个key，可见如果数据不被主动get，它什么时候最终被清理掉是未知的。上述主动清理只会在master进行，slave们会收到从master发过来的DEL指令，master的AOF文件也会插入一条DEL。　　　　8. Java Driver　　各个Driver好像只有比较活跃。　　不需要的封装，因为Jedis已足够简单，所以它没有像对MongoDB java driver的封装那样能简化代码，所谓屏蔽各种底层driver的差异并不太吸引人，因为我就没打算选其他几种driver。　　Jedis基于Apache Commons Pool做的连接池，默认最大连接数只有8，一般需要重新设置。　　9. Windows的版本　　Windows版本方便单机调测，但Redis并没有提供，好在微软提供了一个，暂时基于Redis 2.4版本。 /MSOpenTech/redis 因为github现在已经没有Download服务了，所以编译好的可执行文件藏在这里 /MSOpenTech/redis/tree/2.4/msvs/bin/release
微信公众号
TechTarget
TechTarget中国
查看更多评论
敬请读者发表评论，本站保留删除与本文无关和不雅评论的权力。
NoSQL技术现在仍然处于相对初级的阶段，众多NoSQL软件类型和产品服务令人眼花缭乱，选择合适的性能管理方案也成为一件颇具挑战性的事。
NoSQL是对数据库由内而外的全方位改造，从而创造出一个高容量、高速度和高可变性的架构。然而，NoSQL供应商在可变性部分却正在遭遇失败。
GPU技术的使用是一些机器学习应用的前沿和核心。Facebook，百度、亚马逊和其他一些公司正在使用的GPU集群来研究深层神经网络相关的机器学习应用程序。
NoSQL数据库有多少类型？如何选择合适的NoSQL数据库？我们将介绍选择列族数据库和图型数据库必须考虑的因素。
在进行Oracle Web开发的时候，程序员再也没有理由说自己找不到合适的开发工具了。在过去几年中，出现了许多基于Oracle数据库的Web开发工具，这些工具可以帮助程序员更加快速高效便捷地进行Web应用开发。
在本次的技术手册中，我们将介绍关于Oracle&11g的一些新特性，并对部署Oracle&11g的硬件服务器进行详细的评定，以便DBA参考。
Oracle公司的数据加载工具ODI（Oracle&Data&Integrator）提出了一种“ELT”的架构，也是数据整合的一个开发平台,，在不同信息系统或者数据库之间做数据传输、转换。
在本次技术手册中，我们将结合Microsoft Hyper-V，为您介绍SQL Server虚拟化的基础知识，包括创建容错安装、维护虚拟机的高可用性以及部署SQL Server虚拟设备到Hyper-V等精彩内容。
TechTarget
企业级IT网站群
TechTarget中国 版权所有
All Rights Reserved, Copyright
TechTarget中国 版权所有
All Rights Reserved, CopyrightRedis中5种数据结构的使用场景介绍
投稿：junjie
字体：[ ] 类型：转载 时间：
这篇文章主要介绍了Redis中5种数据结构的使用场景介绍,本文对Redis中的5种数据类型String、Hash、List、Set、Sorted Set做了讲解,需要的朋友可以参考下
一、redis 数据结构使用场景
原来看过 redisbook 这本书，对 redis 的基本功能都已经熟悉了，从上周开始看 redis 的源码。目前目标是吃透 redis 的数据结构。我们都知道，在 redis 中一共有5种数据结构，那每种数据结构的使用场景都是什么呢？
String——字符串
Hash——字典
List——列表
Set——集合
Sorted Set——有序集合
下面我们就来简单说明一下它们各自的使用场景：
1. String——字符串
String 数据结构是简单的 key-value 类型，value 不仅可以是 String，也可以是数字（当数字类型用 Long 可以表示的时候encoding 就是整型，其他都存储在 sdshdr 当做字符串）。使用 Strings 类型，可以完全实现目前 Memcached 的功能，并且效率更高。还可以享受 Redis 的定时持久化（可以选择 RDB 模式或者 AOF 模式），操作日志及 Replication 等功能。除了提供与 Memcached 一样的 get、set、incr、decr 等操作外，Redis 还提供了下面一些操作：
1.LEN niushuai：O(1)获取字符串长度
2.APPEND niushuai redis：往字符串 append 内容，而且采用智能分配内存（每次2倍）
3.设置和获取字符串的某一段内容
4.设置及获取字符串的某一位（bit）
5.批量设置一系列字符串的内容
6.原子计数器
7.GETSET 命令的妙用，请于清空旧值的同时设置一个新值，配合原子计数器使用
2. Hash——字典
在 Memcached 中，我们经常将一些结构化的信息打包成 hashmap，在客户端序列化后存储为一个字符串的值（一般是 JSON 格式），比如用户的昵称、年龄、性别、积分等。这时候在需要修改其中某一项时，通常需要将字符串（JSON）取出来，然后进行反序列化，修改某一项的值，再序列化成字符串（JSON）存储回去。简单修改一个属性就干这么多事情，消耗必定是很大的，也不适用于一些可能并发操作的场合（比如两个并发的操作都需要修改积分）。而 Redis 的 Hash 结构可以使你像在数据库中 Update 一个属性一样只修改某一项属性值。
存储、读取、修改用户属性
3. List——列表
List 说白了就是链表（redis 使用双端链表实现的 List），相信学过数据结构知识的人都应该能理解其结构。使用 List 结构，我们可以轻松地实现最新消息排行等功能（比如新浪微博的 TimeLine ）。List 的另一个应用就是消息队列，可以利用 List 的 *PUSH 操作，将任务存在 List 中，然后工作线程再用 POP 操作将任务取出进行执行。Redis 还提供了操作 List 中某一段元素的 API，你可以直接查询，删除 List 中某一段的元素。
1.微博 TimeLine
2.消息队列
4. Set——集合
Set 就是一个集合，集合的概念就是一堆不重复值的组合。利用 Redis 提供的 Set 数据结构，可以存储一些集合性的数据。比如在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。因为 Redis 非常人性化的为集合提供了求交集、并集、差集等操作，那么就可以非常方便的实现如共同关注、共同喜好、二度好友等功能，对上面的所有集合操作，你还可以使用不同的命令选择将结果返回给客户端还是存集到一个新的集合中。
1.共同好友、二度好友
2.利用唯一性，可以统计访问网站的所有独立 IP
3.好友推荐的时候，根据 tag 求交集，大于某个 threshold 就可以推荐
5. Sorted Set——有序集合
和Sets相比，Sorted Sets是将 Set 中的元素增加了一个权重参数 score，使得集合中的元素能够按 score 进行有序排列，比如一个存储全班同学成绩的 Sorted Sets，其集合 value 可以是同学的学号，而 score 就可以是其考试得分，这样在数据插入集合的时候，就已经进行了天然的排序。另外还可以用 Sorted Sets 来做带权重的队列，比如普通消息的 score 为1，重要消息的 score 为2，然后工作线程可以选择按 score 的倒序来获取工作任务。让重要的任务优先执行。
1.带有权重的元素，比如一个游戏的用户得分排行榜
2.比较复杂的数据结构，一般用到的场景不算太多
二、redis 其他功能使用场景
1. 订阅-发布系统
Pub/Sub 从字面上理解就是发布（Publish）与订阅（Subscribe），在 Redis 中，你可以设定对某一个 key 值进行消息发布及消息订阅，当一个 key 值上进行了消息发布后，所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统，比如普通的即时聊天，群聊等功能。
2. 事务——Transactions
谁说 NoSQL 都不支持事务，虽然 Redis 的 Transactions 提供的并不是严格的 ACID 的事务（比如一串用 EXEC 提交执行的命令，在执行中服务器宕机，那么会有一部分命令执行了，剩下的没执行），但是这个 Transactions 还是提供了基本的命令打包执行的功能（在服务器不出问题的情况下，可以保证一连串的命令是顺序在一起执行的，中间有会有其它客户端命令插进来执行）。Redis 还提供了一个 Watch 功能，你可以对一个 key 进行 Watch，然后再执行 Transactions，在这过程中，如果这个 Watched 的值进行了修改，那么这个 Transactions 会发现并拒绝执行。
您可能感兴趣的文章:
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具