redis学习总结

redis学习总结

 

 参考:

https://blog.csdn.net/richard_jason/article/details/53130369

https://www.cnblogs.com/mrhgw/p/6278619.html

https://www.cnblogs.com/xuliangxing/p/7151812.html 

https://blog.csdn.net/i10630226/article/details/79058513

https://blog.csdn.net/happy_wu/article/details/78736641 

https://blog.csdn.net/black_ox/article/details/48972085

 

 

Redis各个数据类型的使用场景

Redis支持五种数据类型：string（字符串），hash（哈希），list（列表），set（集合）及zset（sorted set：有序集合）。

Redis列表命令

参考：http://www.redis.net.cn/tutorial/3501.html

---

使用场景

String

String数据结构是简单的key-value类型，value其实不仅可以是String，也可以是数字。 
常规key-value缓存应用； 
常规计数：微博数，粉丝数等。

hash

Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。 
存储部分变更的数据，如用户信息等。

list

list就是链表，略有数据结构知识的人都应该能理解其结构。使用Lists结构，我们可以轻松地实现最新消息排行等功能。List的另一个应用就是消息队列，可以利用List的PUSH操作，将任务存在List中，然后工作线程再用POP操作将任务取出进行执行。Redis还提供了操作List中某一段的api，你可以直接查询，删除List中某一段的元素。 
Redis的list是每个子元素都是String类型的双向链表，可以通过push和pop操作从列表的头部或者尾部添加或者删除元素，这样List即可以作为栈，也可以作为队列。

消息队列系统 
使用list可以构建队列系统，使用sorted set甚至可以构建有优先级的队列系统。 
比如：将Redis用作日志收集器 
实际上还是一个队列，多个端点将日志信息写入Redis，然后一个worker统一将所有日志写到磁盘。

取最新N个数据的操作

//把当前登录人添加到链表里
ret = r.lpush("login:last_login_times", uid)
//保持链表只有N位
ret = redis.ltrim("login:last_login_times", 0, N-1)
//获得前N个最新登陆的用户Id列表
last_login_list = r.lrange("login:last_login_times", 0, N-1)

比如sina微博: 
在Redis中我们的最新微博ID使用了常驻缓存，这是一直更新的。但是做了限制不能超过5000个ID，因此获取ID的函数会一直询问Redis。只有在start/count参数超出了这个范围的时候，才需要去访问数据库。 
系统不会像传统方式那样“刷新”缓存，Redis实例中的信息永远是一致的。SQL数据库（或是硬盘上的其他类型数据库）只是在用户需要获取“很远”的数据时才会被触发，而主页或第一个评论页是不会麻烦到硬盘上的数据库了。

set

set就是一个集合，集合的概念就是一堆不重复值的组合。利用Redis提供的set数据结构，可以存储一些集合性的数据。set中的元素是没有顺序的。 
案例： 
在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。Redis还为集合提供了求交集、并集、差集等操作，可以非常方便的实现如共同关注、共同喜好、二度好友等功能，对上面的所有集合操作，你还可以使用不同的命令选择将结果返回给客户端还是存集到一个新的集合中。

交集，并集，差集

//book表存储book名称
set book:1:name "The Ruby Programming Language"
set book:2:name "Ruby on rail"
set book:3:name "Programming Erlang"

//tag表使用集合来存储数据，因为集合擅长求交集、并集
sadd tag:ruby 1
sadd tag:ruby 2
sadd tag:web 2
sadd tag:erlang 3

//即属于ruby又属于web的书？
 inter_list = redis.sinter("tag:web", "tag:ruby")
//即属于ruby，但不属于web的书？
 diff_list = redis.sdiff("tag:ruby", "tag:web")
//属于ruby和属于web的书的合集？
 union_list = redis.sunion("tag:ruby", "tag:web")

获取某段时间所有数据去重值 
这个使用Redis的set数据结构最合适了，只需要不断地将数据往set中扔就行了，set意为集合，所以会自动排重。

sorted set

和set相比，sorted set增加了一个权重参数score，使得集合中的元素能够按score进行有序排列，比如一个存储全班同学成绩的sorted set，其集合value可以是同学的学号，而score就可以是其考试得分，这样在数据插入集合的时候，就已经进行了天然的排序。可以用sorted set来做带权重的队列，比如普通消息的score为1，重要消息的score为2，然后工作线程可以选择按score的倒序来获取工作任务。让重要的任务优先执行。

排行榜应用，取TOP N操作 
这个需求与上面需求的不同之处在于，前面操作以时间为权重，这个是以某个条件为权重，比如按顶的次数排序，这时候就需要我们的sorted set出马了，将你要排序的值设置成sorted set的score，将具体的数据设置成相应的value，每次只需要执行一条ZADD命令即可。

//将登录次数和用户统一存储在一个sorted set里
zadd login:login_times 5 1
zadd login:login_times 1 2
zadd login:login_times 2 3

//当用户登录时，对该用户的登录次数自增1
ret = r.zincrby("login:login_times", 1, uid)
//那么如何获得登录次数最多的用户呢，逆序排列取得排名前N的用户
ret = r.zrevrange("login:login_times", 0, N-1)

比如在线游戏的排行榜，根据得分你通常想要：

     - 列出前100名高分选手

     - 列出某用户当前的全球排名

这些操作对于Redis来说小菜一碟，即使你有几百万个用户，每分钟都会有几百万个新的得分。 
模式是这样的，每次获得新得分时，我们用这样的代码：

ZADD leaderboard <score> <username>

你可能用userID来取代username，这取决于你是怎么设计的。 
得到前100名高分用户很简单：

ZREVRANGE leaderboard 0 99

用户的全球排名也相似，只需要：

ZRANK leaderboard <username>

需要精准设定过期时间的应用 
比如你可以把上面说到的sorted set的score值设置成过期时间的时间戳，那么就可以简单地通过过期时间排序，定时清除过期数据了，不仅是清除Redis中的过期数据，你完全可以把Redis里这个过期时间当成是对数据库中数据的索引，用Redis来找出哪些数据需要过期删除，然后再精准地从数据库中删除相应的记录。

范围查找 
来自Redis在Google Group上的一个问题，有一位同学发贴求助，说要解决如下的一个问题：他有一个IP范围对应地址的列表，现在需要给出一个IP的情况下，迅速的查找到这个IP在哪个范围，也就是要判断此IP的所有地。这个问题引来了Redis作者Salvatore Sanfilippo（@antirez）的回答。解答如下： 
例如有下面两个范围，10－20和30－40 
- A_start 10, A_end 20 
- B_start 30, B_end 40 
我们将这两个范围的起始位置存在Redis的sorted set数据结构中，基本范围起始值作为score，范围名加start和end为其value值：

redis 127.0.0.1:6379> zadd ranges 10 A_start
1
redis 127.0.0.1:6379> zadd ranges 20 A_end
1
redis 127.0.0.1:6379> zadd ranges 30 B_start
1
redis 127.0.0.1:6379> zadd ranges 40 B_end
1

这样数据在插入sorted set后，相当于是将这些起始位置按顺序排列好了。 
现在我需要查找15这个值在哪一个范围中，只需要进行如下的zrangbyscore查找：

redis 127.0.0.1:6379> zrangebyscore ranges (15 +inf LIMIT 0 1
1) "A_end"

这个命令的意思是在Sorted Sets中查找大于15的第一个值。（+inf在Redis中表示正无穷大，15前面的括号表示>15而非>=15） 
查找的结果是A_end，由于所有值是按顺序排列的，所以可以判定15是在A_start到A_end区间上，也就是说15是在A这个范围里。至此大功告成。 
当然，如果你查找到的是一个start，比如咱们用25，执行下面的命令:

redis 127.0.0.1:6379> zrangebyscore ranges (25 +inf LIMIT 0 1
1) "B_start"

返回结果表明其下一个节点是一个start节点，也就是说25这个值不处在任何start和end之间，不属于任何范围。 
当然，这个例子仅适用于类似上面的IP范围查找的案例，因为这些值范围之间没有重合。如果是有重合的情况，这个问题本身也就变成了一个一对多的问题。

Pub/Sub

Pub/Sub 从字面上理解就是发布（Publish）与订阅（Subscribe），在Redis中，你可以设定对某一个key值进行消息发布及消息订阅，当一个key值上进行了消息发布后，所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统，比如普通的即时聊天，群聊等功能。

使用场景

Pub/Sub构建实时消息系统

Redis的Pub/Sub系统可以构建实时的消息系统 
比如很多用Pub/Sub构建的实时聊天系统的例子。

参考： 
http://www.redis.net.cn/tutorial/3501.html 
http://www.cnblogs.com/markhe/p/5689356.html 
http://www.cnblogs.com/ggjucheng/p/3349102.html

redis 数据类型详解 以及 redis适用场景场合

Redis常用数据类型

Redis最为常用的数据类型主要有以下：

• String
• Hash
• List
• Set
• Sorted set
• pub/sub
• Transactions

在具体描述这几种数据类型之前，我们先通过一张图了解下Redis内部内存管理中是如何描述这些不同数据类型的：

         首先Redis内部使用一个redisObject对象来表示所有的key和value,redisObject最主要的信息如上图所示：

         type代表一个value对象具体是何种数据类型，

         encoding是不同数据类型在redis内部的存储方式，

         比如：type=string代表value存储的是一个普通字符串，那么对应的encoding可以是raw或者是int,如果是int则代表实际redis内部是按数值型类存储和表示这个字符串的，当然前提是这个字符串本身可以用数值表示，比如:"123" "456"这样的字符串。

       这里需要特殊说明一下vm字段，只有打开了Redis的虚拟内存功能，此字段才会真正的分配内存，该功能默认是关闭状态的，该功能会在后面具体描述。通过上图我们可以发现Redis使用redisObject来表示所有的key/value数据是比较浪费内存的，当然这些内存管理成本的付出主要也是为了给Redis不同数据类型提供一个统一的管理接口，实际作者也提供了多种方法帮助我们尽量节省内存使用，我们随后会具体讨论。

