redis核心

笔记

 
 Redis持久化
 
  • RDB
在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是Snapshot快照,它恢复时是将快照文件直接读到内存里.
Redis会单独创建一个(fork)子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件.整个过程中,主线程是不进行任何IO操作的.这就确保了极高的性能.如果需要进行大规模的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效.RDB的企鹅点是最后一次持久化的数据可能丢失.我们默认的就是RDB,一般情况下不许要修改这个配置.
 
在主从复制中,rdb就是用来备份的.
 
触发机制:
1.save的规则满足的情况下,会自动触发rdb规则
2.执行flushall命令,也会触发我们的rdb规则
3.退出redis,也会产生edb文件
备份就自动生成一个dump.rdb
 
如果恢复rdb文件?
1.只需要将rdb文件放在我们redis启动目录就可以,redis启动的时候会自动检查dump.rdb恢复其中的数据.
2.查看需要存放的位置
config get dir    # 如果在这个目录下存在dump.rdb文件,启动就会自动恢复其中的数据
 
默认的配置几乎就够用了
 
rdb的优点:
  1. 适合大规模的数据恢复!dump.rdb.
  2. 对数据的完整性要求不高.
rdb的缺点:
  1. 需要一定的时间间隔进程操作!如果redis意外宕机了,这个最后一次修改数据就没有了
  2. fork进程的时候,会占用一定的内存空间
  • AOF
将我们的所有命令都记录下来.
 
 
以日志的形式来记录每个写操作,将Redis执行过的所有指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话,就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作.
默认是不开启的,需要手动设置
appendonly yes        就开启了aof(需要重启redis)
 
如果aof文件错误,redis启动不起来,我们需要修复
redis-check-aof --fix appendonly.aof
 
重写规则:
如果aof文件大于64m,太大了,fork用一个新的进程来将我们的文件进行重写.
 
aof的优点
  1. 每一次修改都同步,文件的完整会更加好.
  2. 每秒同步一次,可能会丢失一秒的数据.
  3. 从不同步,效率高.
 
缺点
  1. 相对于数据文件来说,aof远远大于rdb,修复的速度也比rdb慢.
  2. aof运行效率也要比rdb慢,所以我们redis默认的配置就是rdb持久化.
 
扩展:
  1. RDB持久化方式能够在指定的时间间隔内对你的数据进行快照存
  2. AOF持久化方式记录每次服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以Redis协议追加保存每次写的操作到文件结尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大.
  3. 只做缓存,如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化.
  4. 同时开启两种持久化方式
  • 在这种情况下,当redis重启的时候回优先载入aof文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
  • RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件,那要不要只使用AOF呢?建议不要,因为RDB更适合用于备份数据库(AOF在不断变化不好备份),快速重启,而且不会有AOF可能存在的Bug,留着作为一个万一的手段.
 性能建议
  • 因为RDB文件只用作后备用途,建议只在Slave上持久化RDB文件,而且只要15分钟备份一次就够了,只保留save 900 1这条规则.
  • 如果Enable AOF,好处是在恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只load自己的AOF文件就可以了,代价一是带来了持续的IO,而是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的.只要硬盘许可,应该尽量减少AOF rewrite的频率,AOF重写的期初大小默认值64M太小了,可以设到5G以上,默认超过原大小100%大小重写可以改到适当的数值.
  • 如果不Enable AOF,仅靠Master-Slave Repllcation实现高可用性也可以,能省掉一大笔ID,也减少了rewrite时带来的系统波动,代价是如果Master/Slave同时倒掉,会丢失十几分钟的数据,启动脚本也要比较两个Master/Slave中的RDB文件,载入较新的那个,微博就是这种架构.
 
 
3.Redis发布订阅
Redis发布订阅(pub/sub)是一种消息通信模式:发送者(pub)发送信息,订阅者(sub)接收消息.微信,微博,关注系统.
Redis客户端可以订阅任意数量的频道.
 
