关于redis:7000字-Redis-超详细总结笔记建议收藏

Redis 是齐全开源收费的，恪守 BSD 协定，是一个高性能的 key – value 数据库

Redis 与其余 key – value 缓存产品有以下三个特点：

Redis 反对数据长久化，能够将内存中的数据保留在磁盘中，重启的时候能够再次加载进行应用。
Redis 不仅仅反对简略的 key – value 类型的数据，同时还提供 list，set，zset，hash 等数据结构的存储
Redis 反对数据的备份，即 master – slave 模式的数据备份

性能极高 – Redis 读的速度是 110000 次 /s, 写的速度是 81000 次 /s。
丰盛的数据类型 – Redis 反对二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。
原子性 – Redis 的所有操作都是原子性的，意思就是要么胜利执行要么失败齐全不执行。单个操作是原子性的。多个操作也反对事务，即原子性，通过 MULTI 和 EXEC 指令包起来。
其余个性 – Redis 还反对 publish/subscribe 告诉，key 过期等个性。

Redis 反对 5 中数据类型：string（字符串），hash（哈希），list（列表），set（汇合），zset（sorted set：有序汇合）

string

string 是 redis 最根本的数据类型。一个 key 对应一个 value。

string 是二进制平安的。也就是说 redis 的 string 能够蕴含任何数据。比方 jpg 图片或者序列化的对象。

string 类型是 redis 最根本的数据类型，string 类型的值最大能存储 512 MB。

了解：string 就像是 java 中的 map 一样，一个 key 对应一个 value

127.0.0.1:6379> set hello world
OK
127.0.0.1:6379> get hello
"world"

hash

Redis hash 是一个键值对（key – value）汇合。Redis hash 是一个 string 类型的 key 和 value 的映射表，hash 特地适宜用于存储对象。

了解：能够将 hash 看成一个 key – value 的汇合。也能够将其想成一个 hash 对应着多个 string。

与 string 区别：string 是一个 key – value 键值对，而 hash 十多个 key – value 键值对。

// hash-key 能够看成是一个键值对汇合的名字, 在这里别离为其增加了 sub-key1 : value1、sub-key2 : value2、sub-key3 : value3 这三个键值对 127.0.0.1:6379> hset hash-key sub-key1 value1
(integer) 1
127.0.0.1:6379> hset hash-key sub-key2 value2
(integer) 1
127.0.0.1:6379> hset hash-key sub-key3 value3
(integer) 1
// 获取 hash-key 这个 hash 外面的所有键值对
127.0.0.1:6379> hgetall hash-key
1) "sub-key1"
2) "value1"
3) "sub-key2"
4) "value2"
5) "sub-key3"
6) "value3"
// 删除 hash-key 这个 hash 外面的 sub-key2 键值对
127.0.0.1:6379> hdel hash-key sub-key2
(integer) 1
127.0.0.1:6379> hget hash-key sub-key2
(nil)127.0.0.1:6379> hget hash-key sub-key1
"value1"
127.0.0.1:6379> hgetall hash-key
1) "sub-key1"
2) "value1"
3) "sub-key3"
4) "value3"

list

Redis 列表是简略的字符串列表，依照插入程序排序。咱们能够往列表的右边或者左边增加元素。

127.0.0.1:6379> rpush list-key v1(integer) 1127.0.0.1:6379> rpush list-key v2(integer) 2127.0.0.1:6379> rpush list-key v1(integer) 3127.0.0.1:6379> lrange list-key 0 -11) "v1"2) "v2"3) "v1"127.0.0.1:6379> lindex list-key 1"v2"127.0.0.1:6379> lpop list(nil)127.0.0.1:6379> lpop list-key"v1"127.0.0.1:6379> lrange list-key 0 -11) "v2"2) "v1"

咱们能够看出 list 就是一个简略的字符串汇合，和 Java 中的 list 相差不大，区别就是这里的 list 寄存的是字符串。list 内的元素是可反复的。

set

redis 的 set 是字符串类型的无序汇合。汇合是通过哈希表实现的，因而增加、删除、查找的复杂度都是 O（1）

127.0.0.1:6379> sadd k1 v1(integer) 1127.0.0.1:6379> sadd k1 v2(integer) 1127.0.0.1:6379> sadd k1 v3(integer) 1127.0.0.1:6379> sadd k1 v1(integer) 0127.0.0.1:6379> smembers k11) "v3"2) "v2"3) "v1"127.0.0.1:6379>127.0.0.1:6379> sismember k1 k4(integer) 0127.0.0.1:6379> sismember k1 v1(integer) 1127.0.0.1:6379> srem k1 v2(integer) 1127.0.0.1:6379> srem k1 v2(integer) 0127.0.0.1:6379> smembers k11) "v3"2) "v1"