3.  各种数据类型应用和实现方式

下面我们先来逐一的分析下这7种数据类型的使用和内部实现方式:

• String:

Strings 数据结构是简单的key-value类型，value其实不仅是String，也可以是数字.

常用命令:  set,get,decr,incr,mget 等。

应用场景：String是最常用的一种数据类型，普通的key/ value 存储都可以归为此类.即可以完全实现目前 Memcached 的功能，并且效率更高。还可以享受Redis的定时持久化，操作日志及 Replication等功能。除了提供与 Memcached 一样的get、set、incr、decr 等操作外，Redis还提供了下面一些操作：

• 获取字符串长度
• 往字符串append内容
• 设置和获取字符串的某一段内容
• 设置及获取字符串的某一位（bit）
• 批量设置一系列字符串的内容

实现方式：String在redis内部存储默认就是一个字符串，被redisObject所引用，当遇到incr,decr等操作时会转成数值型进行计算，此时redisObject的encoding字段为int。

• Hash

常用命令：hget,hset,hgetall 等。

应用场景：在Memcached中，我们经常将一些结构化的信息打包成HashMap，在客户端序列化后存储为一个字符串的值，比如用户的昵称、年龄、性别、积分等，这时候在需要修改其中某一项时，通常需要将所有值取出反序列化后，修改某一项的值，再序列化存储回去。这样不仅增大了开销，也不适用于一些可能并发操作的场合（比如两个并发的操作都需要修改积分）。而Redis的Hash结构可以使你像在数据库中Update一个属性一样只修改某一项属性值。

        我们简单举个实例来描述下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结构来实现。

Lists 就是链表，相信略有数据结构知识的人都应该能理解其结构。使用Lists结构，我们可以轻松地实现最新消息排行等功能。Lists的另一个应用就是消息队列，
可以利用Lists的PUSH操作，将任务存在Lists中，然后工作线程再用POP操作将任务取出进行执行。Redis还提供了操作Lists中某一段的api，你可以直接查询，删除Lists中某一段的元素。

实现方式：

Redis list的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销，Redis内部的很多实现，包括发送缓冲队列等也都是用的这个数据结构。

• Set

常用命令：

sadd,spop,smembers,sunion 等。

应用场景：

Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。

Sets 集合的概念就是一堆不重复值的组合。利用Redis提供的Sets数据结构，可以存储一些集合性的数据，比如在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。Redis还为集合提供了求交集、并集、差集等操作，可以非常方便的实现如共同关注、共同喜好、二度好友等功能，对上面的所有集合操作，你还可以使用不同的命令选择将结果返回给客户端还是存集到一个新的集合中。

实现方式：

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来存储，这样获取时就是自动按时间排好序的。

另外还可以用Sorted Sets来做带权重的队列，比如普通消息的score为1，重要消息的score为2，然后工作线程可以选择按score的倒序来获取工作任务。让重要的任务优先执行。

实现方式：

Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。

• Pub/Sub

Pub/Sub 从字面上理解就是发布（Publish）与订阅（Subscribe），在Redis中，你可以设定对某一个key值进行消息发布及消息订阅，当一个key值上进行了消息发布后，所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统，比如普通的即时聊天，群聊等功能。

• Transactions

谁说NoSQL都不支持事务，虽然Redis的Transactions提供的并不是严格的ACID的事务（比如一串用EXEC提交执行的命令，在执行中服务器宕机，那么会有一部分命令执行了，剩下的没执行），但是这个Transactions还是提供了基本的命令打包执行的功能（在服务器不出问题的情况下，可以保证一连串的命令是顺序在一起执行的，中间有会有其它客户端命令插进来执行）。Redis还提供了一个Watch功能，你可以对一个key进行Watch，然后再执行Transactions，在这过程中，如果这个Watched的值进行了修改，那么这个Transactions会发现并拒绝执行。

4.  Redis实际应用场景

        Redis在很多方面与其他数据库解决方案不同：它使用内存提供主存储支持，而仅使用硬盘做持久性的存储；它的数据模型非常独特，用的是单线程。另一个大区别在于，你可以在开发环境中使用Redis的功能，但却不需要转到Redis。

转向Redis当然也是可取的，许多开发者从一开始就把Redis作为首选数据库；但设想如果你的开发环境已经搭建好，应用已经在上面运行了，那么更换数据库框架显然不那么容易。另外在一些需要大容量数据集的应用，Redis也并不适合，因为它的数据集不会超过系统可用的内存。所以如果你有大数据应用，而且主要是读取访问模式，那么Redis并不是正确的选择。

        然而我喜欢Redis的一点就是你可以把它融入到你的系统中来，这就能够解决很多问题，比如那些你现有的数据库处理起来感到缓慢的任务。这些你就可以通过Redis来进行优化，或者为应用创建些新的功能。在本文中，我就想探讨一些怎样将Redis加入到现有的环境中，并利用它的原语命令等功能来解决 传统环境中碰到的一些常见问题。在这些例子中，Redis都不是作为首选数据库。

1、显示最新的项目列表

下面这个语句常用来显示最新项目，随着数据多了，查询毫无疑问会越来越慢。

 

SELECT * FROM foo WHERE ... ORDER BY time DESC LIMIT 10

        在Web应用中，“列出最新的回复”之类的查询非常普遍，这通常会带来可扩展性问题。这令人沮丧，因为项目本来就是按这个顺序被创建的，但要输出这个顺序却不得不进行排序操作。

        类似的问题就可以用Redis来解决。比如说，我们的一个Web应用想要列出用户贴出的最新20条评论。在最新的评论边上我们有一个“显示全部”的链接，点击后就可以获得更多的评论。

        我们假设数据库中的每条评论都有一个唯一的递增的ID字段。

        我们可以使用分页来制作主页和评论页，使用Redis的模板，每次新评论发表时，我们会将它的ID添加到一个Redis列表：

 

LPUSH latest.comments <ID>

       我们将列表裁剪为指定长度，因此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数据库（或是硬盘上的其他类型数据库）只是在用户需要获取“很远”的数据时才会被触发，而主页或第一个评论页是不会麻烦到硬盘上的数据库了。

2、删除与过滤

      我们可以使用LREM来删除评论。如果删除操作非常少，另一个选择是直接跳过评论条目的入口，报告说该评论已经不存在。

       有些时候你想要给不同的列表附加上不同的过滤器。如果过滤器的数量受到限制，你可以简单的为每个不同的过滤器使用不同的Redis列表。毕竟每个列表只有5000条项目，但Redis却能够使用非常少的内存来处理几百万条项目。

3、排行榜相关

      另一个很普遍的需求是各种数据库的数据并非存储在内存中，因此在按得分排序以及实时更新这些几乎每秒钟都需要更新的功能上数据库的性能不够理想。

      典型的比如那些在线游戏的排行榜，比如一个Facebook的游戏，根据得分你通常想要：

         - 列出前100名高分选手

         - 列出某用户当前的全球排名

      这些操作对于Redis来说小菜一碟，即使你有几百万个用户，每分钟都会有几百万个新的得分。

      模式是这样的，每次获得新得分时，我们用这样的代码：

      ZADD leaderboard  <score>  <username> 

     你可能用userID来取代username，这取决于你是怎么设计的。

      得到前100名高分用户很简单：ZREVRANGE leaderboard 0 99。

      用户的全球排名也相似，只需要：ZRANK leaderboard <username>。

 

4、按照用户投票和时间排序

      排行榜的一种常见变体模式就像Reddit或Hacker News用的那样，新闻按照类似下面的公式根据得分来排序：

       score = points / time^alpha 

      因此用户的投票会相应的把新闻挖出来，但时间会按照一定的指数将新闻埋下去。下面是我们的模式，当然算法由你决定。

      模式是这样的，开始时先观察那些可能是最新的项目，例如首页上的1000条新闻都是候选者，因此我们先忽视掉其他的，这实现起来很简单。

      每次新的新闻贴上来后，我们将ID添加到列表中，使用LPUSH + LTRIM，确保只取出最新的1000条项目。

      有一项后台任务获取这个列表，并且持续的计算这1000条新闻中每条新闻的最终得分。计算结果由ZADD命令按照新的顺序填充生成列表，老新闻则被清除。这里的关键思路是排序工作是由后台任务来完成的。

 

5、处理过期项目

      另一种常用的项目排序是按照时间排序。我们使用unix时间作为得分即可。

      模式如下：

       - 每次有新项目添加到我们的非Redis数据库时，我们把它加入到排序集合中。这时我们用的是时间属性，current_time和time_to_live。

       - 另一项后台任务使用ZRANGE…SCORES查询排序集合，取出最新的10个项目。如果发现unix时间已经过期，则在数据库中删除条目。

 

6、计数

       Redis是一个很好的计数器，这要感谢INCRBY和其他相似命令。

       我相信你曾许多次想要给数据库加上新的计数器，用来获取统计或显示新信息，但是最后却由于写入敏感而不得不放弃它们。

       好了，现在使用Redis就不需要再担心了。有了原子递增（atomic increment），你可以放心的加上各种计数，用GETSET重置，或者是让它们过期。

       例如这样操作：

         INCR user:<id> EXPIRE 

         user:<id> 60 

       你可以计算出最近用户在页面间停顿不超过60秒的页面浏览量，当计数达到比如20时，就可以显示出某些条幅提示，或是其它你想显示的东西。