1.消息发送者
2.频道
3.消息订阅者
 
 
 
 
订阅一个或多个频道        subscribe 频道 ...
127.0.0.1:6379> subscribe gg
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "gg"
3) (integer) 1
 
 
127.0.0.1:6379> publish gg "this a message"    发布者发布消息到频道
(integer) 1
127.0.0.1:6379> publish gg "hello redis"        
(integer) 1
 
 
1) "message"                   信息
2) "gg"                        来自哪个频道
3) "this a message"            频道信息
1) "message"
2) "gg"
3) "hello redis"
 
 
使用场景:
1.实时消息系统
2.实时聊天(频道当做聊天室,将信息回显给所有人即可)
3.订阅,关注系统都是可以的
 
复杂的场景我们就会使用消息中间件MQ
 
 
Redis主从复制
  主从复制,是指将一台Redis服务器的数据,复制到其他的Redis服务器.前者称为主节点,后者称为从节点;数据的复制是单向的,只能从主节点到从节点.Master以写为主,Slave以读为主.
默认情况下,每台Redis服务器都是主节点;且一个主节点可以有多个从节点(或没有从节点),但一个从节点只能有一个主节点.
 
主从复制的作用主要包括:
  1. 数据冗余:主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式.
  2. 故障恢复:当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复;实际上是一种服务的冗余.
  3. 负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务(即写Redis数据时应用连接主节点,读Redis数据是应用连接从节点),分担服务器负载;尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大大提高Redis服务器的并发量
  4. 高可用基石:除了上述作用以外,主从复制还是哨兵和集群能够实施的基础,因此说主从复制是Redis高可用的基础.
 
主从复制,读写分离!减缓服务器压力,架构中经常使用
 
环境配置
 只配置从库,不配置主库
 
127.0.0.1:6379> info replication    查看当前库的信息
# Replication
role:master            角色
connected_slaves:0     没有从机
master_replid:7e70152de021cdcfa23f5cf96021009741b8bde3
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
 
1.开启多个redis服务,修改配置文件
port 6379 端口要需要不同
daemonize yes    后台运行,默认为开启
pidfile /var/run/redis_6379.pid    这个也需要不同
logfile ""      指定一个文件,不要空着[6380.log]
dbfilename dump.rdb    修改rdb文件名
 
2.
redis-server         选择开启的配置文件路径
redis-cli -p 6380    连接客户端并指定端口
 
依次开启redis服务(ps -ef|grep) redis 查看进程
 
3.在开启的从机中指定主机
slaveof 127.0.0.1 6379
 
info replication   在从机中可以看到主机信息
info replication   在主机中可以看到从机的信息
 
说明:通过命令设置是暂时的,修改配置文件才能实现永久
 
 
细节:
主机可以写,从机不能写只能读!主机中的所有信息和数据,都会自动被从机保存.
 
主机断开链接,从机依旧链接到主机,但是没有写操作,这个时候,主机如果回来了,从机依旧可以直接获取到主机写的信息.
 
如果是使用命令行配置的主从,这个时候如果重启了,从机就会变会主机.只要变为从机,立马就会从主机中获取值.
 
复制原理:
 1.Slave启动成功链接到master后会发送一个sync命令
 2.Master接到命令,启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令,在后台进程执行完毕之后,master将传送整个数据文件到slave,并完成一次完全同步.
 全量复制:而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中.
 增量复制:Master继续将新的收集到的修改命令依次传给slave,完成同步.但是只要是重新连接master,依次完全同步(全量复制)将被自动执行.
 
 
层层链路(主从方式2)
上一个主节点链接下一个从节点
 
如果没有老大了,这个时候我们能不能自己当老大,手动实现..
谋朝篡位
slaveof no one    使自己成为主节点
 
如果主机断开了链接,我们可以使用slaveof no one让自己变成主机!其他的节点就可以手动连接到最新的这个主节点(手动).如果这个时候老大修复了,那就重新连接!
 
 
哨兵模式
 自动选举老大的模式
    主从切换技术的方式是:当服务器宕机后,需要手动吧一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不能可用.这不是一种推荐的方式,更多时候,我们优先考虑哨兵模式.Redis从2.8开始正式提供了Sentinel(哨兵)架构来解决这个问题.
