Redis基础

随着用户量的增加，服务端CPU压力和内存压力增加，故需要引入多台服务器，并使用负载均衡将请求均摊至各台服务器，而这就出现了session的共享问题，缓存数据库的存在解决了这个问题。

解决方法：

1. 存在cookie里：不安全、网络负担导致效率低
2. 存在文件服务器或者数据库里：大量的IO效率问题
3. session复制：session数据冗余，节点越多浪费越大
4. 缓存数据库：完全在内存中，速度快，数据结构简单

随着用户量的增加，数据库IO压力增加，为了提高性能，可以使用水平切分、垂直切分、读写分离等方式，然而这些方式破坏了一定的业务逻辑，缓存数据库的存在减少了io的读操作，在不破坏业务逻辑的情况下提高了性能。

一、NoSQL数据库的特点

1、概述

NoSQL(Not Only SQL)，泛指非关系型数据库。NoSQL不依赖业务逻辑方式存储，而以简单的Key-Value模式存储，因此大大增加了数据库的扩展能力。

• 不遵循SQL标准
• 不支持ACID
• 远超于SQL的性能

2、适用场景

• 对数据高并发的读写
• 海量数据的读写
• 对数据高可扩展性的

3、不适用场景

• 需要事务支持
• 基于SQL的结构化查询存储，处理复杂的关系，需要即席查询

二、Redis概述

1、概述

Redis是一个开源的key-value存储系统。和Memcache类似，它支持存储的value数据类型相对更多，包括string、list、set、zset(有序集合)和hash，这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而这些操作都是原子性的。

在此基础上，Redis支持各种不同方式的排序。

与Mencache一样，为了保证效率，数据都是缓存在内存中。区别是Redis会周期性的把更新的数据写入磁盘或者把修改操作追加的记录文件。并在此基础上实现了master-slave(主从)同步

2、功能

• 最新N个数据：通过list按自然时间排序的数据
• 排行榜，top N：利用zset(有序集合)
• 时效性的数据，比如手机验证码：Expire过期
• 计数器、秒杀：原子性、自增方法INCR、DECR
• 去除大量数据中的重复数据：利用set集合
• 构建队列：利用list集合
• 发布订阅消息系统：pub/sub模

3、底层

区别于Memcache使用多线程+锁，效率更高。

三、Redis数据类型

1、Redis键（Key）

• keys*：查看当前库(默认为0号库，有0-15号库)中的所有key
• exits key：判断key是否存在
• type key：查看key的类型
• del key：删除指定key
• unlink key：根据value选择非阻塞删除（仅将keys从keyspace元数据中删除，真正的删除会在后续异步操作）
• expire key：为给定的key设置过期时间
• ttl key：查看还有多少秒过期，-1表示永不过期，-2表示已过期
• select：切换数据库
• dbsize：查看当前数据库key的数量
• flushdb：清空当前库
• flushall：通杀所有库

2、字符串类型（String）

String是Redis中最基本的类型

String类型是二进制安全的，意味着Redis的String可以包含任何数据，比如jpg图片、视频、序列化对象等

一个Redis中字符串value最多可以是512M

序号	命令及描述
1	SET key value 设置指定 key 的值。
2	GET key 获取指定 key 的值。
3	GETRANGE key start end 返回 key 中字符串值的子字符
4	GETSET key value 将给定 key 的值设为 value ，并返回 key 的旧值(old value)。
5	GETBIT key offset 对 key 所储存的字符串值，获取指定偏移量上的位(bit)。
6	[MGET key1 key2…] 获取所有(一个或多个)给定 key 的值。
7	SETBIT key offset value 对 key 所储存的字符串值，设置或清除指定偏移量上的位(bit)。
8	SETEX key seconds value 将值 value 关联到 key ，并将 key 的过期时间设为 seconds (以秒为单位)。
9	SETNX key value 只有在 key 不存在时设置 key 的值。
10	SETRANGE key offset value 用 value 参数覆写给定 key 所储存的字符串值，从偏移量 offset 开始。
11	STRLEN key 返回 key 所储存的字符串值的长度。
12	[MSET key value key value …] 同时设置一个或多个 key-value 对。
13	[MSETNX key value key value …] 同时设置一个或多个 key-value 对，当且仅当所有给定 key 都不存在。
14	PSETEX key milliseconds value 这个命令和 SETEX 命令相似，但它以毫秒为单位设置 key 的生存时间，而不是像 SETEX 命令那样，以秒为单位。
15	INCR key 将 key 中储存的数字值增一。
16	INCRBY key increment 将 key 所储存的值加上给定的增量值（increment） 。
17	INCRBYFLOAT key increment 将 key 所储存的值加上给定的浮点增量值（increment） 。
18	DECR key 将 key 中储存的数字值减一。
19	DECRBY key decrement key 所储存的值减去给定的减量值（decrement） 。
20	APPEND key value 如果 key 已经存在并且是一个字符串， APPEND 命令将指定的 value 追加到该 key 原来值（value）的末尾。

