redis基础
redis的常用数据结构有哪些？
redis是K-V存储，K是字符串，V有多种数据类型。
1. string：简单的key-value类型，一般用在计数场景，比如用户访问次数、文章点赞数
2. list：list 即是 链表，使用场景：发布与订阅或者说消息队列、慢查询。
3. hash：类似HashMap，内部实现是数组 + 链表，使用场景：系统中对象数据的存储。
4. set：类似HashSet ，一种无序去重集合。使用场景： 需要存放的数据不能重复。
5. zset / sorted set ：和 set 相比，sorted set 增加了一个权重参数 score，使得集合中的元素能够按 score 进行有序排列。使用场景：需要对数据根据某个权重进行排序的场景。比如直播的礼物排行榜
6. bitmap：bitmap存储的是二进制数字（0 和 1），只需要一个 bit 位就可以表示某个元素的值或状态，极大节省储存空间。使用场景：适合需要保存状态信息，比如用户签到情况、用户行为统计（比如是否点赞过某个视频）
缓存的常见问题及其解法
问题1：缓存穿透/缓存击穿
如果访问数据库不存在的数据，会先缓存查一次，再数据库查一次，如果这类请求过多，会造成性能降低，甚至数据库崩溃。
解法：
- 对不存在的key，在缓存中置value为null，快速返回，但TTL不能太长，防止key真有数据录入了数据库。
- 布隆过滤器bloom filter：通过 bloom filter 判断 key 是否存在，如果不存在直接返回即可，无需查缓存。
- 请求做参数校验，过滤无效请求。
问题2：缓存雪崩
某一时刻，多个key同时失效，压力全部到数据库，导致数据库出现异常。
解法：
- key的过期时间增加随机值，不会同时失效
问题3：数据不一致
更新数据后，数据库和缓存中同1个key的value不一致。
解法：
- 数据库更新成功后立即删除缓存
- 缩短TTL，及时读取DB最新数据
问题4：HotKey/热key
同一时间大量请求访问特定key，打爆带宽，影响整体redis集群。
解法：
- 凭借业务经验、实时监控，及时识别HotKey，下发到客户端缓存，减少请求量。
- 采用redis集群部署，提升可用性。
问题5：BigKey
BigKey指一个K的value很大，会导致占用过多内存空间、处理时间长导致阻塞后续请求，影响整体redis集群性能。
解法：
- 对大Key进行清理：Redis提供UNLINK命令，能够以非阻塞的方式缓慢逐步的清理传入的Key，可以安全的删除大Key甚至特大Key。
- 对大Key进行拆分：将一个Big Key拆分为多个key-value这样的小Key，通过get不同的key或者使用mget批量获取。
- 压缩value：用压缩算法控制key的大小
布隆过滤波器存在什么问题？
布隆过滤器是一种基于概率的数据结构，可以迅速判断一个元素在不在一个集合。
判断不在集合中，准确率100%；判断在集合中，可能存在误判。
布隆过滤器的核心技术实现就是bit array，bit只能代表0和1，如果元素hash后对应的位置不全是1，则一定不在集合中；如果全是1，由于hash碰撞的存在，只能说明可能在集合中。
redis高可用
主从模式
- 读写分离：读操作，主从都接收；写操作，先到主，然后同步给从。 故障恢复：当主出问题，可以由从节点提供服务，实现快速的故障恢复。
- 复制偏移量offset：主和从会维护一个复制偏移量，主每次向从传递 N 个字节后，会将自己的复制偏移量加上 N；从收到主的 N 个字节数据，也会将自己的复制偏移量加上 N。通过主从的偏移量对比可以知道数据是否一致。 增量同步：从把当前的偏移量告诉主，主计算偏移量差距，然后把两者之间相差的命令操作同步给从。 全量同步：从首次加入集群，发生的是全量同步，主库通过 bgsave 命令生成 RDB 文件，然后传送到从库。
哨兵模式
当主宕机，需要手动把从切换为主，费时费力，所以有了哨兵（Sentinel）模式。 为减少误判，引入多个哨兵节点，当大部分(N/2 + 1)哨兵认为主库下线，主库才会真正被下线。一般采用一主/两从/三哨兵方式：
哨兵实现了什么功能？
- 监控：哨兵会不断检查主和从是否运作正常。哨兵每10秒向主发送INFO命令，获取所有从库列表，刷新从库状态。
- 自动故障转移：主不能正常工作时，哨兵会将一个从节点升为新主。
- 通知：将故障转移结果发送给客户端。
故障判定的原理：
- 主观下线：单个哨兵作出的节点下线的判断。哨兵每秒对所有实例（哨兵、主、从）发送PING命令，如果一定时间内收不到回复，哨兵认为节点主观下线。
- 客观下线：哨兵集群共同决定节点是否下线。当一个哨兵认为节点主观下线后，它会询问其他的哨兵，看其他节点是否也认为节点下线。如果接收到足够多的的数量证明节点下线，那么就会认为节点客观下线。
redis cluster集群模式
哨兵模式已基本实现高可用，如果数据量不大，使用sentinel就够了。 但针对海量数据+高并发的场景，每个节点都存储相同的内容，浪费内存，同时master写数据的压力很大。
Redis Cluster采用虚拟哈希槽分区而非一致性hash算法，一个切片集群共有16384个哈希槽，每个键会被映射到一个哈希槽。如果集群中有N个实例，那么，每个实例上的槽个数为16384/N个，每一个分区内的master节点负责维护一部分槽。 官方推荐，至少要 3 台以上的master节点，最好使用 3 主 3 从六个节点的模式。 集群模式实现了分布式存储，而且节点存储不同内容。
redis主从复制的原理？作用？
2种形式：
- 全量复制：第一次主从同步时，会把所有数据以RDB形式同步给从库。
- 增量复制：之后每条命令，以增量形式同步给从库。
具体过程：
- 主节点执行写命令后，会将写命令发送给从节点。
- 从节执行写命令，成功后向主节点发送ACK确认信息。
- 主节点收到ACK后，会将写命令记录到日志文件中。
主从复制的作用：
- 主节点宕机后，可以从从节点切换到主节点，保证服务的可用性。
- 增加从节点可以提高读负载，减轻主节点的压力。
redis集群如何保证各节点的数据一致性？
当客户端向redis集群发送写操作时，该节点会先将操作转发给负责相应槽的主节点，主节点再将操作同步到所有从节点上，最后返回客户端。
数据一致性策略：
- 槽分区：Redis集群将数据分成16384个槽，每个槽分配到不同的节点上，这样每个节点只需要处理自己分配到的槽，可以有效避免数据冲突的问题。
- 一致性hash算法：Redis集群中使用了一致性哈希算法来将槽映射到节点上，这样可以保证当集群中增加或减少节点时，只有部分槽需要重新分配，不会影响整个集群的数据一致性。
- 主从复制：主节点会将自己的写操作同步到所有从节点上，从节点再执行相同的写操作。
- 哨兵机制：Redis集群中的哨兵节点会监控主节点的健康状况，如果主节点故障了，哨兵会自动将某个从节点提升为主节点，这样可以保证集群中始终有可用的主节点。
redis数据的过期机制和淘汰机制？
1. 过期策略
redis可对key设置过期时间，因此需要有相应的机制删除过期键，即过期策略。Redis中同时使用了被动删除和定期删除两种过期策略。
- 被动删除：key再被操作时，Redis主动检查key是否过期，过期则删除。
- 定期删除：周期性地，随机选择x个设置了过期时间的key，删除已过期的key，如果删除key的数量超过x的25%，则重复以上步骤。
2. 内存淘汰策略
在配置文件 redis.conf 中，可以通过参数 maxmemory <bytes> 来设定最大运行内存。当redis的运行内存超过设置的最大内存，会使用内存淘汰策略，删除符合条件的 key，以保障redis的运行。
(1) noeviction，不进行数据淘汰：Redis3.0之后默认的内存淘汰策略。当运行内存超过最大设置内存时，不淘汰任何数据，但不再提供服务，直接返回错误。
(2) 对设置了过期时间的数据的淘汰策略
- volatile-random：随机
- volatile-ttl：优先淘汰更早过期的键值
- volatile-lru：淘汰最久未使用的键值
- volatile-lfu：淘汰最少使用的键值
(3) 在所有数据范围内的淘汰策略
- allkeys-random：随机
- allkeys-lru：淘汰最久未使用的键值
- allkeys-lfu：淘汰最少使用的键值
什么是redis脑裂？如何解决？
什么是脑裂？
脑裂是指在主从集群中，同时有两个主节点，它们都能接收写请求，导致不同客户端会往不同的主节点上写入数据，进一步导致数据丢失。
为什么产生脑裂？
主库是由于某些原因（比如网络通信故障）无法处理请求，也没有响应哨兵的心跳，被判断客观下线，重新选主。结果，原主库又重新开始处理请求了，此时哨兵还没有完成主从切换，客户端仍然可以和原主库通信，客户端发送的写操作就会在原主库上写入数据了。
解决方案：
Redis 提供了两个配置项来限制主库的请求处理，分别是 min-slaves-to-write 和 min-slaves-max-lag：
- min-slaves-to-write：主库可以进行数据同步的最少从库数量
- min-slaves-max-lag：主从复制时，从库给主库发送 ACK 消息的最大延迟（单位秒）
这两个配置项组合后，1. 主库至少有 N 个从库；2. 主从复制时的 ACK 消息延迟不能超过 T 秒，否则主库不再接收客户端请求。
619
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
