002---Redis

主从复制

主节点负责写数据、从节点负责读数据。主节点定期将数据同步到从节点，从而保证数据的一致性。

• 一主一从

• 一主多从
  
  针对“读”较多的场景，“读”由多个从节点来分担，但节点越多，主节点同步到多节点的次数也越多，影响带宽，也加重主节点的稳定

• 树状主从：一主多从的缺点（主节点推送次数多压力大）可用些方案解决，主节点只推送一次数据到从节点B，再由从节点B推送到C，减轻主节点推送的压力。

缺点：

• 主节点出现问题，需手动配置将从节点变为主节点
• 主从复制的主节点写能力单机，能力有限

发布与订阅

redis提供了“发布、订阅”模式的消息机制，其中消息订阅者与发布者不直接通信，发布者向指定的频道（channel）发布消息，订阅该频道的每个客户端都可以接收到消息

Redis哨兵机制（Sentinel）

哨兵机制正式为了解决主从复制的缺点

原理：当主节点出现故障时，由Redis Sentinel自动监控完成故障发现和转移，并通知应用方，实现高可用性

Redis 持久化

支持RDB、AOF。两种持久化机制。持久化可避免进程丢失而造成数据丢失。

• RDB持久化

RDB持久化把当前进程数据生成快照（.rdb）文件保存到硬盘的过程，有手动触发和自动触发

手动触发有save和bgsave两命令

save命令：阻塞当前Redis，直到RDB持久化过程完成为止，若内存实例比较大会造成长时间阻塞，线上环境不建议用它

bgsave命令：redis进程执行fork操作创建子线程，由子线程完成持久化，阻塞时间很短（微秒级），是save的优化,在执行redis-cli shutdown关闭redis服务时，如果没有开启AOF持久化，自动执行bgsave;

显然bgsave是对save的优化

优点：1，压缩后的二进制文文件适用于备份、全量复制，用于灾难恢复

          2，加载RDB恢复数据远快于AOF方式

缺点：1，无法做到实时持久化，每次都要创建子进程，频繁操作成本过高

          2，保存后的二进制文件，存在老版本不兼容新版本rdb文件的问题

• AOF持久化

Redis的过期策略

Redis的分布式锁实现

redis常见集群技术

• 客户端分片
• 代理分片
• Redis Cluster

codis

Twemproxy代理分片

应用场景

• 缓存

• 排行榜：redis的有序列表数据结构非常方便。

• 计数器：点赞、访问数。

• 限速器：抢购秒杀，防止用户疯狂点击带来不必要的压力；

• session共享：session默认保存在服务器中，即当前服务器。如果是集群服务，用户的信息可能在不同机器，所以会造成用户频繁登录。利用redis保存session，无论哪台机器都可以获取session信息。

• 简单的消息队列：除了Redis自身的发布/订阅模式，我们也可以利用List来实现一个队列机制，比如：到货通知、邮件发送之类的需求