目录
1.redis配置文件
特点1.对大小写不敏感
1.1网络配置
bind 127.0.0.1 -::1 #绑定ip 默认开启只允许本地访问
protected-mode yes #保护模式 默认开启
port 6379 #端口设置
1.2通用配置
daemonize yes #是否开启守护进程 默认是no 开启后台运行
pidfile /var/run/redis_6379.pid #如果以后台方式运行，需要一个pid文件
#日志文件
# Specify the server verbosity level.
# This can be one of:
# debug (a lot of information, useful for development/testing)
# verbose (many rarely useful info, but not a mess like the debug level)
# notice (moderately verbose, what you want in production probably)
# warning (only very important / critical messages are logged)
loglevel notice
logfile "" #生成的文件位置
databases 16 #数据库的数量
always-show-logo no #是否显示logo1.3快照
持久化、在规定的时间内，执行多少次操作会持久化文件rdb.aof文件种
redis是内存数据库，如果没有持久化就会断电缺失
#在3600s内如果至少有一次修改，就会进行持久化操作
save 3600 1
#在300秒内如果进行至少100次修改就会持久化操作
save 300 100
save 60 10000
#持久化出错了是否需要继续工作
stop-writes-on-bgsave-error yes
#是否rdp文件 消耗cpu资源
rdbcompression yes
#保存rdb文件，的时候进行错误检查校验
rdbchecksum yes
#rdb文件保存目录
dir ./1.4主从复制
1.5安全
1）配置文件修改密码
2）命令行设置密码
#登录 默认没有密码
auth 密码
#获取密码
config get requirepass
#设置相应的密码 可以设置为空
config set requirepass "密码"
1.6客户端限制
#连接的最大数量 10000万
maxclients 10000
#最大内存容量
maxmemory <bytes>
#内存满了的淘汰策略
maxmemory-policy noeviction
#淘汰策略有 默认noeviction
no-eviction：不删除策略
allkeys-lru key少的淘汰
volatile-lru 最近最少使用的淘汰
allkeys-random 随机淘汰
volatile-random 在设置expire的key种随机淘汰
volatile-ttl 删除即将过期
noeviction 永不过期，返回错误
1.7aof配置
############################## APPEND ONLY MODE ###############################
appendonly no #默认不开启，默认使用rdb完全够用
appendfilename "appendonly.aof" #持久化文件名字
# appendfsync always #每次丢该都会sync消耗性能
appendfsync everysec #每秒执行一次 可能丢失1s数据，
# appendfsync no #不执行sync这个操作系统自己同步数据 速度最快2.redis持久化
2.1RDB
单独开启一个子进程进行持久化，然后把数据写入一个临时的文件，持久化结束用临时的文件代替原来的文件 dumb.rdb
优点：1.效率比aof高2.数据恢复3.对数据完整性不高
缺点：1.最后替换文件如果宕机会导致数据丢失，需要操作间隔
触发机制
1.save的规则班组的情况，自动触发
2.执行flushall命令，也会触发rdb规则
3.退出redis也会产生rdb文件
回复rdb文件
1.把rdb文件放在redis驱动目录，redis启动的时候对自动减产dump.rdb自动恢复
2.2AOF
原理
把所有命令记录下来，然后把恢复数据的时候把曾经操作的命令重新操作一遍进行恢复数据
默认关闭
如果aof文件有错误，这时候redis是启动不起来的，需要修复配置文件
redis-check-aof --fix appendonly.aof
优缺点
优点1.每一次修改都同步，文件完整会更好
2.每秒同步一次，可能会丢失秒数据
3.从不同步效率更高
缺点
1.相对于数据文件来说，aof远远大于rdb，修复的速度比rdb慢
2.Aof运行效率也要比Rdb低
重写规则
如果aof文件超过64mb，则会开启一个新的进程 ，讲文件进行重写
2.主从复制
概念
将一台redis服务器的数据复制到其他redis服务器，前者称为主节点（master/leader）,后者成为节点（salve/follower）;数据重复是单向的，只能从主节点到从节点，Mater以写为住，salve以读主（读写分离），减缓服务器压力，一主二从
默认情况下，每台Redis服务器都是主节点
主从复制的的作用主要包括：
1）数据冗余：主从复制实现了数据的热备份
2）故障备份：当主节点出现问题，可以由从节点提供服务，实现快速恢复故障
3）负载均衡：读写分离提高并发量
4）高可用（集群）基石：是哨兵和集群能够实施的基础。
命令
info replication 查看主从复制的信息
一主二从
默认情况下每台redis服务器都是主节点，一般情况配置从机
命令
SLAVEOF IP地址 端口 当 IP地址和端口的ip地址 ps命令是暂时的
注意
1.主机可以写，从机不能写只能读！主机种的所有信息和数据，都会被从机保存。未配置哨兵之前断了，依旧是从机。
2.主机断开连接，从机依旧可以连接到，但是没有写操作。主机恢复依旧可以
3.从节点第一次连接到主机就会有一次sync同步操作。Slave连接到master后会发送一个sync同步命令，Master接到命令，启动后台的存盘进程，同时接受到用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slace，并完成一次完全同步
全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中
增量复制：在全量复制之后执行的复制，Master继续将新的所有收集到的修改命令一次传递给slave，完成同步
但是只有重新连接master，都会完成一次全量复制（自动执行）。
3.哨兵模式（Sentinel）
简单说就是主服务器宕机后的，集群依旧需要主节点，然后需要在剩下的节点中选出一个主节点。
单哨兵模式
多哨兵模式
主服务器宕机，哨兵1先检查主服务器，系统不会立刻挂掉，哨兵1主管的认为主节点不可以用，·判定为主管下线并且会通知其他的哨兵也来检查，当其他哨兵也检查到主服务不可用并且达到一定的数量的时候，哨兵就会进行一次slave的投票。投票由一个哨兵开启，并把选举的结果选举为新的master，替换到原来的master。这个过程又叫客观下线
哨兵的配置文件
举例
vim sentinel.conf
sentinel monitor 哨兵名称 监控ip地址 1 1表示主机挂了的投票
举例：
sentinel monitor mys 127.0.0.1 6379 1
启动
redis-sentinel sentinel.conf
全配置文件
引用(12条消息) Redis哨兵配置文件详解_程序员小圆的博客-CSDN博客_redis哨兵配置文件详解
# Example sentinel.conf
# *** IMPORTANT ***
# 绑定IP地址
# bind 127.0.0.1 192.168.1.1
# 保护模式（是否禁止外部链接，除绑定的ip地址外）
# protected-mode no
# port <sentinel-port>
# 此Sentinel实例运行的端口
port 26379
# 默认情况下，Redis Sentinel不作为守护程序运行。 如果需要，可以设置为 yes。
daemonize no
# 启用守护进程运行后，Redis将在/var/run/redis-sentinel.pid中写入一个pid文件
pidfile /var/run/redis-sentinel.pid
# 指定日志文件名。 如果值为空，将强制Sentinel日志标准输出。守护进程下，如果使用标准输出进行日志记录，则日志将发送到/dev/null
logfile ""
# sentinel announce-ip <ip>
# sentinel announce-port <port>
#
# 上述两个配置指令在环境中非常有用，因为NAT可以通过非本地地址从外部访问Sentinel。
#
# 当提供announce-ip时，Sentinel将在通信中声明指定的IP地址，而不是像通常那样自动检测本地地址。
#
# 类似地，当提供announce-port 有效且非零时，Sentinel将宣布指定的TCP端口。
#
# 这两个选项不需要一起使用，如果只提供announce-ip，Sentinel将宣告指定的IP和“port”选项指定的服务器端口。
# 如果仅提供announce-port，Sentinel将通告自动检测到的本地IP和指定端口。
#
# Example:
#
# sentinel announce-ip 1.2.3.4
# dir <working-directory>
# 每个长时间运行的进程都应该有一个明确定义的工作目录。对于Redis Sentinel来说，/tmp就是自己的工作目录。
dir /tmp
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
#
# 告诉Sentinel监听指定主节点，并且只有在至少<quorum>哨兵达成一致的情况下才会判断它 O_DOWN 状态。
#
#
# 副本是自动发现的，因此您无需指定副本。
# Sentinel本身将重写此配置文件，使用其他配置选项添加副本。另请注意，当副本升级为主副本时，将重写配置文件。
#
# 注意：主节点（master）名称不能包含特殊字符或空格。
# 有效字符可以是 A-z 0-9 和这三个字符 ".-_".
sentinel monitor mymaster 127.0.0.1 6379 2
# 如果redis配置了密码，那这里必须配置认证，否则不能自动切换
# Example:
#
# sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
# sentinel down-after-milliseconds <master-name> <milliseconds>
#
# 主节点或副本在指定时间内没有回复PING，便认为该节点为主观下线 S_DOWN 状态。
#
# 默认是30秒
sentinel down-after-milliseconds mymaster 30000
# sentinel parallel-syncs <master-name> <numreplicas>
#
# 在故障转移期间，多少个副本节点进行数据同步
sentinel parallel-syncs mymaster 1
# sentinel failover-timeout <master-name> <milliseconds>
#
# 指定故障转移超时（以毫秒为单位）。 它以多种方式使用：
#
# - 在先前的故障转移之后重新启动故障转移所需的时间已由给定的Sentinel针对同一主服务器尝试，是故障转移超时的两倍。
#
# - 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
#
# - 取消已在进行但未生成任何配置更改的故障转移所需的时间
#
# - 当进行failover时，配置所有slaves指向新的master所需的最大时间。
# 即使过了这个超时，slaves依然会被正确配置为指向master。
#
# 默认3分钟
sentinel failover-timeout mymaster 180000
# 脚本执行
#
# sentinel notification-script和sentinel reconfig-script用于配置调用的脚本，以通知系统管理员或在故障转移后重新配置客户端。
# 脚本使用以下规则执行以进行错误处理：
#
# 如果脚本以“1”退出，则稍后重试执行（最多重试次数为当前设置的10次）。
#
# 如果脚本以“2”（或更高的值）退出，则不会重试执行。
#
# 如果脚本因为收到信号而终止，则行为与退出代码1相同。
#
# 脚本的最长运行时间为60秒。 达到此限制后，脚本将以SIGKILL终止，并重试执行。
# 通知脚本
#
# sentinel notification-script <master-name> <script-path>
#
# 为警告级别生成的任何Sentinel事件调用指定的通知脚本（例如-sdown，-odown等）。
# 此脚本应通过电子邮件，SMS或任何其他消息传递系统通知系统管理员 监控的Redis系统出了问题。
#
# 使用两个参数调用脚本：第一个是事件类型，第二个是事件描述。
#
# 该脚本必须存在且可执行，以便在提供此选项时启动sentinel。
#
# 举例:
#
# sentinel notification-script mymaster /var/redis/notify.sh
# 客户重新配置脚本
#
# sentinel client-reconfig-script <master-name> <script-path>
#
# 当主服务器因故障转移而变更时，可以调用脚本执行特定于应用程序的任务，以通知客户端，配置已更改且主服务器地址已经变更。
#
# 以下参数将传递给脚本：
#
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
#
# <state> 目前始终是故障转移 "failover"
# <role> 是 "leader" 或 "observer"
#
# 参数 from-ip, from-port, to-ip, to-port 用于传递主服务器的旧地址和所选副本的新地址。
#
# 举例:
#
# sentinel client-reconfig-script mymaster /var/redis/reconfig.sh
# 安全
# 避免脚本重置，默认值yes
# 默认情况下，SENTINEL SET将无法在运行时更改notification-script和client-reconfig-script。
# 这避免了一个简单的安全问题，客户端可以将脚本设置为任何内容并触发故障转移以便执行程序。
sentinel deny-scripts-reconfig yes
# REDIS命令重命名
#
#
# 在这种情况下，可以告诉Sentinel使用不同的命令名称而不是正常的命令名称。
# 例如，如果主“mymaster”和相关副本的“CONFIG”全部重命名为“GUESSME”，我可以使用：
# SENTINEL rename-command mymaster CONFIG GUESSME
# 设置此类配置后，每次Sentinel使用CONFIG时，它将使用GUESSME。 请注意，实际上不需要尊重命令案例，因此在上面的示例中写“config guessme”是相同的。
# SENTINEL SET也可用于在运行时执行此配置。
# 为了将命令设置回其原始名称（撤消重命名），可以将命令重命名为它自身：
# SENTINEL rename-command mymaster CONFIG CONFIG
————————————————
版权声明：本文为CSDN博主「程序员小圆」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/xiaolinzi176/article/details/123166936优点
1.哨兵集群，基于主从复制模式，所有的主从配置优点，相当于主从模式的升级
2.主从可以切换，故障可以转移，系统的可用性就会更好
缺点
1.redis不好在线扩容，集群容量到达上限，在线扩容就会很麻烦
4.Redis缓存穿透和雪崩
4.1缓存穿透
j通俗化讲mysql里面大面积没有查不到内容
造成原因
比如秒杀高并发首次获取数据都到缓存中，缓存中没有就会去数据库进行访问，但是再未访访问钱会有大量的缓存的访问请求。这些大量请求同时访问数据库但是数据库没有就会导致MySQL崩了，
解决办法
1.布隆过滤器
概念:再缓存上面再加一分缓存
2.缓存空对象
概念：在访问mysql的时候没有查到相对应的内容则在缓存中加入一空对象，再次访问就会访问空的对象
存在问题
1）空值存在能够被缓存起来，这意味着缓存需要更多的空间且访问的是没有意义的空值
2）即使对空值设置了过期的时间，但还是存在缓存层和存储层的数据会有一段时间的窗口不一致，对需要保持一致的业务有影响
4.2缓存击穿
通俗讲：查一个key的值量太大了，缓存过期
ttl设置过期时间30秒 恢复时间30.1秒 但是在0.1秒的时候，大量的数据进行访问，导致数据库压力瞬间变法，导致崩掉
解决方案
1.热点数据不过期
但是导致redis内存变大，redis内存满了会清理key会导致数据丢失
2.加互斥锁
每一个key同一个时间只有一个线程去后台查询访问
4.3缓存雪崩
某一个时间段缓存集中过期失效，或者Redis宕机
举例：秒杀
因为很多热点的数据不可能放在数据库中，放在缓存中同一时间失效，时大量的数据访问数据库会导致服务器宕机
解决办法
1）redis的高可用
多开几个redis服务器
2）限流降级
缓存失效后加一个锁或者队列来控制数据库写缓存的线程数量
3）数据预热
在访问之前把可能热点的数据先预先访问一遍，让大量的数据加载到缓存里
182
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
