共计 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增量式补全，冷备热备一起上才是王道！
正文完
