redis面试：redis单副本&&多副本

介绍下redis单副本

redis单福本，采用单个redis节点部署架构，没有备用节点实时同步数据，不提供数据持久化和备份策略，适用于数据可靠性要求不高的纯缓存业务场景。

优点：

• 架构简单，部署方便
• 高性价比：缓存使用时无需备用节点（单实例可用性可以用supervisor或crontab保证），当然为了满足业务的高可用性，也可以牺牲一个备用节点，但同时刻只有一个实例对外提供服务
• 高性能

缺点：

• 不保证数据的可靠性
• 在缓存使用，进程重启后，即使由备用的节点解决高可用性，但是仍然不能解决缓存预热的问题，因此不适合数据可靠性要求高的业务
• 高性能受限于单核CPU的处理能力(redis是单线程机制)，CPU成为主要瓶颈，所以适合操作命令简单、排序、计算较少的场景。也可以考虑用memcached替代

介绍下redis多副本

redis多副本，采用主从(replication)部署架构，相较于单副本而言最大的特定就是主从实例间数据实时同步，并且提供数据持久化和备份策略。主从实例部署在不用物理服务器上，根据公司的基础环境配置，可以实现同时对外提供服务和读写分离策略

优点：

• 高可靠性：
  • 一方面，采用双机主备架构，能够在主库出现故障的时候自动进行主备切换，从库提升为主库提供服务，保证服务平稳运行；
  • 另一方面，开启数据持久化功能和配置合理的备份策略，能有效的解决数据误操作和数据异常丢失的问题

缺点：

• 故障恢复复杂，如果没有RedisHA系统（需要开发），当主库节点出现故障时，需要手动将一个从节点晋升为主节点，同时需要通知业务方变更配置，并且需要让其他重复节点去复制新主库节点，整个过程需要认为干预，比较繁琐
• 主库的写能力受到单机的限制，可以考虑分片
• 主库的存储能力受到单机的限制，可以考虑Pika；
• 原生复制的弊端在早期的版本中会比较突出，比如：redis复制中断后，slave会发起psync，此时如果同步不成功，则会进行增量同步，主库提前执行全量备份的同时可能会造成毫秒或者秒级的卡顿；又由于COW机制，导致极端情况下的主库内存会溢出，程序异常退出或者宕机；主库节点生成备份文化导致服务器磁盘IO和CPU(压缩)资源消耗；发送数GB大小的备份文件会导致服务器出口带宽暴增，阻塞请求；建议升级到最新版本