redis API操作

qns_fengyusong

　　Redis 设计与实现： http://redis.readthedocs.org/en/latest/index.html#redis
     redis-cli 命令总结
　　http://www.178-go.com/archives/redis-cli-%E5%91%BD%E4%BB%A4%E6%80%BB%E7%BB%93.html
　　http://blog.csdn.net/zxkln/article/details/6117586
　　参考资料
　　http://www.cnblogs.com/shanyou/archive/2012/01/28/2330451.html
　　http://redis.io/
     
        Redis几个认识误区
　　http://54im.com/category/nosql-2/redis-nosql-2
　　http://wuhai.blog.51cto.com/2023916/932305
      
　　redis与关系数据库对应设计
　　http://labs.alcacoop.it/doku.php?id=articles:redis_land
Redis内存使用优化与存储
    http://www.infoq.com/cn/articles/tq-redis-memory-usage-optimization-storage
　　Redis在很多方面与其他数据库解决方案不同：它使用内存提供主存储支持，而仅使用硬盘做持久性的存储；它的数据模型非常独特，用的是单线程。另一个大区别在于，你可以在开发环境中使用Redis的功能，但却不需要转到Redis。
　　转向Redis当然也是可取的，许多开发者从一开始就把Redis作为首选数据库；但设想如果你的开发环境已经搭建好，应用已经在上面运行了，那么更换数据库框架显然不那么容易。另外在一些需要大容量数据集的应用，Redis也并不适合，因为它的数据集不会超过系统可用的内存。所以如果你有大数据应用，而且主要是读取访问模式，那么Redis并不是正确的选择。
　　然而我喜欢Redis的一点就是你可以把它融入到你的系统中来，这就能够解决很多问题，比如那些你现有的数据库处理起来感到缓慢的任务。这些你就可以通过Redis来进行优化，或者为应用创建些新的功能。在本文中，我就想探讨一些怎样将Redis加入到现有的环境中，并利用它的原语命令等功能来解决传统环境中碰到的一些常见问题。在这些例子中，Redis都不是作为首选数据库。
　　显示最新的项目列表
　　下面这个语句常用来显示最新项目，随着数据多了，查询毫无疑问会越来越慢。
SELECT * FROM foo WHERE ... ORDER BY time DESC LIMIT 10　　在Web应用中，“列出最新的回复”之类的查询非常普遍，这通常会带来可扩展性问题。这令人沮丧，因为项目本来就是按这个顺序被创建的，但要输出这个顺序却不得不进行排序操作。
　　类似的问题就可以用Redis来解决。比如说，我们的一个Web应用想要列出用户贴出的最新20条评论。在最新的评论边上我们有一个“显示全部”的链接，点击后就可以获得更多的评论。
　　我们假设数据库中的每条评论都有一个唯一的递增的ID字段。
　　我们可以使用分页来制作主页和评论页，使用Redis的模板：
　　-每次新评论发表时，我们会将它的ID添加到一个Redis列表：
LPUSH latest.comments 　　-我们将列表裁剪为指定长度，因此Redis只需要保存最新的5000条评论：
LTRIM latest.comments 0 5000　　-每次我们需要获取最新评论的项目范围时，我们调用一个函数来完成（使用伪代码）：
FUNCTION get_latest_comments(start,num_items):    id_list = redis.lrange("latest.comments",start,start+num_items-1)    IF id_list.length < num_items        id_list = SQL_DB("SELECT ... ORDER BY time LIMIT ...")    END    RETURN id_list END　　这里我们做的很简单。在Redis中我们的最新ID使用了常驻缓存，这是一直更新的。但是我们做了限制不能超过5000个ID，因此我们的获取ID函数会一直询问Redis。只有在start/count参数超出了这个范围的时候，才需要去访问数据库。
　　我们的系统不会像传统方式那样“刷新”缓存，Redis实例中的信息永远是一致的。SQL数据库（或是硬盘上的其他类型数据库）只是在用户需要获取“很远”的数据时才会被触发，而主页或第一个评论页是不会麻烦到硬盘上的数据库了。
　　删除与过滤
　　我们可以使用LREM来删除评论。如果删除操作非常少，另一个选择是直接跳过评论条目的入口，报告说该评论已经不存在。
　　有些时候你想要给不同的列表附加上不同的过滤器。如果过滤器的数量受到限制，你可以简单的为每个不同的过滤器使用不同的Redis列表。毕竟每个列表只有5000条项目，但Redis却能够使用非常少的内存来处理几百万条项目。
　　排行榜相关
　　另一个很普遍的需求是各种数据库的数据并非存储在内存中，因此在按得分排序以及实时更新这些几乎每秒钟都需要更新的功能上数据库的性能不够理想。
　　典型的比如那些在线游戏的排行榜，比如一个Facebook的游戏，根据得分你通常想要：
　　-列出前100名高分选手
　　-列出某用户当前的全球排名
　　这些操作对于Redis来说小菜一碟，即使你有几百万个用户，每分钟都会有几百万个新的得分。
　　模式是这样的，每次获得新得分时，我们用这样的代码：
ZADD leaderboard  　　你可能用userID来取代username，这取决于你是怎么设计的。
　　得到前100名高分用户很简单：ZREVRANGE leaderboard 0 99。
　　用户的全球排名也相似，只需要：ZRANK leaderboard 。
　　按照用户投票和时间排序
　　排行榜的一种常见变体模式就像Reddit或Hacker News用的那样，新闻按照类似下面的公式根据得分来排序：
score = points / time^alpha　　因此用户的投票会相应的把新闻挖出来，但时间会按照一定的指数将新闻埋下去。下面是我们的模式，当然算法由你决定。
　　模式是这样的，开始时先观察那些可能是最新的项目，例如首页上的1000条新闻都是候选者，因此我们先忽视掉其他的，这实现起来很简单。
　　- 每次新的新闻贴上来后，我们将ID添加到列表中，使用LPUSH + LTRIM，确保只取出最新的1000条项目。
　　- 有一项后台任务获取这个列表，并且持续的计算这1000条新闻中每条新闻的最终得分。计算结果由ZADD命令按照新的顺序填充生成列表，老新闻则被清除。这里的关键思路是排序工作是由后台任务来完成的。
　　过期项目处理
　　另一种常用的项目排序是按照时间排序。我们使用unix时间作为得分即可。
　　模式如下：
　　- 每次有新项目添加到我们的非Redis数据库时，我们把它加入到排序集合中。这时我们用的是时间属性，current_time和time_to_live。
　　- 另一项后台任务使用ZRANGE…SCORES查询排序集合，取出最新的10个项目。如果发现unix时间已经过期，则在数据库中删除条目。
　　计数
　　Redis是一个很好的计数器，这要感谢INCRBY和其他相似命令。
　　我相信你曾许多次想要给数据库加上新的计数器，用来获取统计或显示新信息，但是最后却由于写入敏感而不得不放弃它们。
　　好了，现在使用Redis就不需要再担心了。有了原子递增（atomic increment），你可以放心的加上各种计数，用GETSET重置，或者是让它们过期。
　　例如这样操作：
INCR user: EXPIRE user: 60　　你可以计算出最近用户在页面间停顿不超过60秒的页面浏览量，当计数达到比如20时，就可以显示出某些条幅提示，或是其它你想显示的东西。
　　特定时间内的特定项目
　　另一项对于其他数据库很难，但Redis做起来却轻而易举的事就是统计在某段特点时间里有多少特定用户访问了某个特定资源。比如我想要知道某些特定的注册用户或IP地址，他们到底有多少访问了某篇文章。
　　每次我获得一次新的页面浏览时我只需要这样做：
SADD page:day1: 　　当然你可能想用unix时间替换day1，比如time()-(time()%3600*24)等等。
　　想知道特定用户的数量吗？只需要使用SCARD page:day1:。
　　需要测试某个特定用户是否访问了这个页面？SISMEMBER page:day1:。
　　实时分析正在发生的情况，用于数据统计与防止垃圾邮件等
　　我们只做了几个例子，但如果你研究Redis的命令集，并且组合一下，就能获得大量的实时分析方法，有效而且非常省力。使用Redis原语命令，更容易实施垃圾邮件过滤系统或其他实时跟踪系统。
　　Pub/Sub
　　Redis的Pub/Sub非常非常简单，运行稳定并且快速。支持模式匹配，能够实时订阅与取消频道。
　　队列
　　你应该已经注意到像list push和list pop这样的Redis命令能够很方便的执行队列操作了，但能做的可不止这些：比如Redis还有list pop的变体命令，能够在列表为空时阻塞队列。
　　缓存
　　Redis的缓存部分值得写一篇新文章，我这里只是简单的说一下。Redis能够替代memcached，让你的缓存从只能存储数据变得能够更新数据，因此你不再需要每次都重新生成数据了。
　　Redis可以解决你的问题！
　　现在你就可以用上Redis，让用户感到更轻松，让你的系统变得不再复杂，让你的网站反应更快。你不需要改变现有的数据库结构，使用Redis给你的框架带来新的东西，来完成那些从前认为不可能做到/很难做到的，或是成本太高的任务。
存储结构化数据
　　例如有“通讯录”这样的数据，包含有”name”,”city”,”gender”等8个属性，使用mongoDB保存就很简单，创建一个Document，设置属性后存储即可，而Redis本身并非Document型的DB而是Key Value DB，要存储这种数据，还得在Key上面花一点功夫：使用contact:id:name,contact:id:city,contact:id:gender之类的Key来存储其对应的值。当然，这只是使用redis存储结构化数据最原始的办法，更建议的办法是使用Hash存储，如 hmset contact:id name jeff contact xx@gmail.com gender male。相对set操作而言，hmset既节省了存储空间又提高了存储效率
　　下面我们先来逐一的分析下这五种数据类型的使用和内部实现方式：

