1、redis认证实现方法:
(1)通过配置文件redis.conf修改
requirepass PASSWORD #定义连接redis时的密码
(2)通过客户端redis-cli修改
auth PASSWORD #验证密码，PASSWORD为配置文件中requirepass定义的密码
2、redis事务
(1)通过MULTI、EXEC、WATCH等命令实现事务功能:
将一个命令或多个命令归并为一个操作提请服务器按顺序执行的机制
举栗子:
multi #启动(开始)一个事务
…
…
exec #执行(结束)一个事务
(2)watch:乐观锁
在exec命令执行之前，用于监视指定键；如果监视中的某任意键数据被修改，则服务器拒绝执行事务(因为watch是监视数据是否被修改，一旦确认数据被修改，则放弃使用数据，而不是拒绝对方使用数据，所以叫乐观锁)
(3)redis事务与传统关系型数据库的事务最大区别在于:
redis不支持回滚
3、redis持久化:本质上是内存数据库
redis持久化有两种机制:
(1)RDB:快照机制，按事先制定的策略，周期性的将数据保存至磁盘，数据文件默认为dunp.rdb
客户端也可以显式使用save或bgsave命令启动快照保存机制
save:同步，在主线中保存快照，此时会阻塞所有客户端请求
bgsave:异步，bg表示back-ground，后台运行，不会阻塞客户端请求
与rdb相关的配置文件参数:
stop-write-on-bgsave-error yes #出错时停止写入
rdbcompression yes #rdb文件是否执行压缩来节省磁盘空间
rdbchecksum yes #是否对rdb的镜像文件做校验码检测
dbfilename dump.rdb #指明文件名
dir /var/lib/redis #指明rdb文件保存的目录
(2)AOF：append only file的缩写，把redis的每一个操作命令以附加的形式，附加到指定文件的尾部，会导致文件很大。记录每一次写操作至指定的文件尾部实现持久化，当redis重启时，可以通过重新执行文件中的命令在内存中重建数据库。
通过bgrewriteaof来实现aof文件重写，不会读取正在使用的aof文件，而是通过将内存中的数据以命令的方式保存到临时文件中，完成之后替换原来的aof文件
与aof相关的配置文件参数:
appendonly no #没有开启aof功能
appendfilename “appendonly.aof” #文件名
appendfsync always #每次收到写命令就立即写到aof文件
appendfsync everysec #每秒钟写一次(折中的方式)
appendfsync no #不通知内核，内核爱怎么写就怎么写
no-appendfsync-on-write no #重写的时候对新写的操作不做sync操作，而是暂存在内存当中
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64m
aof重写过程:
a.redis主进程通过fork创建子进程
b.子进程根据redis内存中的数据创建数据库重建命令序列于临时文件中
c.父进程继承client的请求，并会把这些请求中的写操作继续追加至原来的aof文件中；额外的，这些新的写请求还会被放置于一个缓冲队列中
d.子进程重写完成，会通知父进程；父进程把缓冲中的命令写到临时文件中
e.父进程用临时文件替换老的aof文件
使用子进程进行AOF重写的问题：
子进程在进行AOF重写期间，服务器进程还要继续处理命令请求，而新的命令可能对现有的数据进行修改，这会让当前数据库的数据和重写后的AOF文件中的数据不一致
如何修正:
为了解决这种数据不一致的问题，Redis增加了一个AOF重写缓存，这个缓存在fork出子进程之后开始启用，Redis服务器主进程在执行完写命令之后，会同时将这个写命令追加到AOF缓冲区和AOF重写缓冲区
即子进程在执行AOF重写时，主进程需要执行以下三个工作：
执行client发来的命令请求；
将写命令追加到现有的AOF文件中；
将写命令追加到AOF重写缓存中。
参考链接:https://blog.csdn.net/hezhiqiang1314/article/details/69396887
备注:
重写本身不能取代备份，还应该指定备份策略，对redis数据库进行定期备份
rdb与aof同时启用的时候:
a.bgsave和bgrewriteaof不会同时执行
b.在redis服务器启动数据恢复时，会优先使用aof
4、复制功能
(1)特点:
a.一个master可以有多个slave
b.支持链式复制
c.master以非阻塞的方式同步数据至salve
(2)主从(配置):
slave
slaveof master_ip master_port
(3)认证
如果master使用requirepass开启了认证功能，从服务器要使用masterauth来连入服务请求来使用此密码进行验证
5、HA高可用
通过sentinel来管理多个redis服务器实现HA
sentinel作用:
(1)用于监视主服务器
(2)实现通知功能(notification)
(3)实现自动故障转移
sentinel协议:
(1)流言协议:接收主服务器是否下线的通知
(2)投票协议:决定哪个服务器成为新的主服务器
sentinel启动:
(1)redis-sentinel /path/to/file.conf
(2)redis-server /path/to/file.conf –sentinel
启动过程:
(1)服务器自身初始化，运行redis-server中专用于sentinel功能的代码
(2)初始化sentinel状态，根据给定的配置文件，初始化监控的master服务器列表
(3)创建指向master的连接
sentinel下线:
(1)主观下线:一个sentinel实例判断出某节点下线
(2)客观下线:多个sentinel节点协商好判断出某节点下线
sentinel专用配置文件:
/etc/redis-sentinel.conf
(1)sentinel monitor mymaster 127.0.0.1 6379 2(2代表投票数)
#多个sentinel的情况下，有2票投票从服务器成为主服务器的话，从服务器就会成为新的主服务器
(2)sentinel down-after-milliseconds mymaster 30000
#30秒找不到主服务器就判断离线
(3)sentinel parallel-syncs mymaster 2
#允许多少个从服务器向主服务器发起同步请求
(4)sentinel failover-timeout mymaster 20
#主服务器发生故障，故障转移超时时间(故障转移超过这个时间，判断故障转移失败)
sentinel专用命令(都以sentinel开头):
sentinel masters:列出所有监视的主服务器
sentinel slaves master_name:获取指定主服务器的从节点
sentinel get-master-addr-by-name master_name:根据name获取master地址
sentinel reset:重置操作
sentinel failover <master_name>:手动执行故障转移操作
sentinel连接:
(1)客户端连接sentinel示例
redis-cli -h ipaddr -p 26379(sentinel默认端口)
(2)客户端连接从节点示例
redis-cli -h ipaddr -p 6380(自定义redis端口)
6、集群
clustering:redis3.0以后支持
分布式数据库，通过分片机制进行数据分析，clustering内的每个节点仅存数据库的一部分数据，也被称作去中心化(每一个节点都可以接入客户请求)。这样，每个节点都持有全局元数据，但仅持有一部分数据
优点:
(1)无中心化，gossip分散式模式
(2)更少的来回次数并降低延迟
(3)自动于多个redis节点进行分片
(4)不需要第三方软件支持协调机制
缺点:
(1)依赖于redis3.0或更高版本
(2)需要时间验证其稳定性
(3)没有后台界面
(4)需要智能客户端
(5)redis客户端必须支持redis cluster架构
