共计 1222 个字符,预计需要花费 4 分钟才能阅读完成。
都说Redis快,说说为啥快?
最直接的原因,redis存在内存中,mysql/mongodb等数据库存在磁盘
底层原因:
- redis存的是k-v格式的数据,时间复杂度是O(1),而像mysql引擎底层实现是B+Tree,时间复杂度是O(logn),对数阶的。
- redis完全基于内存,绝大部分请求都是纯粹的内存操作
- 采用单进程单线程,没有多进程多线程切换对CPU的消耗,也不存在不必要的上下文切换和竞争条件,没有锁的问题,不存在加锁释放锁的操作,不会出现死锁导致的性能损耗
- redis是单线程多路复用IO,非堵塞IO
既然redis是单线程的,那不是无法充分利用多核CPU?
一个redis实例是单线程的,那么开多个实例就好了
遇到redis的性能瓶颈,如何解决?
可以做搭建集群redis-cluster,主从读写分离,master节点写数据,slave节点读数据,一个master配多个slave,一个slave又可以有多个slave,就可以形成强大的集群架构。
这样整个redis就可以横向扩容了,如果还需要更大的数据量,可以横向扩容更多的master节点。
redis持久化如何实现?
redis持久化是高可用中一个重要的环节,目前有两种机制:
RDB快照
- 对redis中的数据进行周期性的持久化,将内存数据写入dump.rdb二进制文件中
- 原理:底层借助fork函数,将当前进程fork出一个子进程,在子进程中完成数据持久化
- 配置快照:save 900 1/save 300 10/save 60 10000 ,在*秒内至少有*个键被更改进行快照,也可以自定义
AOF
- append only file,追加写入日志文件
- 原理:redis会将每一个写命令通过write函数追加到日志文件中,在redis重启时,会重新执行日志中保存的写命令来在内存中重建数据
- 配置:1. appendfsync no,依赖于操作系统的调试,对于大多数的Linux系统来说,每30秒进行一次fsync;2. appendfsync everysec,每秒进行一个fsync;3. appendfsync always,每一次写操作都进行fsync
两种机制的优缺点
RDB适合做冷备,AOF适合做热备。
RDB持久化缺点:redis停机时,会丢失rdb文件生成点到停机点的数据。优点:1.RDB是一个紧凑的文件,方便传输。2.快照由子进程完成,父进程不要进行IO操作。3.恢复数据比AOF快
AOF缺点:体积大,速度比RDB慢,维护成本高,重建时间长。优点:1.数据更完整;2.redis可以在AOF文件过大时使用BGREWRITEAOF进行重写,使得体积不至于过大;3.保存的日志文件按照redis协议的格式保存,很容易读取
那这两种机制改如何选择呢?
小孩子才做选择,我当然是全都要了。单独用RDB会丢失数据,单独使用AOF恢复速度慢,没办法第一时间恢复。混合使用,先用RDB全量恢复,再用AOF增量式补全,冷备热备一起上才是王道!
正文完