7、特定时间内的特定项目

        另一项对于其他数据库很难，但Redis做起来却轻而易举的事就是统计在某段特点时间里有多少特定用户访问了某个特定资源。比如我想要知道某些特定的注册用户或IP地址，他们到底有多少访问了某篇文章。

      每次我获得一次新的页面浏览时我只需要这样做：

       SADD page:day1:<page_id> <user_id> 

      当然你可能想用unix时间替换day1，比如time()-(time()%3600*24)等等。

      想知道特定用户的数量吗？只需要使用SCARD page:day1:<page_id>。

       需要测试某个特定用户是否访问了这个页面？SISMEMBER page:day1:<page_id>。

 

8、实时分析正在发生的情况，用于数据统计与防止垃圾邮件等

        我们只做了几个例子，但如果你研究Redis的命令集，并且组合一下，就能获得大量的实时分析方法，有效而且非常省力。使用Redis原语命令，更容易实施垃圾邮件过滤系统或其他实时跟踪系统。

 

9、Pub/Sub

       Redis的Pub/Sub非常非常简单，运行稳定并且快速。支持模式匹配，能够实时订阅与取消频道。

10、队列

        你应该已经注意到像list push和list pop这样的Redis命令能够很方便的执行队列操作了，但能做的可不止这些：比如Redis还有list pop的变体命令，能够在列表为空时阻塞队列。

       现代的互联网应用大量地使用了消息队列（Messaging）。消息队列不仅被用于系统内部组件之间的通信，同时也被用于系统跟其它服务之间的交互。消息队列的使用可以增加系统的可扩展性、灵活性和用户体验。非基于消息队列的系统，其运行速度取决于系统中最慢的组件的速度（注：短板效应）。而基于消息队列可以将系统中各组件解除耦合，这样系统就不再受最慢组件的束缚，各组件可以异步运行从而得以更快的速度完成各自的工作。

    此外，当服务器处在高并发操作的时候，比如频繁地写入日志文件。可以利用消息队列实现异步处理。从而实现高性能的并发操作。

 

11、缓存

        Redis的缓存部分值得写一篇新文章，我这里只是简单的说一下。Redis能够替代memcached，让你的缓存从只能存储数据变得能够更新数据，因此你不再需要每次都重新生成数据了。

　　

Redis高级特性及应用场景

redis中键的生存时间（expire）

redis中可以使用expire命令设置一个键的生存时间，到时间后redis会自动删除它。

1. 过期时间可以设置为秒或者毫秒精度。
2. 过期时间分辨率总是 1 毫秒。
3. 过期信息被复制和持久化到磁盘，当 Redis 停止时时间仍然在计算 (也就是说 Redis 保存了过期时间)。

expire  设置生存时间（单位/秒）

expire key seconds(秒)

ttl 查看键的剩余生存时间

ttl key

persist 取消生存时间

persist key

expireat [key] unix时间戳1351858600

示例：

EXPIREAT cache 1355292000     # 这个 key 将在 2012.12.12 过期

操作图示：

应用场景：

1. 限时的优惠活动信息
2. 网站数据缓存（对于一些需要定时更新的数据，例如：积分排行榜）
3. 手机验证码
4. 限制网站访客访问频率（例如：1分钟最多访问10次）

redis的事务（transaction）

redis中的事务是一组命令的集合。事务同命令一样都是redis的最小执行单元。一组事务中的命令要么都执行，要么都不执行。(例如：转账)

原理：

先将属于一个事务的命令发送给redis进行缓存，最后再让redis依次执行这些命令。

应用场景：

1. 一组命令必须同时都执行，或者都不执行。
2. 我们想要保证一组命令在执行的过程之中不被其它命令插入。

命令：

multi    //事务开始
.....
exec     //事务结束，开始执行事务中的命令
discard     //放弃事务

错误处理

1：语法错误：致命的错误，事务中的所有命令都不会执行

2：运行错误：不会影响事务中其他命令的执行

Redis 不支持回滚（roll back）

正因为redis不支持回滚功能，才使得redis在事务上可以保持简洁和快速。

watch命令

作用：监控一个或者多个键，当被监控的键值被修改后阻止之后的一个事务的执行。

但是不能保证其它客户端不修改这一键值，所以我们需要在事务执行失败后重新执行事务中的命令。

注意：执行完事务的exec命令之后，watch就会取消对所有键值的监控

unwatch：取消监控

 操作图示：

redis中数据的排序（sort）

sort命令可以对列表类型，集合类型和有序集合类型进行排序。

sort key [desc] [limit offset count]

by 参考键(参考键可以是字符串类型或者是hash类型的某个字段，hash类型的格式为：键名->字段名)

1. 如果参考键中不带*号则不排序
2. 如果某个元素的参考键不存在，则默认参考键的值为0

扩展 get参数

1. get参数的规则和by参数的规则一样
2. get # (返回元素本身的值)

扩展 store参数

使用store 参数可以把sort的排序结果保存到指定的列表中

性能优化

1：尽可能减少待排序键中元素的数量

2：使用limit参数只获取需要的数据

3：如果要排序的数据数量很大，尽可能使用store参数将结果缓存。

 操作图示：

  

“发布/订阅”模式

发布：publish

publish channel message

订阅：subscribe

subscribe channel [.....]

取消订阅：unsubscribe

unsubscribe [channel]

按照规则订阅：psubscribe

psubscribe channel ?

按照规则取消订阅：punsubscribe

注意：使用punsubscribe命令只能退订通过psubscribe 订阅的频道。

操作图示：（订阅频道后，频道每发布一条消息，都能动态显示出来）

订阅：

 发布：

redis任务队列

任务队列：使用lpush和rpop(brpop)可以实现普通的任务队列。

 brpop是列表的阻塞式(blocking)弹出原语。

它是 RPOP命令的阻塞版本，当给定列表内没有任何元素可供弹出的时候，连接将被 BRPOP命令阻塞，直到等待超时或发现可弹出元素为止。

当给定多个 key 参数时，按参数 key 的先后顺序依次检查各个列表，弹出第一个非空列表的尾部元素。

优先级队列：

brpop key1 key2 key3 timeout

操作图示：

redis管道(pipeline)

redis的pipeline(管道)功能在命令行中没有，但是redis是支持管道的，在java的客户端(jedis)中是可以使用的。

测试发现：

1：不使用管道方式，插入1000条数据耗时328毫秒

// 测试不使用管道
public static void testInsert() {
    long currentTimeMillis = System.currentTimeMillis();
    Jedis jedis = new Jedis("192.168.33.130", 6379);
    for (int i = 0; i < 1000; i++) {
        jedis.set("test" + i, "test" + i);
    }
    long endTimeMillis = System.currentTimeMillis();
    System.out.println(endTimeMillis - currentTimeMillis);
}

2：使用管道方式，插入1000条数据耗时37毫秒

// 测试管道
public static void testPip() {
    long currentTimeMillis = System.currentTimeMillis();
    Jedis jedis = new Jedis("192.168.33.130", 6379);
    Pipeline pipelined = jedis.pipelined();
    for (int i = 0; i < 1000; i++) {
        pipelined.set("bb" + i, i + "bb");
    }
    pipelined.sync();
    long endTimeMillis = System.currentTimeMillis();
    System.out.println(endTimeMillis - currentTimeMillis);
}

在插入更多数据的时候，管道的优势更加明显：测试10万条数据的时候，不使用管道要40秒，实用管道378毫秒。

redis持久化（persistence）

redis支持两种方式的持久化，可以单独使用或者结合起来使用。

第一种：RDB方式（redis默认的持久化方式）

第二种：AOF方式

redis持久化之RDB

rdb方式的持久化是通过快照完成的，当符合一定条件时redis会自动将内存中的所有数据执行快照操作并存储到硬盘上。默认存储在dump.rdb文件中。(文件名在配置文件中dbfilename)

redis进行快照的时机（在配置文件redis.conf中）

save 900 1  //表示900秒内至少一个键被更改则进行快照。
save 300 10  //表示300秒内10条被更改则快照
save 60 10000  //60秒内10000条

Redis自动实现快照的过程

1、redis使用fork函数复制一份当前进程的副本(子进程)

2、父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件

3、当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此，一次快照操作完成。

注意：redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。

这就使得我们可以通过定时备份RDB文件来实现redis数据库的备份

RDB文件是经过压缩的二进制文件，占用的空间会小于内存中的数据，更加利于传输。

手动执行save或者bgsave命令让redis执行快照。

两个命令的区别在于，save是由主进程进行快照操作，会阻塞其它请求。bgsave是由redis执行fork函数复制出一个子进程来进行快照操作。

文件修复：

redis-check-dump

rdb的优缺点

优点：由于存储的有数据快照文件，恢复数据很方便。

缺点：会丢失最后一次快照以后更改的所有数据。

redis持久化之AOF

aof方式的持久化是通过日志文件的方式。默认情况下redis没有开启aof，可以通过参数appendonly参数开启。

appendonly yes

aof文件的保存位置和rdb文件的位置相同，都是dir参数设置的，默认的文件名是appendonly.aof，可以通过appendfilename参数修改

appendfilename appendonly.aof

 

redis写命令同步的时机

appendfsync always 每次都会执行
appendfsync everysec 默认 每秒执行一次同步操作（推荐，默认）
appendfsync no不主动进行同步，由操作系统来做，30秒一次

 

aof日志文件重写

auto-aof-rewrite-percentage 100(当目前aof文件大小超过上一次重写时的aof文件大小的百分之多少时会再次进行重写，如果之前没有重写，则以启动时的aof文件大小为依据)
auto-aof-rewrite-min-size 64mb

 

手动执行bgrewriteaof进行重写

重写的过程只和内存中的数据有关，和之前的aof文件无关。

所谓的“重写”其实是一个有歧义的词语， 实际上， AOF 重写并不需要对原有的 AOF 文件进行任何写入和读取， 它针对的是数据库中键的当前值。

文件修复：

redis-check-aof

动态切换redis持久方式，从 RDB 切换到 AOF（支持Redis 2.2及以上）

CONFIG SET appendonly yes
CONFIG SET save ""（可选）

注意：

