ICode9

精准搜索请尝试: 精确搜索
首页 > 数据库> 文章详细

Redis作为分布式缓存

2021-10-04 15:32:02  阅读:135  来源: 互联网

标签:AOF 缓存 快照 Redis 服务器 持久 重写 分布式


分布式缓存对比
Redis和Memcached 都具备高性能,那我们为什么要选择Redis?
主要有以下几点原因:

  • Redis支持更丰富的数据类型
  • Redis支持数据的持久化,可以将内存中的数据保持在磁盘中,重启的时候可以再次加载进行使用,而 Memecache 把数据全部存在内存之中。
  • Redis 在服务器内存使用完之后,可以将不用的数据放到磁盘上。但是,Memcached 在服务器内存使用完之后,就会直接报异常。
  • Redis原生支持集群模式。
  • Redis拥有丰富的功能:支持发布订阅模型,Lua脚本,事务等功能,而 Memcached 不支持。并且,Redis 支持更多的编程语言。
  • Memcached过期数据的删除策略只用了惰性删除,而 Redis 同时使用了惰性删除与定期删除。

下面就介绍一下redis作为缓存的几种特性:

一. Redis的两种持久化方式

RDB

Redis 创建快照之后,可以对快照进行备份,可以将快照复制到其他服务器从而创建具有相同数据的服务器副本(Redis 主从结构,主要用来提高 Redis 性能),还可以将快照留在原地以便重启服务器的时候使用
快照持久化是 Redis 默认采用的持久化方式,在 Redis.conf 配置文件中默认有此下配置:

save 900 1           #在900秒(15分钟)之后,如果至少有1个key发生变化,Redis就会自动触发BGSAVE命令创建快照。

save 300 10          #在300秒(5分钟)之后,如果至少有10个key发生变化,Redis就会自动触发BGSAVE命令创建快照。

save 60 10000        #在60秒(1分钟)之后,如果至少有10000个key发生变化,Redis就会自动触发BGSAVE命令创建快照。

AOF

与快照持久化相比,AOF 持久化 的实时性更好,因此已成为主流的持久化方案。默认情况下 Redis 没有开启 AOF(append only file)方式的持久化,可以通过 appendonly 参数开启:

appendonly yes

开启 AOF 持久化后每执行一条会更改 Redis 中的数据的命令,Redis 就会将该命令写入硬盘中的 AOF 文件。
由于redis运行,AOF 的文件会越来越大,文件越大,占用服务器内存越大以及 AOF 恢复要求时间越长。为了解决这个问题,Redis新增了重写机制。即读取服务器现有的键值对,然后用一条命令去代替之前记录这个键值对的多条命令,生成一个新的文件后去替换原来的 AOF 文件。这样可以减少内存资源的浪费。
AOF重写带来的问题
1.父进程阻塞问题
由于Redis是单线程的,所以如果 重写 AOF 需要比较长的时间,那么在重写 AOF 期间,Redis将长时间无法处理其他的命令,这是无法忍受的。
Redis为了克服这个问题,将 AOF 重写程序放到子进程中进行,这样有两个好处:

  • 子进程重写期间,父进程可以继续处理其他命令;
  • 因为子进程拥有父进程的数据副本(采用写时复制的技术),可以不使用锁就保证数据的安全性。

2.丢失数据修改问题
为了解决在重写期间丢失的数据修改问题,Redis 服务器设置了一个 AOF 重写缓冲区,这个缓冲区是在创建子进程后开始使用,当Redis服务器执行一个写命令之后,就会将这个写命令也发送到 AOF 重写缓冲区。当子进程完成 AOF 重写之后,就会给父进程发送一个信号,父进程接收此信号后,就会调用函数将 AOF 重写缓冲区的内容都写到新的 AOF 文件中。

RDB-AOF混合持久化方式
在Redis4.0之后,既上一篇文章介绍的RDB和这篇文章介绍的AOF两种持久化方式,又新增了RDB-AOF混合持久化方式。
  这种方式结合了RDB和AOF的优点,既能快速加载又能避免丢失过多的数据。具体配置为:

aof-use-rdb-preamble : yes

当开启混合持久化时,主进程先fork出子进程将现有内存副本全量以RDB方式写入aof文件中,然后将缓冲区中的增量命令以AOF方式写入aof文件中,写入完成后通知主进程更新相关信息,并将新的含有 RDB和AOF两种格式的aof文件替换旧的aof文件。
  简单来说:混合持久化方式产生的文件一部分是RDB格式,一部分是AOF格式。这种模式缺点是不能兼容Redis4.0之前版本的备份文件了。

二、Redis集群模式

理论知识:

  • 主从模式
    Redis 提供了复制(replication)功能实现master数据库中的数据更新后,会自动将更新的数据同步到其他slave数据库上。实现容灾,读写分离(只对主库进行写操作,减轻主库压力)
  • 哨兵模式
    通过发送命令,让 Redis 服务器返回监控其运行状态,包括主服务器和从服务器;
    当哨兵监测到 master 宕机,会自动将 slave 切换成 master ,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让它们切换主机;
  • Cluster 集群模式
    Redis 的哨兵模式基本已经可以实现高可用,读写分离 ,但是在这种模式下每台 Redis 服务器都存储相同的数据,很浪费内存,所以在 redis3.0上加入了 Cluster 集群模式,实现了 Redis 的分布式存储,也就是说每台 Redis 节点上存储不同的内容。
    redis-cluster集群引入了主从复制模型,一个主节点对应一个或者多个从节点,当主节点宕机的时候,就会启用从节点。当其它主节点 ping 一个主节点 A 时,如果半数以上的主节点与 A 通信超时,那么认为主节点 A 宕机了。如果主节点 A 和它的从节点 A1 都宕机了,那么该集群就无法再提供服务了。

标签:AOF,缓存,快照,Redis,服务器,持久,重写,分布式
来源: https://blog.csdn.net/qq_43350702/article/details/120260601

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有