redis面试

Redis 学习笔记

Redis特性

• 基于内存，速度快
• key-value键值对
• 二进制安全
• worker单线程，IO多线程
• 用到多路复用器，使用内核epoll
• 5中数据类型，且自带本地方法

数据类型

String

使用场景

• 字符串：缓存
• 字符串：Session共享
• 字符串: 对象，序列化，反序列化
• 数值（int）：统计，秒杀限流，消峰
• 二进制安全：小文件存储（类似CDN加速）
• Bitmap：签到， bitset, bitcount, bitop
• Bitmap: 统计登录次数 bitset, bitop
• Bitmap：权限控制（类似linux全选）
• 布隆过滤器

List

• 取表头，表尾的复杂度都是O(1)
• 使用index：模拟数组
• 同方向存取：模拟栈
• 不同方向存取：模拟队列
• JVM数据迁出，分布式共享

Hash

• 值是key-value
• 聚合场景：商品详情页

Set

• 无序，扩容rehash时会颠倒顺序
• 随机事件：SRANDMEMBER （正数不重复，负数重复），如抽奖，随机组合
• 随机事件：SPOP 随机返回一个值，如抽奖
• 集合操作，性能较低，可能阻塞其他请求，推荐系统，如共同好友（交际），推荐好友（差集）

ZSet

• element：元素
• score：排序依据
• rank：排名
• 跳表（zkiplist）
• 排行榜
• 评论 + 分页
• 有序事件

分布式锁

实现

• setnx：当key不存在时，设置value；已存在是，不做任何操作
  • 通过setnx获取锁，设置成功则表示所获取成功，设置失败则表示锁被占用
  • 释放锁时，del key删除即可
  • 存在问题： 得到锁的服务业务逻辑运行时抛出异常或者宕机时，导致锁无法释放，所有其他服务都获得不了锁，形成死锁，整个集群阻塞
  • try-catch-finally能解决异常抛出的问题，但解决不了宕机的问题
• expire：设置超时时间
  • 通过设置锁的超时时间解决上面的问题，即便获得锁的服务宕机，超时过后，其他线程或服务仍旧能获得锁
  • 存在问题： setnx 和 expire不是原子操作，获得锁后，设置超时前宕机，仍旧可能形成死锁
  • 高版本的Redis支持一个命令直接原子操作 SET lock_key random_value NX PX 5000
  • 存在问题： 高并发场景下，执行时间超过了超时时间，锁被释放；第二个线程获得新的锁，；第一个线程执行结束，将第二个线程的锁给释放了；导致其他的线程能够获得锁，形成锁失效
• UUID：获得所示给value赋值UUID，释放锁时判断该锁是否是自己线程获得的锁
  • 这样解决了高并发场景下，锁被其他线程释放的问题
  • 存在问题： 但是执行时间超过超时时间，导致锁失效问题仍旧存在
• 超时续命：
  • 无法保证每个线程的执行时间，极端场景下任何时间都有可能
  • 超时时间设置过短，可能不够执行时间
  • 超时时间设置过长，可能导致死锁时间过长
  • 获得锁后，另外开一个线程，每隔一段时间（一般使用超时时间的1/3）锁续命：如果所还存在，重新设置一下超时时间
  • 存在问题： 主从架构下，在锁尚未同步到从节点时，redis主节点宕机，选举出新的主节点，新的主节点没有锁，导致锁失效
  • 存在问题： 不是可重入锁
• redlock
  • redis默认是AP模型的，只保证最终一致性，不保证最终一致性，如果需要强一致性可以考虑zookeeper
  • redis也可以实现解决主从架构锁失效问题，redlock
  • redlock思路：当且仅当超过半数的独立节点获取到锁才返回获得锁成功，如果获取锁失败（不超过半数成功或超时），通知所有实例释放锁
  • redlock降低性能

Redission

Redission是目前所知使用最广泛的Redis JAVA开源框架，上面所述的所有，sentnx,超时，去重，续命，都已经帮你实现，可直接调用

• RLock lock = redisson.getLock("myLock")
• lock.lock();
• lock.unlock();
• 内部实现 lua脚本保证原子性

redis持久化

• rdb：快照，恢复速度快，缺失多 （默认）
• aof：日志，数据完整，恢复慢（重放所有指令），重复失效操作有冗余，有以下级别
  • 1. 每次操作都追加：确保完整性，降低性能，与数据库相同
  • 2. 每秒钟 OS缓冲 刷写 一个buffer
  • 3. OS缓冲 刷写 一个buffer
• 4.8之前rdb与aof互斥，之后的版本允许混用（归档+日志）

集群分布式

主从复制

• 主从：数据镜像
• 需要数据同步
• 默认支持弱一致性：作为缓存使用时，影响不大（AP）
• 强一致性：更新操作，等待备机写入成功，才返回客户端，会破坏可用性 （CP），分布式锁要求
• 最终一致性：redis没有该功能，HDFS namenode，journalnode（脑裂，过半机制）

分片集群

• 数据分片
• 不需要数据同步
• 客户端实现分片算法
• 或者代理实现分片算法

Redis集群（Cluster）

• 整合高可用及数据分片
• 内部实现Hash算法，公共的映射算法
• 槽位 16384

AKF划分原则

• X轴，水平扩展，主备冗余，高可用
• Y轴，垂直扩展，按业务划分，不同的业务连到不同的实例
• Z轴，解决数据量过大问题，针对业务按区间或者hash数据分片

本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名,转载请标明出处
最后编辑时间为: 2020/08/11 11:02