• 　　String
  　　常用命令：
  　　set,get,decr,incr,mget 等。
  　　应用场景：
  　　String是最常用的一种数据类型，普通的key/value存储都可以归为此类，这里就不所做解释了。
  　　实现方式：
  　　String在redis内部存储默认就是一个字符串，被redisObject所引用，当遇到incr,decr等操作时会转成数值型进行计算，此时redisObject的encoding字段为int。
  
• 　　Hash
  　　常用命令：
  　　hget,hset,hgetall 等。
  　　应用场景：
  　　我们简单举个实例来描述下Hash的应用场景，比如我们要存储一个用户信息对象数据，包含以下信息：
  　　用户ID为查找的key，存储的value用户对象包含姓名，年龄，生日等信息，如果用普通的key/value结构来存储，主要有以下2种存储方式：
  
  
  
  　　第一种方式将用户ID作为查找key,把其他信息封装成一个对象以序列化的方式存储，这种方式的缺点是，增加了序列化/反序列化的开销，并且在需要修改其中一项信息时，需要把整个对象取回，并且修改操作需要对并发进行保护，引入CAS等复杂问题。
  
  
  
  　　第二种方法是这个用户信息对象有多少成员就存成多少个key-value对儿，用用户ID+对应属性的名称作为唯一标识来取得对应属性的值，虽然省去了序列化开销和并发问题，但是用户ID为重复存储，如果存在大量这样的数据，内存浪费还是非常可观的。
  　　那么Redis提供的Hash很好的解决了这个问题，Redis的Hash实际是内部存储的Value为一个HashMap，并提供了直接存取这个Map成员的接口，如下图：
  
  
  
  　　也就是说，Key仍然是用户ID, value是一个Map，这个Map的key是成员的属性名，value是属性值，这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field), 也就是通过 key(用户ID) + field(属性标签) 就可以操作对应属性数据了，既不需要重复存储数据，也不会带来序列化和并发修改控制的问题。很好的解决了问题。
  　　这里同时需要注意，Redis提供了接口(hgetall)可以直接取到全部的属性数据,但是如果内部Map的成员很多，那么涉及到遍历整个内部Map的操作，由于Redis单线程模型的缘故，这个遍历操作可能会比较耗时，而另其它客户端的请求完全不响应，这点需要格外注意。
  　　实现方式：
  　　上面已经说到Redis Hash对应Value内部实际就是一个HashMap，实际这里会有2种不同实现，这个Hash的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的HashMap结构，对应的value redisObject的encoding为zipmap,当成员数量增大时会自动转成真正的HashMap,此时encoding为ht。
  
• 　　List
  　　常用命令：
  　　lpush,rpush,lpop,rpop,lrange等。
  　　应用场景：
  　　Redis list的应用场景非常多，也是Redis最重要的数据结构之一，比如twitter的关注列表，粉丝列表等都可以用Redis的list结构来实现，比较好理解，这里不再重复。
  　　实现方式：
  　　Redis list的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销，Redis内部的很多实现，包括发送缓冲队列等也都是用的这个数据结构。
  
• 　　Set
  　　常用命令：
  　　sadd,spop,smembers,sunion 等。
  　　应用场景：
  　　Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。
  　　实现方式：
  　　set 的内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。
  
• 　　Sorted set
  　　常用命令：
  　　zadd,zrange,zrem,zcard等
  　　使用场景：
  　　Redis sorted set的使用场景与set类似，区别是set不是自动有序的，而sorted set可以通过用户额外提供一个优先级(score)的参数来为成员排序，并且是插入有序的，即自动排序。当你需要一个有序的并且不重复的集合列表，那么可以选择sorted set数据结构，比如twitter 的public timeline可以以发表时间作为score来存储，这样获取时就是自动按时间排好序的。
  　　实现方式：
  　　Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。