1、当redis启动时，如果rdb持久化和aof持久化都打开了，那么程序会优先使用aof方式来恢复数据集，因为aof方式所保存的数据通常是最完整的。如果aof文件丢失了，则启动之后数据库内容为空。

2、如果想把正在运行的redis数据库，从RDB切换到AOF，建议先使用动态切换方式，再修改配置文件，重启数据库。(不能自己修改配置文件，重启数据库，否则数据库中数据就为空了。)

redis中的config命令

使用config set可以动态设置参数信息，服务器重启之后就失效了。

config set appendonly yes
config set save "90 1 30 10 60 100"

使用config get可以查看所有可以使用config set命令设置的参数

config get *

使用config rewrite命令对启动 Redis 服务器时所指定的 redis.conf 文件进行改写(Redis 2.8 及以上版本才可以使用)，主要是把使用config set动态指定的命令保存到配置文件中。

config rewrite

注意：config rewrite命令对 redis.conf 文件的重写是原子性的， 并且是一致的： 如果重写出错或重写期间服务器崩溃， 那么重写失败， 原有 redis.conf 文件不会被修改。 如果重写成功， 那么 redis.conf 文件为重写后的新文件。

redis的安全策略

设置数据库密码

修改配置

requirepass password

验证密码

auth password

bind参数（可以让数据库只能在指定IP下访问）

bind 127.0.0.1

命令重命名

修改命令的名称

rename-command flushall cleanall

禁用命令 

rename-command flushall ""

redis工具

redis-cli  命令行

info/monitor(调试命令)

Redisclient（redis数据库可视化工具，不怎么实用）

http://www.oschina.net/news/53391/redisclient-1-0

http://www.oschina.net/news/55634/redisclient-2-0

 

redis info命令

以一种易于解释（parse）且易于阅读的格式，返回关于 Redis 服务器的各种信息和统计数值。

通过给定可选的参数 section ，可以让命令只返回某一部分的信息：

内容过多，详细参考

http://redisdoc.com/server/info.html

redis内存占用情况

测试情况：

100万个键值对（键是0到999999值是字符串“hello world”）在32位操作系统的笔记本上 用了100MB

使用64位的操作系统的话，相对来说占用的内存会多一点，这是因为64位的系统里指针占用了8个字节，但是64位系统也能支持更大的内存，所以运行大型的redis服务还是建议使用64位服务器

Redis实例最多存keys数

理论上Redis可以处理多达2的32次方的keys，并且在实际中进行了测试，每个实例至少存放了2亿5千万的keys

也可以说Redis的存储极限是系统中的可用内存值。

redis优化1

精简键名和键值

键名：尽量精简，但是也不能单纯为了节约空间而使用不易理解的键名。

键值：对于键值的数量固定的话可以使用0和1这样的数字来表示，（例如：male/female、right/wrong）

当业务场景不需要数据持久化时，关闭所有的持久化方式可以获得最佳的性能

内部编码优化（大家可以自己了解）

redis为每种数据类型都提供了两种内部编码方式，在不同的情况下redis会自动调整合适的编码方式。（如图所示）

 

SLOWLOG [get/reset/len]

slowlog-log-slower-than  //它决定要对执行时间大于多少微秒(microsecond，1秒 = 1,000,000 微秒)的命令进行记录
slowlog-max-len   //它决定 slowlog 最多能保存多少条日志

当发现redis性能下降的时候可以查看下是哪些命令导致的

redis优化2

修改linux内核内存分配策略

原因：

redis在运行过程中可能会出现下面问题

错误日志：

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1'

redis在备份数据的时候，会fork出一个子进程，理论上child进程所占用的内存和parent是一样的，比如parent占用的内存为8G，这个时候也要同样分配8G的内存给child,如果内存无法负担，往往会造成redis服务器的down机或者IO负载过高，效率下降。所以内存分配策略应该设置为 1（表示内核允许分配所有的物理内存，而不管当前的内存状态如何）。

内存分配策略有三种

可选值：0、1、2。

0， 表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。

1， 不管需要多少内存，都允许申请。

2， 只允许分配物理内存和交换内存的大小。(交换内存一般是物理内存的一半)

向/etc/sysctl.conf添加

vm.overcommit_memory = 1    //然后重启服务器

或者执行

sysctl vm.overcommit_memory=1   //立即生效

问题图示：

redis优化3

关闭Transparent Huge Pages(THP)

THP会造成内存锁影响redis性能，建议关闭

Transparent HugePages ：用来提高内存管理的性能
Transparent Huge Pages在32位的RHEL 6中是不支持的

使用root用户执行下面命令

echo never > /sys/kernel/mm/transparent_hugepage/enabled

把这条命令添加到这个文件中/etc/rc.local

redis优化4

修改linux中TCP 监听的最大容纳数量

在高并发环境下你需要一个高backlog值来避免慢客户端连接问题。注意Linux内核默默地将这个值减小到/proc/sys/net/core/somaxconn的值，所以需要确认增大somaxconn和tcp_max_syn_backlog两个值来达到想要的效果。

echo 511 > /proc/sys/net/core/somaxconn

注意：这个参数并不是限制redis的最大链接数。如果想限制redis的最大连接数需要修改maxclients，默认最大连接数为10000。

redis优化5

限制redis的内存大小

通过redis的info命令查看内存使用情况

如果不设置maxmemory或者设置为0，64位系统不限制内存，32位系统最多使用3GB内存。

修改配置文件中的maxmemory和maxmemory-policy

maxmemory：最大内存
maxmemory-policy：内存不足时,数据清除策略

如果可以确定数据总量不大，并且内存足够的情况下不需要限制redis使用的内存大小。如果数据量不可预估，并且内存也有限的话，尽量限制下redis使用的内存大小，这样可以避免redis使用swap分区或者出现OOM错误。

注意：如果不限制内存，当物理内存使用完之后，会使用swap分区，这样性能较低，如果限制了内存，当到达指定内存之后就不能添加数据了，否则会报OOM错误。可以设置maxmemory-policy，内存不足时删除数据。

拓展

used_memory是Redis使用的内存总量，它包含了实际缓存占用的内存和Redis自身运行所占用的内存（以字节（byte）为单位，其中used_memory_human上的数据和used_memory是一样的值，它以M为单位显示，仅为了方便阅读）。

如果一个Redis实例的内存使用率超过可用最大内存(used_memory >可用最大内存)，那么操作系统开始进行内存与swap空间交换，把内存中旧的或不再使用的内容写入硬盘上（硬盘上的这块空间叫Swap分区），以便腾出新的物理内存给新页或活动页(page)使用。

在硬盘上进行读写操作要比在内存上进行读写操作，时间上慢了近5个数量级，内存是0.1us(微秒)、而硬盘是10ms(毫秒)。如果Redis进程上发生内存交换，那么Redis和依赖Redis上数据的应用会受到严重的性能影响。 通过查看used_memory指标可知道Redis正在使用的内存情况，如果used_memory>可用最大内存，那就说明Redis实例正在进行内存交换或者已经内存交换完毕。管理员根据这个情况，执行相对应的应急措施。

排查方案：

若是在使用Redis期间没有开启rdb快照或aof持久化策略，那么缓存数据在Redis崩溃时就有丢失的危险。因为当Redis内存使用率超过可用内存的95%时，部分数据开始在内存与swap空间来回交换，这时就可能有丢失数据的危险。

当开启并触发快照功能时，Redis会fork一个子进程把当前内存中的数据完全复制一份写入到硬盘上。因此若是当前使用内存超过可用内存的45%时触发快照功能，那么此时进行的内存交换会变的非常危险(可能会丢失数据)。 倘若在这个时候实例上有大量频繁的更新操作，问题会变得更加严重。

通过减少Redis的内存占用率，来避免这样的问题，或者使用下面的技巧来避免内存交换发生：

1、尽可能的使用Hash数据结构。因为Redis在储存小于100个字段的Hash结构上，其存储效率是非常高的。所以在不需要集合(set)操作或list的push/pop操作的时候，尽可能的使用Hash结构。比如，在一个web应用程序中，需要存储一个对象表示用户信息，使用单个key表示一个用户，其每个属性存储在Hash的字段里，这样要比给每个属性单独设置一个key-value要高效的多。 通常情况下倘若有数据使用string结构，用多个key存储时，那么应该转换成单key多字段的Hash结构。 如上述例子中介绍的Hash结构应包含，单个对象的属性或者单个用户各种各样的资料。Hash结构的操作命令是HSET(key, fields, value)和HGET(key, field)，使用它可以存储或从Hash中取出指定的字段。

2、设置key的过期时间。一个减少内存使用率的简单方法就是，每当存储对象时确保设置key的过期时间。倘若key在明确的时间周期内使用或者旧key不大可能被使用时，就可以用Redis过期时间命令(expire,expireat, pexpire, pexpireat)去设置过期时间，这样Redis会在key过期时自动删除key。 假如你知道每秒钟有多少个新key-value被创建，那可以调整key的存活时间，并指定阀值去限制Redis使用的最大内存。

3、回收key。在Redis配置文件中(一般叫Redis.conf)，通过设置“maxmemory”属性的值可以限制Redis最大使用的内存，修改后重启实例生效。也可以使用客户端命令config set maxmemory 去修改值，这个命令是立即生效的，但会在重启后会失效，需要使用config rewrite命令去刷新配置文件。 若是启用了Redis快照功能，应该设置“maxmemory”值为系统可使用内存的45%，因为快照时需要一倍的内存来复制整个数据集，也就是说如果当前已使用45%，在快照期间会变成95%(45%+45%+5%)，其中5%是预留给其他的开销。 如果没开启快照功能，maxmemory最高能设置为系统可用内存的95%。

