Redis命令

1、进入redis命令行：redis-cli -h host -p port -a password
2、将Redis注册为windows服务：redis-server.exe –service-install redis.windows.conf

Redis支持的数据类型

String字符串：
格式: set key value
string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象 。
string类型是Redis最基本的数据类型，一个键最大能存储512MB。

Hash（哈希）
格式: hmset name key1 value1 key2 value2
Redis hash 是一个键值(key=>value)对集合。
Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。

List（列表）
Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）
格式: lpush name value
在 key 对应 list 的头部添加字符串元素
格式: rpush name value
在 key 对应 list 的尾部添加字符串元素
格式: lrem name index
key 对应 list 中删除 count 个和 value 相同的元素
格式: llen name
返回 key 对应 list 的长度

Set（集合）
格式: sadd name value
Redis的Set是string类型的无序集合。
集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。

zset(sorted set：有序集合)
格式: zadd name score value
Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。
不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。
zset的成员是唯一的,但分数(score)却可以重复。

Redis持久化

持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。
Redis提供了两种持久化方式:RDB（默认）和AOF。

RDB机制的策略

RDB持久化是指在指定的时间间隔内将内存中的数据和操作通过快照的方式保存到redis bin目录下的一个默认名为 dump.rdb的文件，可以通过配置设置自动的快照持久化的方式，我们可以配置redis在n秒内进行快照的时间，如果超过这个时间节点，将会自动执行快照操作。虽然这种方式方便快捷，但是无法保证数据的绝对安全可靠，如果服务器在非备份时间跨度内发生了故障，无法做到对当前状态的实时保存，导致数据丢失。而且每次保存 RDB文件时， Redis都需要 fork()出一个子进程，由子进程来执行具体的持久化工作，对资源消耗较大。——最大缺点

相关配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
save：这里是用来配置触发 Redis的 RDB 持久化条件，比如“save m n”。表示m秒内数据集存在n次修改时
    save 900 1：表示900 秒内如果至少有 1 个 key 的值变化，则保存
    save 300 10：表示300 秒内如果至少有 10 个 key 的值变化，则保存
    save 60 10000：表示60 秒内如果至少有 10000 个 key 的值变化，则保存
如果你只是用Redis的缓存功能，不需要持久化，那么你可以注释掉所有的 save 行来停用保存功能。可以直接一个空字符串来实现停用：save ""

stop-writes-on-bgsave-error：默认值为yes。当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难（disaster）发生了。如果Redis重启了，那么又可以重新开始接收数据了

rdbcompression：默认值是yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能，但是存储在磁盘上的快照会比较大。

rdbchecksum：默认值是yes。在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能

dbfilename：设置快照的文件名，默认是 dump.rdb

dir：设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。默认是和当前配置文件保存在同一目录

也就是说通过在配置文件中配置的 save 方式，当实际操作满足该配置形式时就会进行 RDB 持久化，将当前的内存快照保存在 dir 配置的目录中，文件名由配置的 dbfilename 决定

手动触发RDB快照，命令：1.save（会造成阻塞）2.bgsave（Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束）

AOF机制的策略

redis 的 AOF 持久化是在每次接受到的写命令通过 write函数追加到文件中（默认是 appendonly.aof），但是由于操作系统在写入文件时使用了缓存来提高写入效率，还是可能会出现因服务器突然故障而导致的数据丢失，故我们可以通过配置文件告诉redis我们同步数据的时间间隔（默认间隔是每秒同步一次）

相关配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
appendonly yes(默认no,关闭)：是否开启AOF持久化

appendfilename "appendonly.aof"：AOF持久化配置文件的名称

appendfsync everysec：AOF持久化策略
    always - 同步持久化，每次发生数据变更会被立即记录到磁盘，性能差但数据完整性比较好
    everysec - 异步操作，每秒记录，如果一秒钟内宕机，有数据丢失，推荐
    no - 将缓存回写的策略交给系统，linux 默认是30秒将缓冲区的数据回写硬盘的

AOF的Rewrite(重写)：
当AOF文件的大小超过了配置所设置的阙值时，Redis就会启动AOF文件压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof
触发机制：Redis会记录上次重写时的AOF文件大小，默认配置时当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

Redis主从复制

主redis配置不需修改，从需要修改port（从端口）和slaveof host port（对应的主redis的host和port）
若主从都开启了密码，则从redis需要配置masterauth

主机说明
主机IP
端口
master 192.168.250.132 7000
slave 192.168.250.133 7001
slave 192.168.250.134 7002

注意：
1.redis安装版本必须保持一致
2.132服务器配置masterauth作用主要是为了后期sentinel引入后重新选举master并且7000端口redis重新加入主从复制时必备的，否则会出现权限不足
3.设置bind 的IP地址，此IP为redis服务器IP以及本地127，如果没有设置 127，会出现无法启动问题，没有设置服务器IP会出现slave服务器无法连接master服务器。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
==================132redis启动================================================
103398:C 08 Jan 2019 17:42:20.481 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
103398:C 08 Jan 2019 17:42:20.481 # Redis version=5.0.2, bits=64, commit=00000000, modified=0, pid=103398, just started
103398:C 08 Jan 2019 17:42:20.481 # Configuration loaded
103399:M 08 Jan 2019 17:42:20.482 * Increased maximum number of open files to 10032 (it was originally set to 1024).
103399:M 08 Jan 2019 17:42:20.483 * Running mode=standalone, port=7000.
103399:M 08 Jan 2019 17:42:20.483 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
103399:M 08 Jan 2019 17:42:20.483 # Server initialized
103399:M 08 Jan 2019 17:42:20.483 # 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' for this to take effect.
103399:M 08 Jan 2019 17:42:20.483 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
103399:M 08 Jan 2019 17:42:20.483 * Ready to accept connections