数据结构

String 的数据结构为简单动态字符串 (Simple Dynamic String, 缩写 SDS)，是可以修改的字符串，内部结构实现上类似于 Java 的 ArrayList，采用预分配冗余空间的方式来减少内存的频繁分配.

如图中所示，内部为当前字符串实际分配的空间 capacity 一般要高于实际字符串长度 len。当字符串长度小于 1M 时，扩容都是加倍现有的空间，如果超过 1M，扩容时一次只会多扩 1M 的空间。需要注意的是字符串最大长度为 512M。

3、列表（List）

单键多值：Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。它的底

层实际是个双向链表，对两端的操作性能很高，通过索引下标的操作中间的节点性能会较差。

序号	命令及描述
1	[BLPOP key1 key2 ] timeout 移出并获取列表的第一个元素， 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。
2	[BRPOP key1 key2 ] timeout 移出并获取列表的最后一个元素， 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。
3	BRPOPLPUSH source destination timeout 从列表中弹出一个值，将弹出的元素插入到另外一个列表中并返回它； 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。
4	LINDEX key index 通过索引获取列表中的元素
5	LINSERT key BEFORE|AFTER pivot value 在列表的元素前或者后插入元素
6	LLEN key 获取列表长度
7	LPOP key 移出并获取列表的第一个元素
8	[LPUSH key value1 value2] 将一个或多个值插入到列表头部
9	LPUSHX key value 将一个值插入到已存在的列表头部
10	LRANGE key start stop 获取列表指定范围内的元素
11	LREM key count value 移除列表元素
12	LSET key index value 通过索引设置列表元素的值
13	LTRIM key start stop 对一个列表进行修剪(trim)，就是说，让列表只保留指定区间内的元素，不在指定区间之内的元素都将被删除。
14	RPOP key 移除列表的最后一个元素，返回值为移除的元素。
15	RPOPLPUSH source destination 移除列表的最后一个元素，并将该元素添加到另一个列表并返回
16	[RPUSH key value1 value2] 在列表中添加一个或多个值
17	RPUSHX key value 为已存在的列表添加值

数据结构

List 的数据结构为快速链表 quickList。

首先在列表元素较少的情况下会使用一块连续的内存存储，这个结构是 ziplist，也即是压缩列表。它将所有的元素紧挨着一起存储，分配的是一块连续的内存。(类似数组)

当数据量比较多的时候才会改成 quicklist。因为普通的链表需要的附加指针空间太大，会比较浪费空间。比如这个列表里存的只是 int 类型的数据，结构上还需要两个额外的指针 prev 和 next。

Redis 将链表和 ziplist 结合起来组成了 quicklist。也就是将多个 ziplist 使用双向指针串起来使用。这样既满足了快速的插入删除性能，又不会出现太大的空间冗余。

4、集合（Set）

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