当内存使用达到设置的最大阀值时，需要选择一种key的回收策略，可在Redis.conf配置文件中修改“maxmemory-policy”属性值。 若是Redis数据集中的key都设置了过期时间，那么“volatile-ttl”策略是比较好的选择。但如果key在达到最大内存限制时没能够迅速过期，或者根本没有设置过期时间。那么设置为“allkeys-lru”值比较合适，它允许Redis从整个数据集中挑选最近最少使用的key进行删除(LRU淘汰算法)。Redis还提供了一些其他淘汰策略，如下：

volatile-lru： 使用LRU算法从已设置过期时间的数据集合中淘汰数据。
volatile-ttl：从已设置过期时间的数据集合中挑选即将过期的数据淘汰。
volatile-random：从已设置过期时间的数据集合中随机挑选数据淘汰。
allkeys-lru：使用LRU算法从所有数据集合中淘汰数据。
allkeys-random：从数据集合中任意选择数据淘汰
no-enviction：禁止淘汰数据。

通过设置maxmemory为系统可用内存的45%或95%(取决于持久化策略)和设置“maxmemory-policy”为“volatile-ttl”或“allkeys-lru”(取决于过期设置)，可以比较准确的限制Redis最大内存使用率，在绝大多数场景下使用这2种方式可确保Redis不会进行内存交换。倘若你担心由于限制了内存使用率导致丢失数据的话，可以设置noneviction值禁止淘汰数据。

redis优化6

Redis是个单线程模型，客户端过来的命令是按照顺序执行的，所以想要一次添加多条数据的时候可以使用管道，或者使用一次可以添加多条数据的命令，例如：

 

Redis应用场景

 

发布与订阅

在更新中保持用户对数据的映射是系统中的一个普遍任务。Redis的pub/sub功能使用了SUBSCRIBE、UNSUBSCRIBE和PUBLISH命令，让这个变得更加容易。

代码示例：

// 订阅频道数据
public static void testSubscribe() {
    //连接Redis数据库
    Jedis jedis = new Jedis("192.168.33.130", 6379);
    JedisPubSub jedisPubSub = new JedisPubSub() {

        // 当向监听的频道发送数据时，这个方法会被触发
        @Override
        public void onMessage(String channel, String message) {
            System.out.println("收到消息" + message);
            //当收到 "unsubscribe" 消息时，调用取消订阅方法
            if ("unsubscribe".equals(message)) {
                this.unsubscribe();
            }
        }

        // 当取消订阅指定频道的时候，这个方法会被触发
        @Override
        public void onUnsubscribe(String channel, int subscribedChannels) {
            System.out.println("取消订阅频道" + channel);
        }

    };
    // 订阅之后，当前进程一致处于监听状态，当被取消订阅之后，当前进程会结束
    jedis.subscribe(jedisPubSub, "ch1");
}


// 发布频道数据
public static void testPubSub() throws Exception {
    //链接Redis数据库
    Jedis jedis = new Jedis("192.168.33.130", 6379);
    //发布频道 "ch1" 和消息 "hello redis"
    jedis.publish("ch1", "hello redis");
    //关闭连接
    jedis.close();
}

打印结果：

限制网站访客访问频率

进行各种数据统计的用途是非常广泛的，比如想知道什么时候封锁一个IP地址。INCRBY命令让这些变得很容易，通过原子递增保持计数；GETSET用来重置计数器；过期属性expire用来确认一个关键字什么时候应该删除。

代码示例：

//指定Redis数据库连接的IP和端口
String host = "192.168.33.130";
int port = 6379;
Jedis jedis = new Jedis(host, port);

/**
 * 限制网站访客访问频率 一分钟之内最多访问10次
 *
 * @throws Exception
 */
@Test
public void test3() throws Exception {
    // 模拟用户的频繁请求
    for (int i = 0; i < 20; i++) {
        boolean result = testLogin("192.168.1.100");
        if (result) {
            System.out.println("正常访问");
        } else {
            System.err.println("访问受限");
        }
    }

}

/**
 * 判断用户是否可以访问网站
 *
 * @param ip
 * @return
 */
public boolean testLogin(String ip) {
    String value = jedis.get(ip);
    if (value == null) {
        //初始化时设置IP访问次数为1
        jedis.set(ip, "1");
        //设置IP的生存时间为60秒，60秒内IP的访问次数由程序控制
        jedis.expire(ip, 60);
    } else {
        int parseInt = Integer.parseInt(value);
        //如果60秒内IP的访问次数超过10，返回false,实现了超过10次禁止分的功能
        if (parseInt > 10) {
            return false;
        } else {
            //如果没有10次，可以自增
            jedis.incr(ip);
        }
    }
    return true;
}

打印结果：

监控变量在事务执行时是否被修改

代码示例：

// 指定Redis数据库连接的IP和端口
String host = "192.168.33.130";
int port = 6379;
Jedis jedis = new Jedis(host, port);

/**
 * 监控变量a在一段时间内是否被修改，若没有，则执行事务，若被修改，则事务不执行
 *
 * @throws Exception
 */
@Test
public void test4() throws Exception {
    //监控变量a，在事务执行后watch功能也结束
    jedis.watch("a");
    //需要数据库中先有a，并且a的值为字符串数字
    String value = jedis.get("a");
    int parseInt = Integer.parseInt(value);
    parseInt++;
    System.out.println("线程开始休息。。。");
    Thread.sleep(5000);

    //开启事务
    Transaction transaction = jedis.multi();
    transaction.set("a", parseInt + "");
    //执行事务
    List<Object> exec = transaction.exec();
    if (exec == null) {
        System.out.println("事务没有执行.....");
    } else {
        System.out.println("正常执行......");
    }
}

打印结果：

变量a没有被修改时：

 

变量a被修改时：

 

各种计数

商品维度计数（喜欢数，评论数，鉴定数，浏览数,etc）

采用Redis 的类型: Hash. 如果你对redis数据类型不太熟悉，可以参考 http://redis.io/topics/data-types-intro

为product定义个key product:，为每种数值定义hashkey, 譬如喜欢数xihuan

 

用户维度计数（动态数、关注数、粉丝数、喜欢商品数、发帖数 等）

用户维度计数同商品维度计数都采用 Hash. 为User定义个key user:，为每种数值定义hashkey, 譬如关注数follow

  

存储社交关系

譬如将用戶的好友/粉丝/关注，可以存在一个sorted set中，score可以是timestamp，这样求两个人的共同好友的操作，可能就只需要用求交集命令即可。

 

用作缓存代替memcached

缓存内容示例：（商品列表，评论列表，@提示列表，etc）

相对memcached 简单的key-value存储来说，redis众多的数据结构（list,set,sorted set,hash, etc）可以更方便cache各种业务数据，性能也不亚于memcached。

例如：

RPUSH pagewviews.user: EXPIRE pagewviews.user: 60  //注意要update timeout

反spam系统

例如：（评论，发布商品，论坛发贴，etc）

作为一个电商网站被各种spam攻击是少不免（垃圾评论、发布垃圾商品、广告、刷自家商品排名等），针对这些spam制定一系列anti-spam规则，其中有些规则可以利用redis做实时分析，譬如：1分钟评论不得超过2次、5分钟评论少于5次等（更多机制/规则需要结合drools ）。 采用sorted set将最近一天用户操作记录起来（为什么不全部记录？节省memory，全部操作会记录到log，后续利用hadoop进行更全面分析统计），通过

redis> RANGEBYSCORE user:200000:operation:comment 61307510405600 +inf    //获得1分钟内的操作记录
redis> ZADD user:200000:operation:comment 61307510402300 "这是一条评论"  //score 为timestamp (integer) 1
redis> ZRANGEBYSCORE user:200000:operation:comment 61307510405600 +inf   //获得1分钟内的操作记录

打印结果：

1) "这是一条评论"

用户Timeline/Feeds

在逛有个类似微博的栏目我关注，里面包括关注的人、主题、品牌的动态。redis在这边主要当作cache使用。

 

最新列表&排行榜

这里采用Redis的List数据结构或sorted set 结构, 方便实现最新列表or排行榜 等业务场景。

消息通知

其实这业务场景也可以算在计数上，也是采用Hash。如下：

 

消息队列

当在集群环境时候，java ConcurrentLinkedQueue 就无法满足我们需求，此时可以采用Redis的List数据结构实现分布式的消息队列。

显示最新的项目列表

Redis使用的是常驻内存的缓存，速度非常快。LPUSH用来插入一个内容ID，作为关键字存储在列表头部。LTRIM用来限制列表中的项目数最多为5000。如果用户需要的检索的数据量超越这个缓存容量，这时才需要把请求发送到数据库。

删除和过滤。

如果一篇文章被删除，可以使用LREM从缓存中彻底清除掉。

排行榜及相关问题

排行榜（leader board）按照得分进行排序。ZADD命令可以直接实现这个功能，而ZREVRANGE命令可以用来按照得分来获取前100名的用户，ZRANK可以用来获取用户排名，非常直接而且操作容易。

按照用户投票和时间排序

这就像Reddit的排行榜，得分会随着时间变化。LPUSH和LTRIM命令结合运用，把文章添加到一个列表中。一项后台任务用来获取列表，并重新计算列表的排序，ZADD命令用来按照新的顺序填充生成列表。列表可以实现非常快速的检索，即使是负载很重的站点。

过期项目处理

使用unix时间作为关键字，用来保持列表能够按时间排序。对current_time和time_to_live进行检索，完成查找过期项目的艰巨任务。另一项后台任务使用ZRANGE...WITHSCORES进行查询，删除过期的条目。

特定时间内的特定项目

这是特定访问者的问题，可以通过给每次页面浏览使用SADD命令来解决。SADD不会将已经存在的成员添加到一个集合。

实时分析

使用Redis原语命令，更容易实施垃圾邮件过滤系统或其他实时跟踪系统。

队列

在当前的编程中队列随处可见。除了push和pop类型的命令之外，Redis还有阻塞队列的命令，能够让一个程序在执行时被另一个程序添加到队列。你也可以做些更有趣的事情，比如一个旋转更新的RSS feed队列。

