微服务分布式架构之redis篇

本文深入探讨了Redis的慢操作及其解决方案,包括哈希冲突、集合操作和列表时间复杂度。介绍了Redis单线程快速的原因,如内存数据库、非阻塞IO多路复用和hash表使用。讨论了数据持久化方法RDB和AOF,以及如何在RDB和AOF之间做出选择。此外,文章还涉及Redis的主从复制、哨兵模式、数据恢复和故障切换。对于数据增长,提出了分片集群的解决方案,讨论了缓存满、击穿、穿透和雪崩问题的处理。最后,文章提到了Redis的分布式锁、并发竞争、布隆过滤器和Redis 6.0的新特性。
摘要由CSDN通过智能技术生成
  1. 快速的redis有哪些慢操作?
  • 哈希冲突导致时间复杂度向链表倾斜,拉低查询效率。解决方案:哈希桶rehash。
  • 一次性rehash会导致redis线程阻塞。解决方案:渐进式rehash,其实也是分步、分摊、分治思想。
  • 集合类型的范围操作时间复杂度降为O(n)。解决方案:用SCAN命令代替,渐进式遍历,每次只返回部分数据。
  • list类型由压缩列表和双向链表实现,时间复杂度都是O(n),但是这二者会记录表头和表尾的偏移量,适合用做先进先出的队列使用。
  • 压缩列表与数组的区别是:压缩列表会允许存储数据的每一个元素的容量大小不同。
  1. 为什么单线程的redis能那么快?
  • 内存数据库,内存操作
  • 单线程,无线程上下文切换开销,无锁资源性能开销
  • 采用非阻塞IO多路复用技术
  • hash表的大量使用
  1. 宕机了,redis如何避免数据丢失?
  • 数据持久化,两种方式:RDB和AOF
  • RDB可以在指定的时间段内对数据进行快照存储,方便传输,适用于灾难备份和灾难恢复。fork子进程,备份的工作由子进程来做。redis意外中断时,会丢失数据。数据集大的时候,fork会比较耗时。
  • AOF将每次写的操作追加到文件末尾。AOF更加耐久,fsync策略可以自己设置。文件体积大,速度可能会慢。
  • 在RDB和AOF之间如何抉择?看业务需求,看中什么优点,能接受什么缺点,或者两种方式结合起来用。
  • 可以调用save或者是bgsave命令进行手动备份。
  • 写时复制机制,fork子进程进行修改的过程中使用了写时复制技术。
  • AOF方式可以进行日志重写,优化,简化。
  1. 宕机后,redis如何实现快速恢复?
  • 有了RDB和AOF两种持久化的方式,可以使用备份的文件对redis数据进行恢复。
  1. 主从库如何实现数据一致?
  • redis默认使用异步复制
  • redis复制对于master而言,是非阻塞的。对于slave而言,加载新数据集是阻塞的。
  • 当master关闭了持久化和被允许自动重启的时候,主从复制会面临一个暗坑。master挂机,自动重启,数据集为空,slave同步master的数据集后也变为空数据集。“天下武功,唯快不破”,master的重启可以快到让sentinel检测不到。故即使配置了sentinel高可用,依然避免不了这个坑。所以在master关闭持久化的时候,需要禁止其自动重启。
  • Replication ID, offset,主从之间同步靠的是这两个参数。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值