Redis的Set是string类型的无序集合。它底层其实是一个value为null的hash表，所以添加、删除、查找的复杂度都是 O (1）

一个算法，随着数据的增加，执行时间的长短，如果是O(1)，数据增加、查找数据的时间不变

序号	命令及描述
1	[SADD key member1 member2] 向集合添加一个或多个成员
2	SCARD key 获取集合的成员数
3	[SDIFF key1 key2] 返回第一个集合与其他集合之间的差异。
4	[SDIFFSTORE destination key1 key2] 返回给定所有集合的差集并存储在 destination 中
5	[SINTER key1 key2] 返回给定所有集合的交集
6	[SINTERSTORE destination key1 key2] 返回给定所有集合的交集并存储在 destination 中
7	SISMEMBER key member 判断 member 元素是否是集合 key 的成员
8	SMEMBERS key 返回集合中的所有成员
9	SMOVE source destination member 将 member 元素从 source 集合移动到 destination 集合
10	SPOP key 移除并返回集合中的一个随机元素
11	[SRANDMEMBER key count] 返回集合中一个或多个随机数
12	[SREM key member1 member2] 移除集合中一个或多个成员
13	[SUNION key1 key2] 返回所有给定集合的并集
14	[SUNIONSTORE destination key1 key2] 所有给定集合的并集存储在 destination 集合中
15	[SSCAN key cursor MATCH pattern] [COUNT count] 迭代集合中的元素

数据结构

Set数据结构是dict字典，字典是用哈希表实现的

Java中HashSet的内部实现使用的是HashMap，只不过所有的value都指向同一个对象。Redis的Set结构也是一样，它的内部也使用hash结构，所有的value都指向同一个内部值

5、哈希（Hash）

Hash是一个键值对集合

Hash是一个string类型的field和value的映射表，hash特别适合用于存储对象

类似Java里面的Map<String,Object>

用户ID为查找的key，存储的value用户对象包含姓名，年龄，生日等信息，如果用普通的key/value结构来存储，主要有以下2种存储方式：

存储为json字符串，每次修改用户的某个属性需要，先反序列化改好后再序列化回去，操作繁琐。

数据分散、结构复杂

通过 key (用户 ID) + field (属性标签) 就可以操作对应属性数据

序号	命令及描述
1	[HDEL key field1 field2] 删除一个或多个哈希表字段
2	HEXISTS key field 查看哈希表 key 中，指定的字段是否存在。
3	HGET key field 获取存储在哈希表中指定字段的值。
4	HGETALL key 获取在哈希表中指定 key 的所有字段和值
5	HINCRBY key field increment 为哈希表 key 中的指定字段的整数值加上增量 increment 。
6	HINCRBYFLOAT key field increment 为哈希表 key 中的指定字段的浮点数值加上增量 increment 。
7	HKEYS key 获取所有哈希表中的字段
8	HLEN key 获取哈希表中字段的数量
9	[HMGET key field1 field2] 获取所有给定字段的值
10	[HMSET key field1 value1 field2 value2 ] 同时将多个 field-value (域-值)对设置到哈希表 key 中。
11	HSET key field value 将哈希表 key 中的字段 field 的值设为 value 。
12	HSETNX key field value 只有在字段 field 不存在时，设置哈希表字段的值。
13	HVALS key 获取哈希表中所有值。
14	[HSCAN key cursor MATCH pattern] [COUNT count] 迭代哈希表中的键值对。

数据结构

Hash类型对应的数据结构是两种：ziplist（压缩列表），hashtable（哈希表）。当field-value长度较短且个数较少时，使用ziplist，否则使用hashtable

6、有序集合（ZSet）

Redis有序集合zset与普通集合set非常相似，是一个没有重复元素的字符串集合。

不同之处是有序集合的每个成员都关联了一个评分（score），这个评分（score）被用来按照从最低分到最高分的方式排序集合中的成员。集合的成员是唯一的，但是评分可以是重复了 。

因为元素是有序的，所以你也可以很快的根据评分（score）或者次序（position）来获取一个范围的元素。

访问有序集合的中间元素也是非常快的，因此你能够使用有序集合作为一个没有重复成员的智能列表。

序号	命令及描述
1	[ZADD key score1 member1 score2 member2] 向有序集合添加一个或多个成员，或者更新已存在成员的分数
2	ZCARD key 获取有序集合的成员数
3	ZCOUNT key min max 计算在有序集合中指定区间分数的成员数
4	ZINCRBY key increment member 有序集合中对指定成员的分数加上增量 increment
5	[ZINTERSTORE destination numkeys key key …] 计算给定的一个或多个有序集的交集并将结果集存储在新的有序集合 destination 中
6	ZLEXCOUNT key min max 在有序集合中计算指定字典区间内成员数量
7	[ZRANGE key start stop WITHSCORES] 通过索引区间返回有序集合指定区间内的成员
8	[ZRANGEBYLEX key min max LIMIT offset count] 通过字典区间返回有序集合的成员
9	[ZRANGEBYSCORE key min max WITHSCORES] [LIMIT] 通过分数返回有序集合指定区间内的成员
10	ZRANK key member 返回有序集合中指定成员的索引
11	[ZREM key member member …] 移除有序集合中的一个或多个成员
12	ZREMRANGEBYLEX key min max 移除有序集合中给定的字典区间的所有成员
13	ZREMRANGEBYRANK key start stop 移除有序集合中给定的排名区间的所有成员
14	ZREMRANGEBYSCORE key min max 移除有序集合中给定的分数区间的所有成员
15	[ZREVRANGE key start stop WITHSCORES] 返回有序集中指定区间内的成员，通过索引，分数从高到低
16	[ZREVRANGEBYSCORE key max min WITHSCORES] 返回有序集中指定分数区间内的成员，分数从高到低排序
17	ZREVRANK key member 返回有序集合中指定成员的排名，有序集成员按分数值递减(从大到小)排序
18	ZSCORE key member 返回有序集中，成员的分数值
19	[ZUNIONSTORE destination numkeys key key …] 计算给定的一个或多个有序集的并集，并存储在新的 key 中
20	[ZSCAN key cursor MATCH pattern] [COUNT count] 迭代有序集合中的元素（包括元素成员和元素分值）

SortedSet (zset) 是Redis提供的一个非常特别的数据结构，一方面它等价于Java的数据结构Map<String, Double>，可以给每一个元素 value赋予一个权重score，另一方面它又类似于TreeSet，内部的元素会按照权重score进行排序，可以得到每个元素的名次，还可以通过score的范围来获取元素的列表。

zset底层使用了两个数据结构：

hash，hash的作用就是关联元素value和权重score，保障元素value 的唯一性，可以通过元素value找到相应的score值。

跳跃表，跳跃表的目的在于给元素value排序，根据score的范围获取元素列表。

跳跃表

有序集合在生活中比较常见，例如根据成绩对学生排名，根据得分对玩家排名等。对于有序集合的底层实现，可以用数组、平衡树、链表等。数组不便元素的插入、删除；平衡树或红黑树虽然效率高但结构复杂；链表查询需要遍历所有效率低。Redis采用的是跳跃表，跳跃表效率堪比红黑树，实现远比红黑树简单。

1、有序表：

要查找值为51的元素，需要从第一个元素开始依次查找、比较才能找到。共需要6次比较。

2、跳跃表（以空间兑换时间）：

• 从第 2 层开始，1 节点比 51 节点小，向后比较；

• 21 节点比 51 节点小，继续向后比较，后面就是 NULL 了，所以从 21 节点向下到第 1 层；

• 在第 1 层，41 节点比 51 节点小，继续向后，61 节点比 51 节点大，所以从 41 向下；

• 在第 0 层，51 节点为要查找的节点，节点被找到，共查找 4 次。

7、BitMap

BitMap 原本的含义是用一个比特位来映射某个元素的状态。由于一个比特位只能表示 0 和 1 两种状态，所以 BitMap 能映射的状态有限，但是使用比特位的优势是能大量的节省内存空间。

Bitmaps 本身不是一种数据类型， 实际上它就是字符串（key-value） ， 但是它可以对字符串的位进行操作。

在 Redis 中，可以把 Bitmaps 想象成一个以比特位为单位的数组，数组的每个单元只能存储0和1，数组的下标在 Bitmaps 中叫做偏移量。

使用场景：

统计活跃用户（用户登陆情况）

假设网站有 1 亿用户， 每天独立访问的用户有 5 千万， 如果每天用集合类型和 Bitmaps 分别存储活跃用户可以得到set 和 Bitmaps 存储一天活跃用户对比：
数据类型 每个用户 id 占用空间 需要存储的用户量 全部内存量
集合 64 位 50000000 64 位 * 50000000 = 400MB
Bitmaps 1 位 100000000 1 位 * 100000000 = 12.5MB

显然极大的减少了开销。

但 Bitmaps 并不是万金油， 假如该网站每天的独立访问用户很少， 例如只有 10 万（大量的僵尸用户） ， 那么两者的对比如下表所示， 很显然， 这时候使用 Bitmaps 就不太合适了， 因为基本上大部分位都是 0。

数据类型 每个用户 id 占用空间 需要存储的用户量 全部内存量
集合 64 位 100000 64 位 * 100000 = 800KB
Bitmaps 1 位 100000000 1 位 * 100000000 = 12.5MB

8、HyperLogLog

在工作当中，我们经常会遇到与统计相关的功能需求，比如统计网站 PV（PageView 页面访问量），可以使用 Redis 的 incr、incrby 轻松实现。但像 UV（UniqueVisitor 独立访客）、独立 IP 数、搜索记录数等需要去重和计数的问题如何解决？这种求集合中不重复元素个数的问题称为基数问题。

什么是基数？

比如数据集 {1, 3, 5, 7, 5, 7, 8}，那么这个数据集的基数集为 {1, 3, 5 ,7, 8}，基数 (不重复元素) 为 5。 基数估计就是在误差可接受的范围内，快速计算基数。

解决基数问题有很多种方案：

• 数据存储在 MySQL 表中，使用 distinct count 计算不重复个数。

• 使用 Redis 提供的 hash、set、bitmaps 等数据结构来处理。

以上的方案结果精确，但随着数据不断增加，导致占用空间越来越大，对于非常大的数据集是不切实际的。能否能够降低一定的精度来平衡存储空间？Redis 推出了 HyperLogLog。

Redis HyperLogLog 是用来做基数统计的算法，HyperLogLog 的优点是：在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。

在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。

计数存在一定的误差，误差率整体较低。标准误差为 0.81% 。

误差可以被设置辅助计算因子进行降低。

但是，因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。

序号	命令及描述
1	[PFADD key element element …] 添加指定元素到 HyperLogLog 中。
2	[PFCOUNT key key …] 返回给定 HyperLogLog 的基数估算值。
3	[PFMERGE destkey sourcekey sourcekey …] 将多个 HyperLogLog 合并为一个 HyperLogLog

9、Geospatial

Redis 3.2 中增加了对 GEO 类型的支持。GEO，Geographic，地理信息的缩写。该类型，就是元素的 2 维坐标，在地图上就是经纬度。redis 基于该类型，提供了经纬度设置，查询，范围查询，距离查询，经纬度 Hash 等常见操作。

• GEOADD：添加一个或多个地理位置元素到一个key中
  • 格式：GEOADD key longitude latitude member [longitude latitude member …]
• GEODIST：返回一个key中指定两个位置之间的距离
  • 格式：GEODIST key member1 member2 [unit] unit可以指定长度单位：m,km,ft等 默认为m
• GEOHASH：返回一个或多个位置元素的 Geohash 表示，Geohash是一种经纬度散列算法，具体请百度。
  • 格式：GEOHASH key member [member …]
• GEOPOS：返回一个或多个位置的经纬度信息，由于采用了geohash算法，返回的经纬度和添加时的数据可能会有细小误差
  • 格式：GEOPOS key member [member …]
• GEORADIUS：以给定位置为中心，半径不超过给定半径的附近所有位置
  • 格式：GEORADIUS key longitude latitude radius m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count]
