Redis高级应用

1.redis密码防护

        给redis服务器设置密码，可以通过redis的配置文件设置密码参数，这样客户端连接到redis服务就需要密码验证，这样可以保护redis服务；

（1）：查看是否设置了密码验证：

config get requirepass
1) "requirepass"
2) ""

（2）：通过以下命令来修改该参数：

> config set requirepass "123"
ok
> config get requirepass
(error) NOAUTH Authentication required.

        设置密码验证后必须验证才能进行其他操作：

127.0.0.1:6379> AUTH 123 OK
127.0.0.1:6379> CONFIG GET requirepass 
1) "requirepass" 
2) "123"

#：注意命令设置仅在当前生效，重启服务后失效。

127.0.0.1:6379> quit 
[root@localhost ~]# systemctl restart redis 
[root@localhost ~]# redis-cli 
127.0.0.1:6379> CONFIG GET requirepass 
1) "requirepass" 
2) ""

#：永久生效需要在配置文件中设置，并重启服务。

vim /etc/redis.conf 

requirepass 123456 

[root@localhost ~]# systemctl restart redis

2. 数据持久化

        redis为了数据的完整性和持久性，要将内存中的数据同步到磁盘中，这个过程称为持久化操作，下次再启动redis服务时，会把磁盘上面保存的数据重新加载到内存里面。

（1）：常见的持久化方式：

        RDB:基于快照的方式，redis安装一定的周期把内存里面的数据同步到磁盘文件里面。

        可查看配置文件中的持久化实践，一般时间为：

# Save the DB to disk.
#
# save <seconds> <changes>
#
# Redis will save the DB if both the given number of seconds and the given
# number of write operations against the DB occurred.
#
# Snapshotting can be completely disabled with a single empty string argument
# as in following example:
#
# save ""
# save 3600 1
# save 300 100
# save 60 10000

        AOF:基于文件追加，redis会把对redis数据造成更改的命令记录到相关的日志文件里面，然后再一次重启，换行日志文件里面对redis写的操作，达到数据还原。

        先在配置文件中开启持久化：

# Please check https://redis.io/topics/persistence for more information.

appendonly yes            //开启持久化

# The name of the append only file (default: "appendonly.aof")

appendfilename "appendonly.aof"             // 持久化日志

        备份周期：

# appendfsync always
appendfsync everysec
# appendfsync no

appendfsync always 
//每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用

appendfsync everysec 
//每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐

appendfsync no //完全依赖os，性能最好,持久化没保证

3.主从同步

1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗 余。

3. 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写 Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。

4. 读写分离：可以用于实现读写分离，主库写、从库读，读写分离不仅可以提高服务器的负载能力，同时可 根据需求的变化，改变从库的数量；

5. 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高

 redis主从复制过程：

        例如，设置192.168.188.127为主服务器，设置192.168.188.128为从服务器，进行如下配置，在redis.conf中；

        主服务器：

bind 192.168.188.127

        从服务器配置：

bind 192.168.188.128

slaveof 192.168.188.127 6379        // 新版本中也可能replica

//主服务器有密码还需要配置如下：
masterauth 6379

        测试主从：

127：
set key "hello"

128
get key

4.哨兵模式（sentinel）

        Sentinel 哨兵是 redis 官方提供的高可用方案，可以用它来监控多个 Redis 服务实例的运行情况。

        Redis Sentinel 是一个运行在特殊模式下的 Redis 服务器。

        Redis Sentinel 是在多个 Sentinel 进程环境 下互相协作工作的。

哨兵的三种功能：

        1：监控：Sentinel 不断的检查主服务和从服务器是否按照预期正常工作。

        2：提醒：被监控的 Redis 出现问题时，Sentinel 会通知管理员或其他应用程序。    

        3：自动故障转移：监控的主 Redis 不能正常工作， Sentinel 会开始进行故障迁移操作。将一个从服务器升级新的主服务器。 让其他从服务器挂到新的主服务器。同时向客户端提供新的主服务器地址。

高可用 Sentinel 哨兵配置：

        哨兵作为对redis 实例的监控，通过选举算法保证哨兵的鲁棒性和高可用，所以哨兵至少要部署 3 台，符 合半数原则，需要5 或者 7 ，超过一半，不包含一半存活的时候，才能够选举出 leader ，才能进行主从的 切换功能。

        redis服务，至少需要存活一台，才能保证服务正常运行 sentinel ，选择新 master 的原则是最近可用且 数据最新且优先级最高且活跃最久

        

哨兵高可用测试：

        分别连接对应的redis服务端，手动停止哨兵，停止主 reids 服务，看主从是否切换成功。

        三哨兵情况：redis 实例挂掉两台，剩下一台能够成为主，自动切换

哨兵系统的搭建过程，有几点需要注意：

（1）哨兵系统中的主从节点，与普通的主从节点并没有什么区别，故障发现和转移是由哨兵来控制和 完成的。

（2）哨兵节点本质上是 redis 节点。

（3）每个哨兵节点，只需要配置监控主节点，便可以自动发现其他的哨兵节点和从节点。

（4）在哨兵节点启动和故障转移阶段，各个节点的配置文件会被重写 (config rewrite) 。

（5）一个哨兵可以只监控了一个主节点；实际上，一个哨兵可以监控多个主节点，通过配置多条 sentinel monitor即可实现。

参考配置文件 ：

bind 192.168.188.127

# 是否为守护进程

daemonize yes

#：持久化

appendonly yes

pidfile "/var/run/redis/redis-sentinel.pid"

logfile "/var/log/redis/redis-sentinel.log"

bind 127.0.0.1

port 26379

# 工作目录

dir "/var/lib/redis"

# 声明该哨兵的主库是 mymaster ，主库的 ip 和端口分别为 127.0.0.1 和 6379

# 最后一个 2 的含义是，在哨兵发生领导选举时，该哨兵需要获得 2 票才能成为 leader

sentinel monitor mymaster 127.0.0.1 6379 2

# 在 mymaster 宕机 30 秒后进行主观下线

sentinel down-after-milliseconds mymaster 30000

# 指定在发生 failover 故障转移时最多可以有 1 个 slave 同时对新的 master 进行同步

sentinel parallel-syncs mymaster 1

# 设置故障转移超时时间为 180 秒

# 这个参数的意义比较复杂，详细可以参考官方的注释说明

sentinel failover-timeout mymaster 180000

# 发现两个从节点

sentinel known-slave mymaster 127.0.0.1 6380

sentinel known-slave mymaster 127.0.0.1 6381

#epoch 实现类似版本号的功能

sentinel current-epoch 0

配置完成后：scp sentinel.conf到从服务器，

 5.发布订阅

- 发布者不是计划发送消息给特定的接收者（订阅者），而是发布的消息分到不同的频道，不需要知道什么样 的订阅者订阅。

- 订阅者对一个或多个频道感兴趣，只需接收感兴趣的消息，不需要知道什么样的发布者发布的。

- 发布者和订阅者的解耦合可以带来更大的扩展性和更加动态的网络拓扑。

- 客户端发到频道的消息，将会被推送到所有订阅此频道的客户端。

- 客户端不需要主动去获取消息，只需要订阅频道，这个频道的内容就会被推送过来。

消息的格式：

- 推送消息的格式包含三部分；

- part1: 消息类型，包含三种类型；

- subscribe ，表示订阅成功；

- unsubscribe ，表示取消订阅成功；

- message ，表示其它终端发布消息；

- 如果第一部分的值为 subscribe ，则第二部分是频道，第三部分是现在订阅的频道的数量；

- 如果第一部分的值为 unsubscribe ，则第二部分是频道，第三部分是现在订阅的频道的数量，如果为 0 则表示当前没有订阅任何频道，当在Pub/Sub 以外状态，客户端可以发出任何 redis 命令；

- 如果第一部分的值为 message ，则第二部分是来源频道的名称，第三部分是消息的内容；

// 订阅

SUBSCRIBE 频道名称 [频道名称 ...]

// 取消订阅

UNSUBSCRIBE 频道名称 [频道名称 ...]

// 发布

PUBLISH 频道 消息

127.0.0.1:6379> PUBLISH chan1 "hello redis" 
(integer) 1 
127.0.0.1:6379> SUBSCRIBE chan1 Reading messages... 
(press Ctrl-C to quit) 
1) "subscribe" 
2) "chan1" 
3) 
(integer) 1 
1) "message" 
2) "chan1" 
3) "hello redis"

6.事物

Redis 事务可以一次执行多个命令， 并且带有以下两个重要的保证：

▪ 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程 中，不会被其他客户端发送来的命令请求所打断。

▪ 事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

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

▪ 开始事务。 multi

▪ 命令入队。

▪ 执行事务。

// master

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set k3 bbb
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
127.0.0.1:6379>

// slave

127.0.0.1:6379> keys *
1) "k3"
2) "k2"
3) "k1"
127.0.0.1:6379> get k3
"bbb"
127.0.0.1:6379>

// master

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set k4 ddd
QUEUED 
127.0.0.1:6379(TX)> discard
OK
127.0.0.1:6379> keys *
1) "k1"
2) "k3"
3) "k2"
127.0.0.1:6379> 

// slave

127.0.0.1:6379> keys *
1) "k3"
2) "k2"
3) "k1"
127.0.0.1:6379> 

 7.多数据库

redis 也是有数据库的，默认已经创建好，一共有 16 个，分别为 0 ， 1 ， 2 ， ...15

redis 默认数据操作是在 0 号数据库上。

数据库和数据库之间不能共享键值对。

切换数据库

select 1 // 切换到 1 号数据库

把键值移到指定数据库

move address 0 // 假定当前为 1 号数据库，将 1 号数据库 address 移到 0 号数据库

清空当前数据库： flushdb

清空服务器所有数据库： flushall

注意：清空数据库慎用！！！