缓存

Redis缓存使用的方式与memcache相同。

网络应用不能无休止地进行模型的战争，看看这些Redis的原语命令，尽管简单但功能强大，把它们加以组合，所能完成的就更无法想象。当然，你可以专门编写代码来完成所有这些操作，但Redis实现起来显然更为轻松。

手机验证码

使用expire设置验证码失效时间

redis既可以作为数据库来用，也可以作为缓存系统来用

Redis过期策略

本文对Redis的过期机制简单的讲解一下
　　讲解之前我们先抛出一个问题，我们知道很多时候服务器经常会用到redis作为缓存，有很多数据都是临时缓存一下，可能用过之后很久都不会再用到了（比如暂存session，又或者只存放日行情股票数据）那么就会出现一下几个问题了

1. Redis会自己回收清理不用的数据吗？
2. 如果能，那如何配置？
3. 如果不能，如何防止数据累加后大量占用存储空间的问题？

　　之前一直接触Redis不是很深入，最近项目当中遇到一个需求场景，需要清空一些存放在Redis的数据，主要是通过一些时间进行过滤，删除那些不满足的数据，但是这样的工作每天都需要进行，那工作量就比较大了，而且每天都需要按时去手动清理，这样做也不切实际，后面发现Redis中有个设置时间过期的功能，即对存储在Redis数据库中的值可以设置一个过期时间。作为一个缓存数据库，这是非常实用的。这就是我们本文要讲到的Redis过期机制。其实这个机制运用的场景十分广泛，比如我们一般项目中的token或者一些登录信息，尤其是短信验证码都是有时间限制的，或者是限制请求次数，如果按照传统的数据库处理方式，一般都是自己判断过期，这样无疑会严重影响项目性能。

一、设置过期时间

　　Redis对存储值的过期处理实际上是针对该值的键（key）处理的，即时间的设置也是设置key的有效时间。Expires字典保存了所有键的过期时间，Expires也被称为过期字段。

• expire key time(以秒为单位)--这是最常用的方式
• setex(String key, int seconds, String value)--字符串独有的方式

注：
　　1、除了字符串自己独有设置过期时间的方法外，其他方法都需要依靠expire方法来设置时间
　　2、如果没有设置时间，那缓存就是永不过期
　　3、如果设置了过期时间，之后又想让缓存永不过期，使用persist key

1、常用方式

一般主要包括4种处理过期方，其中expire都是以秒为单位，pexpire都是以毫秒为单位的。

1 EXPIRE key seconds　　//将key的生存时间设置为ttl秒
2 PEXPIRE key milliseconds　　//将key的生成时间设置为ttl毫秒
3 EXPIREAT key timestamp　　//将key的过期时间设置为timestamp所代表的的秒数的时间戳
4 PEXPIREAT key milliseconds-timestamp　　//将key的过期时间设置为timestamp所代表的的毫秒数的时间戳

备注：timestamp为unix时间戳（例如：timestamp=1499788800 表示将在2017.07.12过期）
1、2两种方式是设置一个过期的时间段，就是咱们处理验证码最常用的策略，设置三分钟或五分钟后失效，把分钟数转换成秒或毫秒存储到Redis中。 
3、4两种方式是指定一个过期的时间 ，比如优惠券的过期时间是某年某月某日，只是单位不一样。

下面我们就以EXPIREAT为例子简单讲解下用法。

返回值

一个整数值1或0，如下：

• 如果成功地为该键设置了超时时间，返回 1
• 如果键不存在或无法设置超时时间，返回 0

语法
以下是以Redis的EXPIREAT命令的基本语法。

1 redis 127.0.0.1:6379> Expireat KEY_NAME TIME_IN_UNIX_TIMESTAMP

示例

首先，在Redis中创建一个键：akey，并在akey中设置一些值。

1 redis 127.0.0.1:6379> SET akey redis 
2 OK

现在，为设置创建的键设置超时时间为60 秒。

 1 127.0.0.1:6379> SET akey redis
 2 OK
 3 127.0.0.1:6379> EXPIREAT akey 1393840000
 4 (integer) 1
 5 127.0.0.1:6379> EXISTS akey
 6 (integer) 0
 7 127.0.0.1:6379> SET akey redis
 8 OK
 9 127.0.0.1:6379> EXPIREAT akey 1493840000
10 (integer) 1
11 127.0.0.1:6379> EXISTS akey
12 (integer) 1

其他三个用法类似，这里不逐一阐述

2、字符串独有方式

对字符串特殊处理的方式为SETEX命令，SETEX命令为指定的 key 设置值及其过期时间。如果 key 已经存在， SETEX 命令将会替换旧的值。

返回值

设置成功时返回 OK 。

语法

Redis Setex 命令基本语法如下：

redis 127.0.0.1:6379> SETEX KEY_NAME TIMEOUT VALUE

示例

1 redis 127.0.0.1:6379> SETEX mykey 60 redis
2 OK
3 redis 127.0.0.1:6379> TTL mykey
4 60
5 redis 127.0.0.1:6379> GET mykey
6 "redis

二、3种过期策略

• 定时删除
  • 含义：在设置key的过期时间的同时，为该key创建一个定时器，让定时器在key的过期时间来临时，对key进行删除
  • 优点：保证内存被尽快释放
  • 缺点：
    • 若过期key很多，删除这些key会占用很多的CPU时间，在CPU时间紧张的情况下，CPU不能把所有的时间用来做要紧的事儿，还需要去花时间删除这些key
    • 定时器的创建耗时，若为每一个设置过期时间的key创建一个定时器（将会有大量的定时器产生），性能影响严重
    • 没人用
• 惰性删除
  • 含义：key过期的时候不删除，每次从数据库获取key的时候去检查是否过期，若过期，则删除，返回null。
  • 优点：删除操作只发生在从数据库取出key的时候发生，而且只删除当前key，所以对CPU时间的占用是比较少的，而且此时的删除是已经到了非做不可的地步（如果此时还不删除的话，我们就会获取到了已经过期的key了）
  • 缺点：若大量的key在超出超时时间后，很久一段时间内，都没有被获取过，那么可能发生内存泄露（无用的垃圾占用了大量的内存）
• 定期删除
  • 含义：每隔一段时间执行一次删除(在redis.conf配置文件设置hz，1s刷新的频率)过期key操作
  • 优点：
    • 通过限制删除操作的时长和频率，来减少删除操作对CPU时间的占用--处理"定时删除"的缺点
    • 定期删除过期key--处理"惰性删除"的缺点
  • 缺点
    • 在内存友好方面，不如"定时删除"
    • 在CPU时间友好方面，不如"惰性删除"
  • 难点
    • 合理设置删除操作的执行时长（每次删除执行多长时间）和执行频率（每隔多长时间做一次删除）（这个要根据服务器运行情况来定了）

看完上面三种策略后可以得出以下结论： 
定时删除和定期删除为主动删除：Redis会定期主动淘汰一批已过去的key

惰性删除为被动删除：用到的时候才会去检验key是不是已过期，过期就删除

惰性删除为redis服务器内置策略

定期删除可以通过：

• 第一、配置redis.conf 的hz选项，默认为10 （即1秒执行10次，100ms一次，值越大说明刷新频率越快，最Redis性能损耗也越大） 
• 第二、配置redis.conf的maxmemory最大值，当已用内存超过maxmemory限定时，就会触发主动清理策略

 注意：

• 上边所说的数据库指的是内存数据库，默认情况下每一台redis服务器有16个数据库（关于数据库的设置，看下边代码），默认使用0号数据库，所有的操作都是对0号数据库的操作，关于redis数据库的存储结构，查看 第八章 Redis数据库结构与读写原理

# 设置数据库数量。默认为16个库，默认使用DB 0，可以使用"select 1"来选择一号数据库
# 注意：由于默认使用0号数据库，那么我们所做的所有的缓存操作都存在0号数据库上，
# 当你在1号数据库上去查找的时候，就查不到之前set过得缓存
# 若想将0号数据库上的缓存移动到1号数据库，可以使用"move key 1"
databases 16

• memcached只是用了惰性删除，而Redis同时使用了惰性删除与定期删除，这也是二者的一个不同点（可以看做是redis优于memcached的一点）
• 对于惰性删除而言，并不是只有获取key的时候才会检查key是否过期，在某些设置key的方法上也会检查（eg.setnx key2 value2：该方法类似于memcached的add方法，如果设置的key2已经存在，那么该方法返回false，什么都不做；如果设置的key2不存在，那么该方法设置缓存key2-value2。假设调用此方法的时候，发现redis中已经存在了key2，但是该key2已经过期了，如果此时不执行删除操作的话，setnx方法将会直接返回false，也就是说此时并没有重新设置key2-value2成功，所以对于一定要在setnx执行之前，对key2进行过期检查）

三、Redis采用的过期策略

惰性删除+定期删除

• 惰性删除流程
  • 在进行get或setnx等操作时，先检查key是否过期，
  • 若过期，删除key，然后执行相应操作；
  • 若没过期，直接执行相应操作
• 定期删除流程（简单而言，对指定个数个库的每一个库随机删除小于等于指定个数个过期key）
  • 遍历每个数据库（就是redis.conf中配置的"database"数量，默认为16）
    • 检查当前库中的指定个数个key（默认是每个库检查20个key，注意相当于该循环执行20次，循环体时下边的描述）
      • 如果当前库中没有一个key设置了过期时间，直接执行下一个库的遍历
      • 随机获取一个设置了过期时间的key，检查该key是否过期，如果过期，删除key
      • 判断定期删除操作是否已经达到指定时长，若已经达到，直接退出定期删除。

四、RDB对过期key的处理

过期key对RDB没有任何影响

• 从内存数据库持久化数据到RDB文件
  • 持久化key之前，会检查是否过期，过期的key不进入RDB文件