• GEORADIUSBYMEMBER 和GEORADIUS相似，只是中心点不是指定经纬度，而是指定已添加的某个位置作为中心
  • 格式：GEORADIUSBYMEMBER key member radius m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count]

四、配置文件

• bind 127.0.0.1：注释掉该项以支持远程连接

• protected-mode：本机访问保护模式，设置为no以支持远程访问

• timeout 300：当客户端闲置多长秒后关闭连接，如果指定为 0 ，表示关闭该功能

• daemonize no：Redis 默认不是以守护进程的方式运行，可以通过该配置项修改，使用 yes 启用守护进程（即后台启动）

• databases 16：设置数据库的数量，默认数据库为0，可以使用SELECT 命令在连接上指定数据库id

• requirepass foobared： 设置 Redis 连接密码，如果配置了连接密码，客户端在连接 Redis 时需要通过 AUTH ”password“ 命令提供密码，默认关闭

• loglevel notice：指定日志记录级别，Redis 总共支持四个级别：debug、verbose、notice、warning，默认为 notice（生产环境）

• logfile stdout： 日志记录方式，默认为标准输出，如果配置 Redis 为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给 /dev/null

五、Redis的发布和订阅

Redis发布订阅（pub/sub）是一种消息通信模式：发送者（pub）发送消息，订阅者（sub）接收消息

