微服务分布式架构之redis篇

最新推荐文章于 2024-09-26 08:00:00 发布

OneMoreWhy

最新推荐文章于 2024-09-26 08:00:00 发布

阅读量680

点赞数

本文链接：https://blog.csdn.net/OneMoreWhy/article/details/107746313

版权

本文深入探讨了Redis的慢操作及其解决方案，包括哈希冲突、集合操作和列表时间复杂度。介绍了Redis单线程快速的原因，如内存数据库、非阻塞IO多路复用和hash表使用。讨论了数据持久化方法RDB和AOF，以及如何在RDB和AOF之间做出选择。此外，文章还涉及Redis的主从复制、哨兵模式、数据恢复和故障切换。对于数据增长，提出了分片集群的解决方案，讨论了缓存满、击穿、穿透和雪崩问题的处理。最后，文章提到了Redis的分布式锁、并发竞争、布隆过滤器和Redis 6.0的新特性。

摘要由CSDN通过智能技术生成

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

                