• 从RDB文件恢复数据到内存数据库
  • 数据载入数据库之前，会对key先进行过期检查，如果过期，不导入数据库（主库情况）

五、AOF对过期key的处理

过期key对AOF没有任何影响

• 从内存数据库持久化数据到AOF文件：
  • 当key过期后，还没有被删除，此时进行执行持久化操作（该key是不会进入aof文件的，因为没有发生修改命令）
  • 当key过期后，在发生删除操作时，程序会向aof文件追加一条del命令（在将来的以aof文件恢复数据的时候该过期的键就会被删掉）
• AOF重写

              重写时，会先判断key是否过期，已过期的key不会重写到aof文件                       




　

Redis事件与事务

一、Redis特点

• 特性：速度快、基于键值对的数据结构服务器、功能丰富、简单稳定、客户端语言多、持久化、主从复制、支持高可用和分布式
• 单线程架构：redis使用单线程架构和I/O多路复用模型来实现高性能的内存数据库服务。一条命令从客户端到服务端不会立刻被执行，所有命令都会进入一个队列中，然后逐个被执行。（执行顺序不确定的）。

   单线程如何满足线上运行速度？ 

• 纯内存访问：所有数据放在内存中，响应时长大约100纳秒。 
• 非阻塞I/O，使用epoll作为I/O多路复用技术的实现，再加上Redis自身的事件处理模型将poll中的连接、读写、关闭都转换为事件，不在网络I/O上浪费过多的时间。
• 单线程避免了线程切换和竞态产生的消耗。

二、事件

Redis服务器是一个事件驱动程序。处理以下两类事件：

• 文件事件：Redis服务器通过套接字与客户端进行连接，文件事件就是服务器对套接字操作的抽象。
• 时间事件：服务器对定时操作的抽象。

1.文件事件

Redis 基于Reactor模式开发了自己的网络事件处理器即文件事件处理器

文件事件处理器使用I/O多路复用程序来同时监听多个套接字，并根据套接字目前执行的任务来为套接字关联不同的事务处理器。

当被监听的套接字准备好执行连接应答、读取、写入、关闭等操作时，与操作相对应的文件事件就会产生，这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。

• 文件事件处理器 由四个部分组成：套接字、I/O多路复用程序、文件事件分派器以及事件处理器 I/O多路复用程序总是会将所有产生事件的套接字放到一个队列里面，然后通过这个队列以有序、同步、每次一个套接字的方式向文件事件分派器传送套接字。当上一个套接字产生的事件被处理完毕之后，I/O多路复用程序才会继续向文件事件分派器传送下一个套接字。

• I/O多路复用程序 I/O多路复用程序的功能是通过包装常见的select、epoll、evport和kqueue这些I/O多路复用函数库来实现的。

  2.时间事件

  • 分类
    • 定时事件：指定时间执行一次。
    • 周期性事件：每隔一段时间执行一次。

  目前Redis只使用周期性事件，而没有使用定时事件。 一个事件时间主要由三个属性组成：

  1）id：服务器为时间事件创建的全局唯一ID

  2） when：毫秒精度的UNIX时间戳，记录了时间事件的到达时间

  3） timeProc：时间事件处理器，一个函数

  • 实现 服务器将所有时间事件都放在一个无序链表中，每当时间事件执行器运行时，遍历整个链表，查找所有已到达的时间事件，并调用相应的事件处理器。（该链表为无序链表，不按when属性的大小排序）

 

Redis事务

Redis通过 MULTI 、 EXEC 、 WATCH 等命令来实现事务功能。事务提供了一种将多个命令请求打包，然后一次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求，它会将事务中的所有命令都执行完毕，然后才去处理其他客户端的命令请求。

1.事务的实现

下面给了一个事务的简单例子：

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set "name" "wangjia06"
QUEUED
127.0.0.1:6379> get "name"
QUEUED
127.0.0.1:6379> set "company" "dianping"
QUEUED
127.0.0.1:6379> get "company"
QUEUED
127.0.0.1:6379> set age 28
QUEUED
127.0.0.1:6379> get age
QUEUED
127.0.0.1:6379> exec
1) OK
2) "wangjia06"
3) OK
4) "dianping"
5) OK
6) "28"

退出一个事务可以用 MULTI 命令, 此时再执行事务会报错：

127.0.0.1:6379> multi
OK
127.0.0.1:6379> get "company"
QUEUED
127.0.0.1:6379> get "age"
QUEUED
127.0.0.1:6379> discard
OK
127.0.0.1:6379> exec
(error) ERR EXEC without MULTI

一个事务包括三个步骤：

• 事务开始：事务以 MULTI 开始，返回OK命令。
• 命令入队：每个事务命令成功进入队列后，返回 QUEUED 。
• 事务执行： EXEC 执行事务。

Redis事务内会遇到两种错误：

• 队列入队不成功：语法错误，错误的命令名字或者一些重要的条件如OOM条件。这种客户端会进行校验，如果入队成功则返回QUEUED ，否则返回错误。如果一个命令入队失败，大多数客户端会终止该事务。

127.0.0.1:6379> get name
"wangjia08"
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name "wangjia09"
QUEUED
127.0.0.1:6379> get
(error) ERR wrong number of arguments for 'get' command
127.0.0.1:6379> get name
QUEUED
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379>

• 命令执行时报错：如对一个String值进行列表操作。所有其他的命令会被正常执行即使在事务执行中一些命令失败。

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set sex man
QUEUED
127.0.0.1:6379> lpop sex
QUEUED
127.0.0.1:6379> exec
1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
127.0.0.1:6379> get sex
"man"
127.0.0.1:6379>

Redis不支持事务回滚功能，原因大概有两点：

• 一个redis命令执行失败，一般是语法错误或者应该在开发阶段被检测出来，而不是在生产环境。
• redis追求简单、速度快，所以不提供事务回滚功能.

2.WATCH命令的实现

watch 命令给redis事务提供了一个 CAS 功能。它是一个乐观锁，检查被监视的健是否至少有一个已经被修改过了，如果是的话拒绝执行，并返回nil代表执行失败。

如下面例子，在一个客户端开启事务前对键“name”进行监视，若在这个事务执行前，另一个客户端修改了键“name”的值，之后事务执行后就会报nil。

127.0.0.1:6379> watch "name"
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set age 10
QUEUED
127.0.0.1:6379> get "name"
QUEUED
127.0.0.1:6379> exec
(nil)

127.0.0.1:6379> set "name" "wangjia08"
OK

watch 命令监视多个键：

127.0.0.1:6379> watch "name" "age"
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> get "name"
QUEUED
127.0.0.1:6379> get "age"
QUEUED
127.0.0.1:6379> exec
(nil)
127.0.0.1:6379>

127.0.0.1:6379> set "age" 11
OK

3.事务的ACID性质

• 原子性：redis事务多个操作当做一个整体来执行，要么执行事务中的所有操作，要么一个也不执行。
• 一致性：“一致”指的是数据符合数据库本身的定义和要求，没有包含非法的或无效的错误数据
  • 入队错误：服务器拒绝执行该事务。
  • 执行错误：出错的命令会被服务器识别出来，并进行相应的错误处理，不会对数据库做任何修改，也不会对数据一致性造成影响。
  • 服务器停机： RDB 、 AOF 还原数据库状态
• 隔离性：单线程执行事务，且服务器保证事务期间不会对事务进行中断
• 持久性：当一个事务执行完毕时，执行这个事务所得的结果已经被保存到永久性存储介质（比如硬盘）里面了。Redis事务的持久性由Redis所使用的持久化模式决定（无持久化模式、 RDB 、 AOF ）。Redis工作在无持久化模式下时，事务无持久性。在 AOF 模式下 appenfsync 为 no 时，事务也无持久性

　

 

 

Redis数据淘汰策略

在 redis 中，允许用户设置最大使用内存大小 server.maxmemory，在内存限定的情况下是很有用的。譬如，在一台 8G 机子上部署了 4 个 redis 服务点，每一个服务点分配 1.5G 的内存大小，减少内存紧张的情况，由此获取更为稳健的服务。 
　　redis中当内存超过限制时，按照配置的策略，淘汰掉相应的kv，使得内存可以继续留有足够的空间保存新的数据。redis 确定驱逐某个键值对后，会删除这个数据，并将这个数据变更消息发布到本地（AOF 持久化）和从机（主从连接）。

redis 提供 6种数据淘汰策略：

1. volatile-lru:从设置了过期时间的数据集中，选择最近最久未使用的数据释放；
2. allkeys-lru:从数据集中(包括设置过期时间以及未设置过期时间的数据集中)，选择最近最久未使用的数据释放；
3. volatile-random:从设置了过期时间的数据集中，随机选择一个数据进行释放；
4. allkeys-random:从数据集中(包括了设置过期时间以及未设置过期时间)随机选择一个数据进行入释放；
5. volatile-ttl：从设置了过期时间的数据集中，选择马上就要过期的数据进行释放操作；

6. noeviction：不删除任意数据(但redis还会根据引用计数器进行释放),这时如果内存不够时，会直接返回错误。

   　　默认的内存策略是noeviction，在Redis中LRU算法是一个近似算法，默认情况下，Redis随机挑选5个键，并且从中选取一个最近最久未使用的key进行淘汰，在配置文件中可以通过maxmemory-samples的值来设置redis需要检查key的个数,但是栓查的越多，耗费的时间也就越久,但是结构越精确(也就是Redis从内存中淘汰的对象未使用的时间也就越久~),设置多少，综合权衡。

LRU 数据淘汰机制是这样的：　　

在数据集中随机挑选几个键值对，取出其中 lru 最小的键值对淘汰。所以，你会发现，redis 
并不是保证取得所有数据集中最近最少使用（LRU）的键值对，而只是随机挑选的几个键值对中的。

　

TTL 数据淘汰机制是这样的：　　

