（8）Redis集群

1 谈谈Redis的使用场景和实践策略?

Redis是个KV内存数据库，支持多种数据结构、简单消息队列、磁盘持久化，特点是高性能、使用简单、稳定可靠。常见使用场景如下：
（1） 数据缓存：客户端访问服务器的时候，先检查redis是否有数据，Redis有数据直接反馈给客户端；如果没有数据再请求数据库，查询数据后缓存到Redis，下次就可以直接读Redis。
（2）分布式锁：微服务项目服务部署到不同的服务器上，单体架构的同步锁没办法锁住服务，利用Redis实现分布式锁，常用组件为Redisson。
（3）数据共享：将包含用户信息的令牌存储在Redis中，用户每次访问时从Redis中查询令牌，实现资源的共享，即分布式Session。

常用实践策略：
（1）节省内存：控制 key 的长度；选择合适的数据类型；务必设置过期时间；数据压缩后再写入
（2）高性能：开启 lazy-free 机制；不使用复杂度过高的命令；关注 DEL 时间复杂度；批量命令代替单个命令；避免集中过期 key；使用读写分离 + 分片集群； 不开启 AOF 或 AOF 配置为每秒刷盘
（3）可靠性：按业务线部署实例；部署主从集群；合理配置主从复制参数；部署哨兵集群，实现故障自动切换；
（4）运维：禁止使用 KEYS/FLUSHALL/FLUSHDB 命令； 扫描线上实例时，设置休眠时间；慎用 MONITOR 命令；从库必须设置为 slave-read-only； 合理配置 timeout 和 tcp-keepalive 参数；
（5）安全：不要把 Redis 部署在公网可访问的服务器上；部署时不使用默认端口 6379；以普通用户启动 Redis 进程，禁止 root 用户启动；限制 Redis 配置文件的目录访问权限；推荐开启密码认证；禁用/重命名危险命令（KEYS/FLUSHALL/FLUSHDB/CONFIG/EVAL）
（6）监控：做好机器 CPU、内存、带宽、磁盘监控，资源不足时及时报警，任意资源不足都会影响 Redis 性能；设置合理的 slowlog 阈值，并对其进行监控，slowlog 过多及时报警；监控组件采集Redis INFO 信息时，采用长连接，避免频繁的短连接；做好实例运行时监控，重点关注 expired_keys、evicted_keys、latest_fork_usec 指标，这些指标短时突增可能会有阻塞风险

2 说说Redis的几种基础数据结构？

（1）String字符串：String类型是二进制安全的，可以包含任何数据如数字、字符串、图片或者序列化的对象。
（2）List列表：双端链表实现List。使用List数据类型可以实现消息队列，利用List的 PUSH 操作，将任务存放在List中，然后工作线程再用 POP 操作将任务取出进行执行。
（3）Set集合：Redis 的 Set 是 String 类型的无序集合。集合成员是唯一的，不能出现重复的数据。集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。
（4）Hash散列：Redis hash 是一个 string 类型的 field（字段） 和 value（值） 的映射表，hash 特别适合用于存储对象。
（5）Zset有序集合： 有序集合不允许重复的成员。每个元素都会关联一个 double 类型的分数，通过分数来为集合成员排序。有序集合的成员是唯一的，但分数 score 却可以重复。

3 说说Redis如何持久化数据？

Redis 的数据都是存储在内存中，为了避免永久丢失数据，需要定期将 Redis 中的数据以某种形式从内存保存到硬盘。当下次 Redis 重启时，再利用持久化文件实现数据恢复。Redis 的持久化机制有两种：

• RDB(Redis Data Base) 内存快照

RDB持久化是Redis默认的持久化方式，即通过创建快照（压缩的二进制文件）的方式进行持久化，保存某个时间点的全量数据。每次都是从 Redis 中生成一个快照进行数据的全量备份，包括手动触发与自动触发两种方式。

优点：存储紧凑，节省内存空间；恢复速度非常快；适合全量备份、全量复制的场景，经常用于灾难恢复，对数据的完整性和一致性要求相对较低的场合。

缺点：容易丢失数据，容易丢失两次快照之间服务器中变化的数据；RDB 通过 fork 子进程对内存快照进行全量备份，是一个重量级操作，频繁执行成本高。

• AOF(Append Only File) 增量日志

AOF（Append-Only-File）持久化即记录所有变更数据库状态的指令，以append的形式追加保存到AOF文件中。在服务器下次启动时，就可以通过载入和执行AOF文件中保存的命令，来还原服务器关闭前的数据库状态。AOF 能够解决数据持久化实时性问题，是 Redis 持久化机制中主流的方案。

优点：数据的备份更加完整，丢失数据的概率更低，适合对数据完整性要求高的场景。AOF 可操作性更强，日志文件可读，可通过操作日志文件进行修复。

缺点：AOF 日志记录在长期运行中逐渐庞大，恢复起来非常耗时，需要定期对 AOF 日志进行瘦身处理；恢复备份速度比较慢，同步写操作频繁会带来性能压力。