redis 的 set 与 java 中的 set 还是有点区别的。

redis 的 set 是一个 key 对应着多个字符串类型的 value，也是一个字符串类型的汇合，然而和 redis 的 list 不同的是 set 中的字符串汇合元素不能反复，然而 list 能够。

Zset

redis zset 和 set 一样都是字符串类型元素的汇合，并且汇合内的元素不能反复。

不同的是，zset 每个元素都会关联一个 double 类型的分数。redis 通过分数来为汇合中的成员进行从小到大的排序。

zset 的元素是惟一的，然而分数（score）却能够反复。

127.0.0.1:6379> zadd zset-key 728 member1(integer) 1127.0.0.1:6379> zadd zset-key 982 member0(integer) 1127.0.0.1:6379> zadd zset-key 982 member0(integer) 0127.0.0.1:6379> zrange zset-key 0 -1 withscores1) "member1"2) "728"3) "member0"4) "982"127.0.0.1:6379> zrangebyscore zset-key 0 800 withscores1) "member1"2) "728"127.0.0.1:6379> zrem zset-key member1(integer) 1127.0.0.1:6379> zrem zset-key member1(integer) 0127.0.0.1:6379> zrange zset-key 0 -1 withscores1) "member0"2) "982"

zset 是依照分数的大小来排序的。

个别不必 Redis 做音讯公布订阅。

简介

Redis 公布订阅 (pub/sub) 是一种音讯通信模式：发送者 (pub) 发送音讯，订阅者 (sub) 接管音讯。

Redis 客户端能够订阅任意数量的频道。

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

学 Redis 这篇就够了

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

学 Redis 这篇就够了

实例

以下实例演示了公布订阅是如何工作的。在咱们实例中咱们创立了订阅频道名为 redisChat:

127.0.0.1:6379> SUBsCRIBE redisChatReading messages... (press Ctrl-C to quit)1) "subscribe"2) "redisChat"

当初，咱们先从新开启个 redis 客户端，而后在同一个频道 redisChat 公布两次音讯，订阅者就能接管到音讯。

127.0.0.1:6379> PUBLISH redisChat "send message"(integer) 1127.0.0.1:6379> PUBLISH redisChat "hello world"(integer) 1# 订阅者的客户端显示如下 1) "message"2) "redisChat"3) "send message"1) "message"2) "redisChat"3) "hello world"

redis 事务一次能够执行多条命令，服务器在执行命令期间，不会去执行其余客户端的命令申请。

事务中的多条命令被一次性发送给服务器，而不是一条一条地发送，这种形式被称为流水线，它能够缩小客户端与服务器之间的网络通信次数从而晋升性能。

Redis 最简略的事务实现形式是应用 MULTI 和 EXEC 命令将事务操作包围起来。

批量操作在发送 EXEC 命令前被放入队列缓存。
收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余命令仍然被执行。也就是说 Redis 事务不保障原子性。
在事务执行过程中，其余客户端提交的命令申请不会插入到事务执行命令序列中。

一个事务从开始到执行会经验以下三个阶段：

开始事务。
命令入队。
执行事务。

实例

以下是一个事务的例子，它先以 MULTI 开始一个事务，而后将多个命令入队到事务中，最初由 EXEC 命令触发事务，一并执行事务中的所有命令：

redis 127.0.0.1:6379> MULTIOKredis 127.0.0.1:6379> SET book-name "Mastering C++ in 21 days"QUEUEDredis 127.0.0.1:6379> GET book-nameQUEUEDredis 127.0.0.1:6379> SADD tag "C++" "Programming" "Mastering Series"QUEUEDredis 127.0.0.1:6379> SMEMBERS tagQUEUEDredis 127.0.0.1:6379> EXEC1) OK2) "Mastering C++ in 21 days"3) (integer) 34) 1) "Mastering Series" 2) "C++" 3) "Programming"

单个 Redis 命令的执行是原子性的，但 Redis 没有在事务上减少任何维持原子性的机制，所以 Redis 事务的执行并不是原子性的。

事务能够了解为一个打包的批量执行脚本，但批量指令并非原子化的操作，两头某条指令的失败不会导致后面已做指令的回滚，也不会造成后续的指令不做。

这是官网上的阐明 From redis docs on transactions:

It’s important to note that even when a command fails, all the other commands in the queue are processed – Redis will not stop the processing of commands.

比方：

redis 127.0.0.1:7000> multiOKredis 127.0.0.1:7000> set a aaaQUEUEDredis 127.0.0.1:7000> set b bbbQUEUEDredis 127.0.0.1:7000> set c cccQUEUEDredis 127.0.0.1:7000> exec1) OK2) OK3) OK

如果在 set b bbb 处失败，set a 已胜利不会回滚，set c 还会继续执行。

Redis 事务命令

下表列出了 redis 事务的相干命令：

序号命令及形容：

DISCARD 勾销事务，放弃执行事务块内的所有命令。
EXEC 执行所有事务块内的命令。
MULTI 标记一个事务块的开始。
UNWATCH 勾销 WATCH 命令对所有 key 的监督。
WATCH key [key …]监督一个 (或多个) key，如果在事务执行之前这个 (或这些) key 被其余命令所改变，那么事务将被打断。

Redis 是内存型数据库，为了保证数据在断电后不会失落，须要将内存中的数据长久化到硬盘上。

RDB 长久化

将某个工夫点的所有数据都寄存到硬盘上。

能够将快照复制到其余服务器从而创立具备雷同数据的服务器正本。

如果零碎产生故障，将会失落最初一次创立快照之后的数据。

如果数据量大，保留快照的工夫会很长。

AOF 长久化

将写命令增加到 AOF 文件（append only file）开端。

应用 AOF 长久化须要设置同步选项，从而确保 写命令 同步到磁盘文件上的机会。

这是因为对文件进行写入并不会马上将内容同步到磁盘上，而是先存储到缓冲区，而后由操作系统决定什么时候同步到磁盘。

选项同步频率 always 每个写命令都同步 eyerysec 每秒同步一次 no 让操作系统来决定何时同步

always 选项会重大减低服务器的性能
everysec 选项比拟适合，能够保证系统解体时只会失落一秒左右的数据，并且 Redis 每秒执行一次同步对服务器简直没有任何影响。
no 选项并不能给服务器性能带来多大的晋升，而且会减少零碎解体时数据失落的数量。

随着服务器写申请的增多，AOF 文件会越来越大。Redis 提供了一种将 AOF 重写的个性，可能去除 AOF 文件中的冗余写命令。

通过应用 slaveof host port 命令来让一个服务器成为另一个服务器的总服务器。

一个从服务器只能有一个主服务器，并且不反对主主复制。

连贯过程

主服务器创立快照文件，即 RDB 文件，发送给从服务器，并在发送期间应用缓冲区记录执行的写命令。
快照文件发送结束之后，开始向从服务器发送存储在缓冲区的写命令。
从服务器抛弃所有旧数据，载入主服务器发来的快照文件，之后从服务器开始承受主服务器发来的写命令。
主服务器每执行一次写命令，就向从服务器发送雷同的写命令。

主从链

随着负载一直回升，主服务器无奈很快的更新所有从服务器，或者从新连贯和从新同步从服务器将导致系统超载。

为了解决这个问题，能够创立一个中间层来分担主服务器的复制工作。中间层的服务器是最上层服务器的总服务器，又是最上层服务器的主服务器。

Sentinel（哨兵）能够监听集群中的服务器，并在主服务器进入下线状态时，主动从从服务器中抉择出新的主服务器。

分片是将数据划分为多个局部的办法，能够将数据存储到多台机器外面，这种办法在解决某些问题时能够取得线性级别的性能晋升。

假如有 4 个 Redis 实例 R0, R1, R2, R3, 还有很多示意用户的键 user:1, user:2, … , 有不同的形式来抉择一个指定的键存储在哪个实例中。

最简略的是范畴分片，例如用户 id 从 0 ~ 1000 的存储到实例 R0 中，用户 id 从 1001 ~ 2000 的存储到实例 R1 中，等等。然而这样须要保护一张映射范畴表，保护操作代价高。
还有一种是哈希分片。应用 CRC32 哈希函数将键转换为一个数字，再对实例数量求模就能晓得存储的实例。

依据执行分片的地位，能够分为三种分片形式：

客户端分片：客户端应用一致性哈希等算法决定该当散布到哪个节点。
代理分片：将客户端的申请发送到代理上，由代理转发到正确的节点上。
服务器分片：Redis Cluster。

关于redis:7000字-Redis-超详细总结笔记建议收藏

Redis 简介

Redis 劣势

Redis 数据类型

公布订阅

事务

长久化

复制

哨兵

分片