谋朝篡位自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库.
    哨兵模式是一种特殊的模式,首先Redis提供了哨兵命令.哨兵是一个独立的进程,作为进程,它会独立运行,其原理是哨兵通过发送命令等待Redis服务器响应,从而监控运行多个Redis实例.
 
 
 
 
假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行failover过程,仅仅是哨兵1主观认为注服务器不可用,这个现象称为主观下线.当后面的哨兵也检测到主服务器不可用.并且数量达到一定值时,那么哨兵之间就会进行一次投票,投票的结果由一个哨兵发起,进行failover故障转移操作.切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从服务器实现切换主机,这个过程称为客观下线.
 
1.配置哨兵配置文件
新建一个sentinel.conf
sentinel monitor 被监控的名称 host port 1
sentinel monitor myredis 127.0.0.1 6379 1
 
数字1代表主机挂了,从机投票让谁成为主机,票数最多的就会成为主机.
 
2.开启哨兵模式
redis-sentinel sentinel.conf
 
优点:
1.哨兵集群,基于主从复制模式,所有的主从配置优点,它全有
2.主从可以切换,故障可以转移,系统的可用性就会更好
3.哨兵模式就是主从模式的升级,手动到自动,更加健壮
 
缺点:
1.Redis不好在线扩容.集群容量一旦达到上限,在线扩容就十分麻烦.
2.实现哨兵模式的配置其实是很麻烦的,里面有很多选择.
 
 
Redis缓存穿透和雪崩
 
缓存穿透(查不到):
 概念:用户想要查询一个数据,发现redis内存数据库没有,也就是缓存没有命中,于是向持久层数据库查询.发现也没有,于是本次查询失败.当用户很多的时候,缓存都没有命中,于是都去请求了持久层数据库.这会给持久层数据库造成很大的压力,这时候,就相当于出现了缓存穿透.
 
解决:
 1.布隆过滤器
布隆过滤器是一种数据结构,对所有可能查询的参数以hash形式存储,在控制层先进行校验,不符合丢弃,从而避免了对底层存储系统的查询压力.
 
 2.缓存空对象
当存储层不命中后,即使返回的空对象也将其缓存起来,同时设置一个过期时间,之后再访问这个数据将会从缓存中获取,保护了后端数据源.
 
缓存空对象存在的问题:
 1.如果空值能够被缓存起来,这就意味着缓存需要更多的空间存储更多的键,因为这当中可能会有很多的空值的键;
 2.即使对空值设置了过期时间,还是存在缓存层和存储层的数据会有一段时间窗口的不一致,这对于需要保持一致性的业务会有影响.
 
缓存击穿(量太大,缓存过期):
 这里需要注意和缓存穿透的区别.
 缓存击穿,是指一个key非常热点,在不听的扛着大并发,大并发中对这个一个点进行访问,当这个key在失效的瞬间,持续的大并发就穿破缓存,直接请求数据库,就像一个屏障上凿开了一个洞.
 大概某个key在过期的瞬间,有大量的请求并发放稳,这类数据一般是热点数据,由于缓存过期,会同时访问数据库来查询最新数据,并且会写缓存,会致使数据库瞬间压力过大.
 
解决方案:
 设置热点数据永不过期
  从缓存层面来看,没有设置过期时间,所以不会出现热点key过期后产生的问题.
 加互斥锁
  分布式锁:使用分布式锁,保证对每个key同时只有一个线程去查询后端服务,其他线程没有获得分布式锁的权限,因此只需要等待即可.这种方式将高并发的压力转移到了分布式锁,因此对分布式锁的考验很大.
 
缓存雪崩:
 概念:缓存雪崩是指在某一个时间段,缓存几种过期失效.Redis宕机!
 
 产生雪崩的原因之一,比如双十二零点,即将迎来一波抢购,这波商品时间比较集中的放回了缓存.假设缓存一个小时,那么到了凌晨一点钟的时候,这批商品的缓存就过期了.而对这批商品的访问查询,都落到了数据库上,对数据库而言,就会产生周期性的压力波峰.于是所有的请求都会达到存储层,存储层的代用会暴增,造成存储层也会挂掉的情况.
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
posted @ 2021-04-11 10:25  G-G  阅读(49)  评论(0)    收藏  举报