从过期时间的表中随机挑选几个键值对，取出其中 ttl 最大的键值对淘汰。同样你会发现，redis 
并不是保证取得所有过期时间的表中最快过期的键值对，而只是随机挑选的几个键值对中的。

　　　

 

 

Redis的并发竞争问题如何解决

Redis的并发竞争问题，主要是发生在并发写竞争。

考虑到redis没有像db中的sql语句，update val = val + 10 where ...，无法使用这种方式进行对数据的更新。

假如有某个key = "price"，  value值为10，现在想把value值进行+10操作。正常逻辑下，就是先把数据key为price的值读回来，加上10，再把值给设置回去。如果只有一个连接的情况下，这种方式没有问题，可以工作得很好，但如果有两个连接时，两个连接同时想对还price进行+10操作，就可能会出现问题了。

例如：两个连接同时对price进行写操作，同时加10，最终结果我们知道，应该为30才是正确。

考虑到一种情况：

T1时刻，连接1将price读出，目标设置的数据为10+10 = 20。

T2时刻，连接2也将数据读出，也是为10，目标设置为20。

T3时刻，连接1将price设置为20。

T4时刻，连接2也将price设置为20，则最终结果是一个错误值20。

如何解决？

方案一：可以使用独占锁的方式，类似操作系统的mutex机制。（网上有例子，http://blog.csdn.net/black_ox/article/details/48972085 不过实现相对复杂，成本较高）

方案二：使用乐观锁的方式进行解决（成本较低，非阻塞，性能较高）

如何用乐观锁方式进行解决？

本质上是假设不会进行冲突，使用redis的命令watch进行构造条件。伪代码如下：

watch price

get price $price

$price = $price + 10

multi

set price $price

exec

解释一下：

watch这里表示监控该key值，后面的事务是有条件的执行，如果从watch的exec语句执行时，watch的key对应的value值被修改了，则事务不会执行。

同样考虑刚刚的场景，

T1时刻，连接1对price进行watch，读出price值为10，目标计算为20；

T2时刻，连接2对price进行watch，读出price值为10，目标计算为20；

T3时刻，连接2将目标值为20写到redis中，执行事务，事务返回成功。

T4时刻，连接1也对price进行写操作，执行事务时，由于之前已经watch了price，price在T1至T4之间已经被修改过了，所以事务执行失败。

综上，该乐观锁机制可以简单明了的解决了写冲突的问题。

又问：如果多个写操作同时过来，100个写操作同时watch，则最终只会有一个成功，99个执行失败，何解？

如果同时进行有多个请求进行写操作，例如同一时刻有100个请求过来，那么只会有一个最终成功，其余99个全部会失败，效率不高。

而且从业务层面，有些是不可接受的场景。例如：大家同时去抢一个红包，如果背后也是用乐观锁的机制去处理，那每个请求后都只有一个人成功打开红包，这对业务是不可忍受的。

在这种情况下，如果想让总体效率最大化，可以采用排队的机制进行。

将所有需要对同一个key的请求进行入队操作，然后用一个消费者线程从队头依次读出请求，并对相应的key进行操作。

这样对于同一个key的所有请求就都是顺序访问，正常逻辑下则不会有写失败的情况下产生 。从而最大化写逻辑的总体效率。

Redis 并发, 锁, 竞争锁问题

Redis并发问题

Redis为单进程单线程模式，采用队列模式将并发访问变为串行访问。Redis本身没有锁的概念，Redis对于多个客户端连接并不存在竞争，但是在Jedis客户端对Redis进行并发访问时会发生连接超时、数据转换错误、阻塞、客户端关闭连接等问题，这些问题均是由于客户端连接混乱造成。对此有2种解决方法：

1.客户端角度，为保证每个客户端间正常有序与Redis进行通信，对连接进行池化，同时对客户端读写Redis操作采用内部锁synchronized。

2.服务器角度，利用setnx实现锁。

对于第一种，需要应用程序自己处理资源的同步，可以使用的方法比较通俗，可以使用synchronized也可以使用lock；第二种需要用到Redis的setnx命令，但是需要注意一些问题。

SETNX命令（SET if Not eXists）

语法：

SETNX key value

功能：
将 key 的值设为 value ，当且仅当 key 不存在；若给定的 key 已经存在，则 SETNX 不做任何动作。

时间复杂度：
O(1)
返回值：
设置成功，返回 1 。
设置失败，返回 0 。

模式：将 SETNX 用于加锁(locking)

SETNX 可以用作加锁原语(locking primitive)。比如说，要对关键字(key) foo 加锁，客户端可以尝试以下方式：

SETNX lock.foo <current Unix time + lock timeout + 1>

如果 SETNX 返回 1 ，说明客户端已经获得了锁， key 设置的unix时间则指定了锁失效的时间。之后客户端可以通过 DEL lock.foo 来释放锁。

如果 SETNX 返回 0 ，说明 key 已经被其他客户端上锁了。如果锁是非阻塞(non blocking lock)的，我们可以选择返回调用，或者进入一个重试循环，直到成功获得锁或重试超时(timeout)。

但是已经证实仅仅使用SETNX加锁带有竞争条件，在特定的情况下会造成错误。

处理死锁(deadlock)

上面的锁算法有一个问题：如果因为客户端失败、崩溃或其他原因导致没有办法释放锁的话，怎么办？

这种状况可以通过检测发现——因为上锁的 key 保存的是 unix 时间戳，假如 key 值的时间戳小于当前的时间戳，表示锁已经不再有效。

但是，当有多个客户端同时检测一个锁是否过期并尝试释放它的时候，我们不能简单粗暴地删除死锁的 key ，再用 SETNX 上锁，因为这时竞争条件(race condition)已经形成了：

C1 和 C2 读取 lock.foo 并检查时间戳， SETNX 都返回 0 ，因为它已经被 C3 锁上了，但 C3 在上锁之后就崩溃(crashed)了。
C1 向 lock.foo 发送 DEL 命令。
C1 向 lock.foo 发送 SETNX 并成功。
C2 向 lock.foo 发送 DEL 命令。
C2 向 lock.foo 发送 SETNX 并成功。
出错：因为竞争条件的关系，C1 和 C2 两个都获得了锁。


幸好，以下算法可以避免以上问题。来看看我们聪明的 C4 客户端怎么办：

C4 向 lock.foo 发送 SETNX 命令。
因为崩溃掉的 C3 还锁着 lock.foo ，所以 Redis 向 C4 返回 0 。
C4 向 lock.foo 发送 GET 命令，查看 lock.foo 的锁是否过期。如果不，则休眠(sleep)一段时间，并在之后重试。
另一方面，如果 lock.foo 内的 unix 时间戳比当前时间戳老，C4 执行以下命令：
GETSET lock.foo <current Unix timestamp + lock timeout + 1>

因为 GETSET 的作用，C4 可以检查看 GETSET 的返回值，确定 lock.foo 之前储存的旧值仍是那个过期时间戳，如果是的话，那么 C4 获得锁。
如果其他客户端，比如 C5，比 C4 更快地执行了 GETSET 操作并获得锁，那么 C4 的 GETSET 操作返回的就是一个未过期的时间戳(C5 设置的时间戳)。C4 只好从第一步开始重试。
注意，即便 C4 的 GETSET 操作对 key 进行了修改，这对未来也没什么影响。

这里假设锁key对应的value没有实际业务意义，否则会有问题，而且其实其value也确实不应该用在业务中。

为了让这个加锁算法更健壮，获得锁的客户端应该常常检查过期时间以免锁因诸如 DEL 等命令的执行而被意外解开，因为客户端失败的情况非常复杂，不仅仅是崩溃这么简单，还可能是客户端因为某些操作被阻塞了相当长时间，紧接着 DEL 命令被尝试执行(但这时锁却在另外的客户端手上)。

GETSET命令

语法：

GETSET key value

功能：
将给定 key 的值设为 value ，并返回 key 的旧值(old value)。当 key 存在但不是字符串类型时，返回一个错误。

时间复杂度：
O(1)

返回值：
返回给定 key 的旧值；当 key 没有旧值时，也即是， key 不存在时，返回 nil 。

 

 

 

Redis的字典(dict)rehash过程解析

Redis的内存存储结构是个大的字典存储，也就是我们通常说的哈希表。Redis小到可以存储几万记录的CACHE,大到可以存储几千万甚至上亿的记录（看内存而定），这充分说明Redis作为缓冲的强大。Redis的核心数据结构就是字典(dict),dict在数据量不断增大的过程中，会遇到HASH(key)碰撞的问题，如果DICT不够大，碰撞的概率增大，这样单个hash 桶存储的元素会越来愈多，查询效率就会变慢。如果数据量从几千万变成几万，不断减小的过程，DICT内存却会造成不必要的浪费。Redis的dict在设计的过程中充分考虑了dict自动扩大和收缩，实现了一个称之为rehash的过程。使dict出发rehash的条件有两个:

1）总的元素个数 除 DICT桶的个数得到每个桶平均存储的元素个数(pre_num),如果 pre_num > dict_force_resize_ratio,就会触发dict 扩大操作。dict_force_resize_ratio = 5。

2）在总元素 * 10 < 桶的个数，也就是,填充率必须<10%, DICT便会进行收缩，让total / bk_num 接近 1:1。

总结，Redis的rehash动作是一个内存管理和数据管理的一个核心操作，由于Redis主要使用单线程做数据管理和消息效应，它的rehash数据迁移过程采用的是渐进式的数据迁移模式，这样做是为了防止rehash过程太长堵塞数据处理线程。并没有采用memcached的多线程迁移模式。关于memcached的rehash过程，以后再做介绍。从redis的rehash过程设计的很巧，也很优雅。在这里值得注意的是，redis在find数据的时候，是同时查找正在迁移的ht[0]和被迁移的ht[1]。防止迁移过程数据命不中的问题。