经验总结（三）：Redis

Redis

Memcache和Redis的区别

• Memchache

  • 代码层次类似Hash
  • 支持简单数据类型
  • 不支持数据持久化存储
  • 不支持主从
  • 不支持分片

• Redis

  • 数据类型疯
  • 支持数据磁盘持久化存储
  • 支持主从
  • 支持分片

• Redis为什么能这么快

  • 100000+QPS
  • 完全基于内存，绝大部分请求是纯粹的内存操作，执行效率高
  • 数据结构简单，对数据操作也简单
  • 采用单线程（主线程），单线程也能处理高并发请求，想多核也可启动多实例
  • 使用多路I/O复用模型，非阻塞IO

• FD（File Descriptor）

  • 一个打开的文件通过唯一的描述符进行引用，该庙舒服是打开文件的元数据到文件本身的映射，用一个整数来表示。

• 多路I/O复用模型（之后我会在linux章节详细描述）

  • Select系统调用，负责监听各个文件可读/可写

• Redis采用的I/O多路复用函数：epoll/kqueue/evport/select

  • 因地制宜
  • 优选选择时间读咋读为O(1)的I/O多路复用函数作为底层实现
  • 以时间复杂度为O(n)的select作为保底
  • 基于react设计模式监听I/O事件

• Redis的数据类型

  • String：最基本的数据类型，二进制安全
    • set
    • get
    • Incr
  • Hash：String元素字典，适合用于存储对象
    • hmset
    • hset
    • Get
  • List：列表，按照String元素插入顺序排序
    • lpush
    • lrange
  • Set：String元素组成的无序集合，通过哈希表实现，不允许重复
    • saa
    • Members
  • Sorted Set：通过分数来为集合中的成员进行从小到大的排序
    • zadd myzset 3 ada
    • zadd myzset 1 abc
    • zrangebyscore myzset 0 10

• 从海量key里查询出某一固定前缀的key

  • 摸清数据规模，即问清楚边界
  • Keys pattern： 查找所有符合给定模式的pattern的key
    • 键的数量过大会使服务卡顿
  • SCAN cursor [MARCH pattern] [COUNT count]
    • scan 0 match str* count 10
    • 基于有标的迭代器，需要机遇上一次的游标延续之前的迭代过程
    • 以0作为游标开始一次新的迭代，直到命令返回有标0完成一次遍历。
    • 不保证每次执行都返回某个给定数量的元素，支持模糊查询
    • 一次返回的数量不可控，只能是大概率符合count
    • 可能返回相同的数据，需要去重。

• Redis实现分布式锁

  • 分布式锁
    • 互斥性
    • 安全性
    • 死锁
    • 容错
  • SETNX key value :如果key不存在，则创建并赋值
    • 时间复杂度O(1)
    • 如果设置成功，返回1；设置失败，返回0
  • 如果解决SETNX长期有效的问题
    • EXPIPE key seconds
      • 设置key的生存时间，当key过期时（生存时间为0），会被自动删除
    • 先获取资源再设置时间。（原子性得不到满足）
  • SET key value [EX seconds] [PX milliseconds] [NX|XX]
    • EX second : 设置键的国旗时间为second秒
    • PX millisecond : 设置键的国旗时间为millisecond毫秒
    • NX : 只在键不存在时，才对键进行设置操作
    • XX : 只在键已经存在时，才对键进行设置操作
    • SET操作成功完成时，返回OK，否则返回nil
  • 大量的key同时过期注意事项
    • 集中过期，由于清楚大量的key很耗时，会出现短暂的卡顿现象
      • 在设置key的国旗时间的时候，给每个key加上随机值
  • 使用Redis做异步队列
    • 使用rpush入队列，lpop出队列
    • rpush test a
    • lpop test
    • 缺点：没有等待队列里有值就去消费
    • 弥补：可以通过在应用层引入Sleepe机制去调用lpop重试
    • blpop key [key…] timeout：阻塞直到队列有消息或超时
      • 缺点：只能供一个消费者消费
    • pub/sub：主体订阅者模式
      • 发送者（pub）发送消息，订阅者（sub）接收消息
      • 订阅者可以订阅任意数量的频道
      • subscribe myTopic
      • publish myTopic "hello word"
      • 消息的发布时无状态的，无法保证可达
  • Redis的集群原理（从海量数据里快速找到所需要的数据）
    • 分片：按照某种规则去划分数据，分散存储在多个节点上
    • 常规的按照哈希划分无法实现节点的动态增减
  • 一致性哈希
    • 对2^32取模，将哈希值空间组织成虚拟的圆环。
    • Hash环的数据倾斜问题
      • 虚拟节点解决数据倾斜，在进行hash前，在ip或者机器名后面加随机数，虚拟出多个节点。但是多了一步虚拟节点到真实节点的引用。