==================133redis启动开始请求同步======================================
103399:M 08 Jan 2019 17:44:56.213 * Replica 192.168.250.133:7001 asks for synchronization
103399:M 08 Jan 2019 17:44:56.213 * Full resync requested by replica 192.168.250.133:7001

# 主从复制 默认 RDB 持久化
103399:M 08 Jan 2019 17:44:56.213 * Starting BGSAVE for SYNC with target: disk
103399:M 08 Jan 2019 17:44:56.214 * Background saving started by pid 103768
103768:C 08 Jan 2019 17:44:56.216 * DB saved on disk
103768:C 08 Jan 2019 17:44:56.216 * RDB: 4 MB of memory used by copy-on-write
103399:M 08 Jan 2019 17:44:56.299 * Background saving terminated with success

# 133 redis 数据同步成功
103399:M 08 Jan 2019 17:44:56.299 * Synchronization with replica 192.168.250.133:7001 succeeded

==================134redis启动开始请求同步=======================================
103399:M 08 Jan 2019 17:45:25.389 * Replica 192.168.250.134:7002 asks for synchronization
103399:M 08 Jan 2019 17:45:25.389 * Full resync requested by replica 192.168.250.134:7002

# 主从复制 默认 RDB 持久化
103399:M 08 Jan 2019 17:45:25.389 * Starting BGSAVE for SYNC with target: disk
103399:M 08 Jan 2019 17:45:25.390 * Background saving started by pid 103858
103858:C 08 Jan 2019 17:45:25.391 * DB saved on disk
103858:C 08 Jan 2019 17:45:25.392 * RDB: 4 MB of memory used by copy-on-write
103399:M 08 Jan 2019 17:45:25.402 * Background saving terminated with success

# 133 redis 数据同步成功
103399:M 08 Jan 2019 17:45:25.402 * Synchronization with replica 192.168.250.134:7002 succeeded

==================134redis关闭日志===============================================
103399:M 08 Jan 2019 17:51:13.850 # Connection with replica 192.168.250.134:7002 lost.

==================134redis重新启动日志============================================
103399:M 08 Jan 2019 17:52:28.885 * Replica 192.168.250.134:7002 asks for synchronization
103399:M 08 Jan 2019 17:52:28.885 * Partial resynchronization request from 192.168.250.134:7002 accepted. Sending 588 bytes of backlog starting from offset 43.


==================132redis强制关闭================================================
103399:M 08 Jan 2019 17:54:06.369 # User requested shutdown...
103399:M 08 Jan 2019 17:54:06.369 * Removing the pid file.
103399:M 08 Jan 2019 17:54:06.369 # Redis is now ready to exit, bye bye...

==================132redis 主服务器再次上线，同步数据以及连接slave服务器===============
105223:M 08 Jan 2019 17:54:47.189 * Background saving terminated with success
105223:M 08 Jan 2019 17:54:47.189 * Synchronization with replica 192.168.250.133:7001 succeeded
105223:M 08 Jan 2019 17:54:47.807 * Replica 192.168.250.134:7002 asks for synchronization
105223:M 08 Jan 2019 17:54:47.807 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for 'd0ff33789382fccfe621d9ad03c26cc545bda3fa', my replication IDs are '00591a20c6cafe8f906632746d514e99213ee121' and '0000000000000000000000000000000000000000')
105223:M 08 Jan 2019 17:54:47.807 * Starting BGSAVE for SYNC with target: disk
105223:M 08 Jan 2019 17:54:47.808 * Background saving started by pid 105229
105229:C 08 Jan 2019 17:54:47.809 * DB saved on disk
105229:C 08 Jan 2019 17:54:47.809 * RDB: 4 MB of memory used by copy-on-write
105223:M 08 Jan 2019 17:54:47.894 * Background saving terminated with success
105223:M 08 Jan 2019 17:54:47.894 * Synchronization with replica 192.168.250.134:7002 succeeded

总结：
1、slave服务器上面的数据都是从master服务器上同步的，一旦master挂掉，则slave服务器无法进行增量同步，假设某项目使用了slave服务器进行写的操作，当master服务器开启后，slave服务器会进行与master服务器进行全量同步，这样导致原先保存在slave上的数据丢失，当然这个例子是假设，一般slave只当做读的操作。
2、如果master宕机后，如何保证redis还可以正常使用呢？则我们就需要引入Sentinel进行master的选择啦，哨兵模式Sentinel-当redis 挂掉后自动选举 主redis。

哨兵模式Sentinel

1.相关配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
port 26379
daemonize yes
logfile "26379.log"
dir "./"
## 告诉sentinel去监听地址为ip:port的一个master，这里的master-name可以自定义，quorum是一个数字，指明当有多少个sentinel认为一个master失效时，master才算真正失效
sentinel monitor mymaster 192.168.1.5 6381 2
## 这个配置项指定了需要多少失效时间，一个master才会被这个sentinel主观地认为是不可用的。 单位是毫秒，默认为30秒
sentinel down-after-milliseconds mymaster 30000
## 当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了。
sentinel failover-timeout mymaster 15000
## 设置连接master和slave时的密码，注意的是sentinel不能分别为master和slave设置不同的密码，因此master和slave的密码应该设置相同
sentinel auth-pass mymaster wstroRedis
## 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步，这个数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
sentinel parallel-syncs mymaster 1
bind 192.168.1.5 127.0.0.1

sentinel采用的也是是集群部署的方式，其他的配置相同，只修改一下logfile、端口port以及bind绑定的数据

摘自

https://www.cnblogs.com/guolianyu/p/10239913.html
https://blog.csdn.net/men_wen/article/details/72724406