常见的Redis面试"刁难"问题-附个人实操

之前在某个公众号下看到老钱的一篇文章，题目是《十个常见的Redis面试“刁难”问题》，感觉写的很好，不过里面的解答对于我这种小白来说并不是很全面，所以在这里实际操作、思考一番，并把自己的所得简单记录下来。

原文参考：https://mp.weixin.qq.com/s/Z4a8wbWvPDGFTkKJH0X9VQ

key需要设置同一时间过期，一般需要注意什么？

如果大量的key过期时间设置的过于集中，到过期的那个时间点，redis可能会出现短暂的卡顿现象。一般需要在时间上加一个随机值，使得过期时间分散一些。

—主动扫描并删除，redis是单线程，确实容易出现卡顿现象，响应外部请求缓慢。

Redis如何做持久化的？

bgsave做镜像全量持久化，aof做增量持久化。因为bgsave会耗费较长时间，不够实时，在停机的时候会导致大量丢失数据，所以需要aof来配合使用。在redis实例重启时，优先使用aof来恢复内存的状态，如果没有aof日志，就会使用rdb文件来恢复。

bgSave：一个命令，也就是back ground save，会fork出一个子进程，先将内存中数据写入到临时文件，然后再替换原有文件，用二进制压缩存储。也称为RDB持久化，实时性不高。

AOF：append on file，将所有写操作都记录到日志文件，然后再写入到磁盘。实时性较高。

如果再问aof文件过大恢复时间过长怎么办？你告诉面试官，Redis会定期做aof重写，压缩aof文件日志大小。如果面试官不够满意，再拿出杀手锏答案，Redis4.0之后有了混合持久化的功能，将bgsave的全量和aof的增量做了融合处理，这样既保证了恢复的效率又兼顾了数据的安全性。这个功能甚至很多面试官都不知道，他们肯定会对你刮目相看。

如果对方追问那如果突然机器掉电会怎样？取决于aof日志sync属性的配置，如果不要求性能，在每条写指令时都sync一下磁盘，就不会丢失数据。但是在高性能的要求下每次都sync是不现实的，一般都使用定时sync，比如1s1次，这个时候最多就会丢失1s的数据。

Pipeline有什么好处，为什么要用pipeline？

可以将多次IO往返的时间缩减为一次，前提是pipeline执行的指令之间没有因果相关性。使用redis-benchmark进行压测的时候可以发现影响redis的QPS峰值的一个重要因素是pipeline批次指令的数目。

除了mget mset之外，可以使用pipeline将多个指令打包在一起传输到redis-server执行。减少多次IO交互，提高执行效率。

pipeline.incr(…) （多次执行）

pipeline.sync()

Redis的同步机制了解么？

Redis可以使用主从同步，从从同步。第一次同步时，主节点做一次bgsave，并同时将后续修改操作记录到内存buffer，待完成后将rdb文件全量同步到复制节点，复制节点接受完成后将rdb镜像加载到内存。加载完成后，再通知主节点将期间修改的操作记录aof同步到复制节点进行重放就完成了同步过程。

是否使用过Redis集群，集群的原理是什么？

Redis Sentinal着眼于高可用，在master宕机时会自动将slave提升为master，继续提供服务。

Redis Cluster着眼于扩展性，在单个redis内存不足时，使用Cluster进行分片存储。