• 持久化

  • RDB（快照）持久化：保存某个时间点的全量数据快照。
  • 手动触发RDB快照
    • SAVE：阻塞Redis的服务器进程，直到RDB文件被创建完毕。
    • BGSAVE：Fork出一个子进程来创建RDB文件，不阻塞服务器进程。
  • 自动触发RDB快照
    • 根据redis.com配置里的SAVE 900 1 等定时触发（用的是BGSAVE）
    • 主从复制时，主节点自动触发
    • 执行Debug Reload
    • 执行Shutdown切没有开启AOF持久化
  • BGSAVE的原理
    • 检查子进程是否存在AOF/RDB子进程，如果有则返回错误
    • 触发持久化调用rdbSaveBackground
    • 系统调用fork()创建进行，实现Copy-on-Write，创建的进程开始执行rdb操作
    • Copy-on-write:如果有多个调用者同时要求相同的资源（如内存或磁盘上的数据存储），他们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一份副本给该调用者，而其他调用者所见到的最初的资源仍然保持不变。
  • RDB持久化缺点
    • 内存数据的全量同步，数据量大会由于I/O而严重影响性能
    • 可能会因为Redis挂掉而丢失从当前至最近一次快照期间的数据
  • AOF（Append-Only-File）持久化：保存写状态
    • 记录下除了查询以外的所有变更数据库状态的指令。
    • 以append的形式追加的形式保存到AOF文件中（增量）
  • 日志重写解决AOF文件大小不断增大的问题
    • 调用fork()，创建一个子进程
    • 子进程把新的AOF写到一个临时文件里，不依赖原来的AOF文件
    • 主进程持续将新的变动同时写到内存和原来的AOF里
    • 主进程获取子进程重写AOF的完成信号，往新AOF同步增量变动
    • 使用新的AOF文件替换掉旧的AOF文件
  • Redis数据的恢复（RDB和AOF文件）
    • 是否存在AOF文件，如果存在则加载AOF文件
    • 不尊在检查RDB文件是否存在，如果存在加载RDB文件。
  • RDB和AOF的优缺点
    • RDB优点：全量数据快照，文件小，恢复快
    • RDB缺点：无法保存最近一次快照之后的数据。
    • AOF优点：可读性高，适合保存增量数据，数据不易丢失
    • AOF缺点：文件体积大，恢复时间长
  • RDB-AOF混合持久化方式（默认配置）
    • 检查子进程是否含有AOF/RDB的子进程如果有就返回错误
    • 触发持久化，嗲用rewiteAppendOnlyFileBackground
    • fork()，创建一个子进程进行重写操作，生成新的AOF临时文件
    • 主进程相应其他操作。
    • BGSAVE做镜像全量持久化，AOF做增量持久化。

• Pipeline

  • Pipeline和Linux的管道类似
  • Redis基于请求/相应模式，单个请求处理需要一一应答。
  • Pipeline批量执行指令，节省多次IO往返时间。
  • 如果有顺序依赖的指令建议分批次发送

• Redis的同步机制

  • 全同步过程
    • Salve发送sync命令到Master
    • Master启动一个后台进程，将Redis中的数据快照保存到文件中
    • Master将保存数据快照期间接受到的写命令缓存起来
    • Master完成写文件操作后，将该文件发送给Slave
    • 使用写的AOF文件替换掉旧的AOF文件
    • Master将这期间手机的增量写命令发送给Slave端
  • 增量同步
    • Master接收到用户的操作指令，判断是否需要传播到Slave
    • 将操作记录追加到AOF文件
    • 将操作传播到其他Slave：1、对齐主从库；2、往相应缓存写入指令
    • 将缓存中的数据发送给Slave

• Redis Sentinel（解决主从同步Master宕机后的主从切换问题）

  • 监控：检查主从服务器是否运行正常
  • 提醒：通过API向管理员或者其他应用程序发送故障通知
  • 自动故障迁移：主从切换

• 流言协议Gossip（在杂乱无章中寻求一致）

  • 每个节点都随机地与对方通信，最终所有节点的状态达成一致。
  • 种子节点定期随机向其他节点发送节点列表以及需要传播的消息。
  • 不保证信息一定会传递给所有节点，但是最终会趋于一致

---

                                                                                                生活要多点不自量力