4 如何解决Redis缓存单机热点问题？

（1）预估热点key：预估哪些是热key，比如某商品在做秒杀，那商品编号就是热key。但是并非所有业务都能预估出key的冷热。
（2）程序统计：在客户端埋点收集，缺点是有代码入侵。
（3）Redis 自带功能：Redis 4.0以上开启 Redis 自带系统监控，比如monitor命令。

解决热点问题的方案：
（1）二级缓存：把热key加载到系统的JVM中，比如Ehcache、HashMap等
（2）Key 添加随机数：把热点 Key 分布到不同机器，给 Key 加一个随机后缀。

5 Redis的集群方案有哪些？

• 主从方案

一个master可以有多个salve节点，salve节点可以有slave节点。主从结构具有读写分离，提高效率、数据备份，提供多个副本等优点。最大的不足就是主从模式不具备自动容错和恢复功能，主节点故障，集群则无法进行工作，可用性比较低，从节点升主节点需要人工手动干预。

• 哨兵模式

也是主从模式，在主节点宕机导致不可写的情况下增加竞选机制，从所有的从节点竞选出新的主节点。通过发送命令返回监控服务器的运行状态，处理监控主服务器、从服务器外，哨兵之间也相互监控。当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换master，有问题的旧主也会变为新主的从。

• Redis Cluster

redis在3.0上加入了 Cluster 集群模式，实现了 Redis 的分布式存储，也就是说每台 Redis 节点上存储不同的数据。cluster模式为了解决单机Redis容量有限的问题，将数据按一定的规则分配到多台机器，内存/QPS不受限于单机，可受益于分布式集群高扩展性。

Redis Cluster是一种服务器Sharding技术(分片和路由都是在服务端实现)，采用多主多从，每一个分区都是由一个Redis主机和多个从机组成，片区和片区之间是相互平行的。Redis Cluster集群采用了P2P的模式，完全去中心化。

redis cluster主要是针对海量数据+高并发+高可用的场景，海量数据，如果你的数据量很大，那么建议就用redis cluster，数据量不是很大时，使用sentinel就够了。redis cluster的性能和高可用性均优于哨兵模式。

Redis Cluster采用虚拟哈希槽分区而非一致性hash算法，预先分配一些卡槽，所有的键根据哈希函数映射到这些槽内，每一个分区内的master节点负责维护一部分槽以及槽所映射的键值数据。

• 其他实现

Redis在3.0版本前只支持单实例模式，虽然Redis的开发者Antirez早在博客上就提出在Redis 3.0版本中加入集群的功能，但3.0版本等到2015年才发布正式版。各大企业等不急了，在3.0版本还没发布前为了解决Redis的存储瓶颈，纷纷推出了各自的Redis集群方案。这些方案的核心思想是把数据分片（sharding）存储在多个Redis实例中，每一片就是一个Redis实例。

（1）客户端分片

客户端分片是把分片的逻辑放在Redis客户端实现，（比如：jedis已支持Redis Sharding功能，即ShardedJedis），通过Redis客户端预先定义好的路由规则(使用一致性哈希)，把对Key的访问转发到不同的Redis实例中，查询数据时把返回结果汇集。

客户端sharding技术使用hash一致性算法分片的好处是所有的逻辑都是可控的，不依赖于第三方分布式中间件。服务端的Redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强。开发人员清楚怎么实现分片、路由的规则。

（2）代理分片

Redis代理分片用得最多的就是Twemproxy，其基本原理是：通过中间件的形式，Redis客户端把请求发送到Twemproxy，Twemproxy根据路由规则发送到正确的Redis实例，最后Twemproxy把结果汇集返回给客户端。Twemproxy通过引入一个代理层，将多个Redis实例进行统一管理，使Redis客户端只需要在Twemproxy上进行操作，而不需要关心后面有多少个Redis实例，从而实现了Redis集群。

客户端像连接Redis实例一样连接Twemproxy，不需要改任何的代码逻辑，支持无效Redis实例的自动删除。Twemproxy与Redis实例保持连接，减少了客户端与Redis实例的连接数。由于Redis客户端的每个请求都经过Twemproxy代理才能到达Redis服务器，这个过程中会产生性能损失。

Twemproxy最大的痛点是无法平滑地扩容/缩容。对于运维人员来说，当业务需要增加Redis实例时工作量非常大。Twemproxy作为最被广泛使用、最久经考验、稳定性最高的Redis代理，在业界被广泛使用。

参考(摘抄的文字版权属于原作者)
https://www.cnblogs.com/xingxia/p/redis_compare_memcache.html
https://blog.csdn.net/jjclove/article/details/124922628
https://www.cnblogs.com/shenStudy/p/16859463.html
https://blog.csdn.net/An1090239782/article/details/127203348
https://www.cnblogs.com/dragonsuc/p/6885495.html
https://zhuanlan.zhihu.com/p/518594810