redis常见问题(二)

2019-05-13

redis

如何使用Redis做异步队列？
- 使用List作为队列，RPUSH生产消息，LPOP消费消息
  - 缺点：不会等待队列里有值才进行消费
  - 弥补：可以通过在应用层引入Sleep机制去调用LPOP重试
- BLPOP key[key ...] timeout:阻塞直到队列有消息或者超时
  - 缺点：只能供一个消费者消费
- pub/sub：主题订阅者模式
  - 发送者(pub)发送消息，订阅者(sub)接收消息：subscribe mytopic/publish mytopic XXX
  - 订阅者可以订阅任意数量的频道
  - pub/sub缺点
    - 消息的发布是无状态的，无法保证可达，如果消费者在消息发送时突然下线，上线是无法收到消息的，这种需要借助消息队列来完善，如Kafka等。
Redis如何数据持久化？
1. RDB(快照)持久化：保存某个时间点的全量数据快照
  - SAVE：阻塞Redis的服务器进程，直到RDB文件被创建完毕
  - BGSAVE：Fork出一个子进程来创建RDB文件，不阻塞服务器进程（BGSAVE使用了fork函数，生成一个子进程来进行RDB持久化，并使用CopyOnWrite进行优化）
  - 自动触发RDB持久化的方式
    1. 根据redis.conf配置里的SAVE m n定时触发（用的是BGSAVE）
    2. 主从复制时，主节点自动触发
    3. 执行Debug Reload
    4. 执行ShutDown且没有开启AOF持久化
  - RDB持久化缺点：
    - 内存数据的全量同步，数据量大会由于I/O严重影响性能
    - 可能会因为Redis挂掉而丢失从当前到最近一次快照期间的数据
2. AOF（Append-Only-FIle）持久化：保存写状态
  - 记录下除了查询以外的所有变更数据库状态的指令
  - 以append的形式追加保存到AOF文件中（增量）
  - 日志重写解决AOF文件大小不断增大的问题，原理如下：
    1. 调用fork(),创建一个子进程
    2. 子进程把新的AOF写到一个临时文件里，不依赖原来的AOF文件
    3. 主进程持续将新的变动同时写到内存和原来的AOF里
    4. 主进程获取子进程重写AOF的完成信号，往新AOF同步增量变动
    5. 使用新的AOF文件替换掉旧的AOF文件

1557733139087

RDB-AOF混合持久化方式（redis4.0默认持久化方式）
- BGSAVE做镜像全量持久化，AOF做增量持久化

使用PipeLine的好处
- Pipeline和Linux的管道类似
- Redis基于请求/响应模型，单个请求处理需要一一应答
- Pipeline批量执行指令，节省多次IO往返的时间
- 有顺序依赖的指令建议分批发送
Redis的同步机制

主从同步原理：
- 全同步过程
  - Salve发送sync命令到Master
  - Master启动一个后台进程，将Redis中的数据快照保存到文件中
  - Master将保存数据快照期间接受到的写命令缓存起来
  - Master完成写文件操作后，将该文件发送给Salve
  - 使用新的AOF文件替换掉旧的AOF文件
  - Master将这期间收集的增量写命令发送给Salve端
- 增量同步过程
  - Master接收到用户的操作指令，判断是否需要传播到Slave
  - 将操作记录追加到AOF文件
  - 将操作传播到其他Slave：1.对齐主从库；2.往响应缓存写入指令
  - 将缓存中的数据发送给Slave
Redis Sentinel（哨兵）：解决主从同步Master宕机后的主从切换问题：
- 监控：检查主从服务器是否运行正常
- 提醒：通过API向管理员或者其他应用程序发送故障通知
- 自动故障迁移：主从切换
流言协议Gossip：在杂乱无章中寻求一致
- 每个节点都随机地与对方通信，最终所有节点的状态达成一致
- 种子节点定期随机向其他节点发送节点列表以及需要传播的消息
- 不保证信息一定会传递给所有节点，但是最终会趋于一致
如何在海量数据中快速找到所需？
- 分片：按照某种规则去划分数据，分散存储在多个节点上
- 常规的按照哈希划分无法实现节点的动态增减
- redis的集群原理
  
  一致性哈希算法:对2^32取模,将哈希值空间组织成虚拟的圆环: