1、redis密码保护

给 redis 服务器设置密码
可以通过 redis 的配置文件设置密码参数，这样客户端连接到 redis 服务就需要密码验证，这样可以让你的 redis 服务更安全。

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

127.0.0.1:6379> CONFIG GET requirepass
1) "requirepass"
2) ""

通过以下命令来修改该参数

127.0.0.1:6379> CONFIG SET requirepass "123"
OK
127.0.0.1:6379> 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) ""

要永久生效，需要修改配置文件并重启服务。

[root@localhost ~]# vim /etc/redis.conf
requirepass 123456
[root@localhost ~]# systemctl restart redis

客户端登录

[root@localhost ~]# redis-cli -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface
may not be safe.
127.0.0.1:6379> CONFIG GET requirepass
1) "requirepass"
2) "123456"
或
交互模式下使用【auth 密码】 命令
[root@localhost ~]# redis-cli
127.0.0.1:6379> AUTH 123456
OK
127.0.0.1:6379> CONFIG GET requirepass
1) "requirepass"
2) "123456"
127.0.0.1:6379> quit

2、redis数据持久化

2.1 简介

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

常见的持久化方式：

基于快照的方式：

redis安装一定的周期把内存里面的数据同步到磁盘文件里面

基于文件追加：

redis会把对redis数据造成更改的命令记录到日志文件里面，然后再一次重启，执行日志文件里面对redis写的操作，达到数据还原。

2.2 、基于快照的持久化

修改配置文件，开启基于快照的选项
save 900 1 #900秒内如果超过1个key被修改，则发起快照保存
save 300 10 #300秒内容如超过10个key被修改，则发起快照保存
save 60 10000 #60秒内容如超过10000个key被修改，则发起快照保存
#以上是系统默认配置

保持到磁盘上的文件

[root@localhost ~]# egrep "^(dbfilename|dir)" /etc/redis.conf
dbfilename dump.rdb  # 保持文件名称
dir /var/lib/redis # 保持的路径
[root@localhost ~]# cd /var/lib/redis/
[root@localhost redis]# ls
dump.rdb

模拟删除文件，手工保存，重启后查看

[root@localhost redis]# systemctl stop redis
[root@localhost redis]# rm -f dump.rdb
[root@localhost redis]# systemctl start redis
[root@localhost redis]# ls
[root@localhost redis]# redis-cli -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface
may not be safe.
127.0.0.1:6379> set names tom
OK
127.0.0.1:6379> get names
"tom"
127.0.0.1:6379> bgsave
Background saving started
127.0.0.1:6379> quit
[root@localhost redis]# ls
dump.rdb
[root@localhost redis]# systemctl restart redis
[root@localhost redis]# redis-cli -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface
may not be safe.
127.0.0.1:6379> get names
"tom"
127.0.0.1:6379> quit

2.3 、基于文件追加方式持久化

注意：默认没有开启

#appendonly # 基于日志文件追加方式开启持久化
appendonly yes
appendfilename "appendonly.aof" # 日志文件

备份文件周期

# appendfsync always
appendfsync everysec
# appendfsync no

ppendfsync always // 每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不
推荐使用
appendfsync everysec //每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐
appendfsync no //完全依赖os，性能最好,持久化没保证

重启测试

[root@localhost ~]# systemctl restart redis
[root@localhost ~]# ls /var/lib/redis/
appendonly.aof dump.rdb

3 、redis主从同步

主从复制的作用

1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
3. 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
4. 读写分离：可以用于实现读写分离，主库写、从库读，读写分离不仅可以提高服务器的负载能力，同时可根据需求的变化，改变从库的数量；
5. 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

Redis 主从复制过程：

➢ Slave 与 master 建立连接，发送 sync 同步命令
➢ Master 会启动一个后台进程，将数据库快照保存到文件中，同时 master 主进程会开始收集新的写
命令并缓存。
➢ 后台完成保存后，就将此文件发送给 slave
➢ Slave 将此文件保存到硬盘上

一个 master可以拥有多个slave，一个slave又可以拥有多个slave，如此下去，形成了强大的多级服务器集群架构
比如，将 ip为192.168.1.10的机器作为主服务器，将ip为192.168.1.11的机器作为从服务器
设置主服务器的配置

bind 192.168.1.10

设置从服务器的配置
注意：在 slaveof后面写主机ip，再写端口，而且端口必须写

bind 192.168.1.11
slaveof 192.168.1.10 6379

在 master和slave分别执行info命令，查看输出信息：info replication
在 master上写数据

set hello world

在 slave上读数据

get hello

4、哨兵模式

高可用方案：
1、cluster 集群
2、sentinel 哨兵
高可用 Sentinel 哨兵

Sentinel 哨兵是 redis 官方提供的高可用方案，可以用它来监控多个 Redis 服务实例的运行情况。Redis Sentinel 是一个运行在特殊模式下的 Redis 服务器。Redis Sentinel 是在多个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即可实现。

参考配置文件

#是否为守护进程
daemonize 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

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
命令入队。
执行事务。

序号	命令及描述
1	DISCARD 取消事务，放弃执行事务块内的所有命令。
2	EXEC 执行所有事务块内的命令。
3	MULTI 标记一个事务块的开始。
4	UNWATCH 取消 WATCH 命令对所有 key 的监视。
5	WATCH key [key ...] 监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。

7、多数据库

redis也是有数据库的，默认已经创建好，一共有16个，分别为0，1，2，...15
redis默认数据操作是在0号数据库上。
数据库和数据库之间不能共享键值对。

切换数据库
select 1  //切换到1号数据库把键值移到指定数据库
move address 0 //假定当前为1号数据库，将1号数据库address移到0号数据库清空当前数据库：flushdb
清空服务器所有数据库：flushall
注意：清空数据库慎用！！

8、redis的应用场景

8.1 取最新N个数据的操作

比如典型的取你网站的最新文章，通过下面方式，我们可以将最新的5000条评论的ID放在Redis的List集合中，并将超出集合部分从数据库获取
使用LPUSH latest.comments<ID>命令，向list集合中插入数据
插入完成后再用LTRIM latest.comments 0 5000命令使其永远只保存最近5000个ID
然后我们在客户端获取某一页评论时可以用下面的逻辑（伪代码）

FUNCTION get_latest_comments(start,num_items):id_list = redis.lrange("latest.comments",start,start+num_items-1)IF id_list.length < num_itemsid_list = SQL_DB("SELECT ... ORDER BY time LIMIT ...")END
RETURN id_list
END

如果你还有不同的筛选维度，比如某个分类的最新N条，那么你可以再建一个按此分类的List，只存ID的话，Redis是非常高效的。

8.2 排行榜应用，取TOP N操作

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

Redis的命令都是原子性的，你可以轻松地利用INCR，DECR命令来构建计数器系统。

8.3 Uniq 操作，获取某段时间所有数据排重值

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

8.4 实时系统，反垃圾系统

通过上面说到的set功能，你可以知道一个终端用户是否进行了某个操作，可以找到其操作的集合并进行分析统计对比等。没有做不到，只有想不到。

8.5 Pub/Sub 构建实时消息系统

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

8.6 构建队列系统

使用list可以构建队列系统，使用sorted set甚至可以构建有优先级的队列系统。

8.7 缓存

这个不必说了，性能优于Memcached，数据结构更多样化。

8.8 需要精准设定过期时间的应用

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

8.9 计数器应用

redis 高级应用相关推荐

Redis 高级特性（2）—— 发布订阅模式
Redis 高级特性 -- 发布订阅 1. 发布-订阅介绍 "发布-订阅"模式包含两种角色,分别为发布者和订阅者.订阅者可以订阅一个或者若干个频道(channel),而发布者可以向 ...
Redis 高级特性（1）—— 事务过期时间排序
1. Redis 高级特性 -- 事务事务概念 Redis 中的事务 (transaction)是一组命令的集合.事务同命令一样是 Redis 的最小执行单位,一个事务中的命令要么都执行,要么都不执 ...
【Redis】14.Redis高级数据类型Bitmaps、HyperLogLog、GEO
[Redis]14.Redis高级数据类型Bitmaps.HyperLogLog.GEO Bitmaps:用比特位进行快速的状态统计 Bitmaps基本操作 Bitmaps不是一个新的数据类型,而是s ...
Redis学习第八课：Redis高级实用特性（一）
Redis高级实用特性注:我学习的环境是vmware7.1 + ubantu10.10+ redis 3.0.2 1.安全性设置客户端连接后进行任何其他指定前需要的密码.因为redis速度相当快, ...
Redis高级数据结构原理解析-bitmap,hyperloglog
Redis 位图开发过程中,我们可能遇到这种场景记录用户的打卡情况,签到情况,这些场景只有两种结果,有或者没有,加入记录的数据量比较大,比如用一年的数据,如果用Redis中普通key/value,每 ...
redis高级-------2
1 Redis高级 1.1 Redis中持久化策略 1.1.1 Redis持久化规则说明:根据redis的配置文件中所配置的持久化策略,定期持久化.将redis内存中的数据最终写入到持久 ...
redis 经纬度_【SpringBoot DB 系列】Redis 高级特性之 GEO
[SpringBoot DB 系列]Redis 高级特性之 GEO GEO 用于存储地理信息,最直观的就是我们日常使用的地图 app 中,如果我想查询我所在地的周边餐饮,就可以利用 geo 中的以(x ...
【2. Redis 高级数据结构】
Redis 高级数据结构 Bitmaps 现代计算机用二进制(位)作为信息的基础单位,1 个字节等于 8 位,例如"big" 字符串是由 3 个字节组成,但实际在计算机存储时将 ...
第二章 Redis高级
第二章:Redis高级学习目标目标1:能够说出redis中的数据删除策与略淘汰策略目标2:能够说出主从复制的概念,工作流程以及场景问题及解决方案目标3:能够说出哨兵的作用以及工作原理,以及如何 ...
【Redis高级应用总结】
Redis高级 Redis高级应用总结 Redis高级学习目标 1.数据删除与淘汰策略 1.1 过期数据 **1.1.1 Redis中的数据特征** 1.1.2 时效性数据的存储结构 1.2 数据删 ...

redis 高级应用