Redis客户端可以订阅任何数量的频道

下图展示了频道 channel1 ， 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系：

当有新消息通过 PUBLISH 命令发送给频道 channel1 时， 这个消息就会被发送给订阅它的三个客户端：

第一个客户端订阅频道：

redis 127.0.0.1:6379> SUBSCRIBE runoobChat

Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "runoobChat"
3) (integer) 1

第二个客户端在频道发布消息：

redis 127.0.0.1:6379> PUBLISH runoobChat "Redis PUBLISH test"

订阅者的客户端会显示如下消息

1) "message"
2) "runoobChat"
3) "Redis PUBLISH test"
1) "message"
2) "runoobChat"
3) "Learn redis by runoob.com"

序号	命令及描述
1	[PSUBSCRIBE pattern pattern …] 订阅一个或多个符合给定模式的频道。
2	[PUBSUB subcommand argument [argument …]] 查看订阅与发布系统状态。
3	PUBLISH channel message 将信息发送到指定的频道。
4	[PUNSUBSCRIBE pattern [pattern …]] 退订所有给定模式的频道。
5	[SUBSCRIBE channel channel …] 订阅给定的一个或多个频道的信息。
6	[UNSUBSCRIBE channel [channel …]] 指退订给定的频道。

发布的消息没有持久化，只能收到订阅之后发布的消息