|
| 1 | +# Redis 集群以及应用 |
| 2 | + |
| 3 | +## 集群 |
| 4 | +### 主从复制 |
| 5 | +#### 主从链(拓扑结构) |
| 6 | + |
| 7 | + |
| 8 | + |
| 9 | + |
| 10 | +#### 复制模式 |
| 11 | +- 全量复制:master 全部同步到 slave |
| 12 | +- 部分复制:slave 数据丢失进行备份 |
| 13 | + |
| 14 | +#### 问题点 |
| 15 | +- 同步故障 |
| 16 | + - 复制数据延迟(不一致) |
| 17 | + - 读取过期数据(Slave 不能删除数据) |
| 18 | + - 从节点故障 |
| 19 | + - 主节点故障 |
| 20 | +- 配置不一致 |
| 21 | + - maxmemory 不一致:丢失数据 |
| 22 | + - 优化参数不一致:内存不一致. |
| 23 | +- 避免全量复制 |
| 24 | + - 选择小主节点(分片)、低峰期间操作. |
| 25 | + - 如果节点运行 id 不匹配(如主节点重启、运行 id 发送变化),此时要执行全量复制,应该配合哨兵和集群解决. |
| 26 | + - 主从复制挤压缓冲区不足产生的问题(网络中断,部分复制无法满足),可增大复制缓冲区( rel_backlog_size 参数). |
| 27 | +- 复制风暴 |
| 28 | + |
| 29 | +### 哨兵机制 |
| 30 | +#### 拓扑图 |
| 31 | + |
| 32 | + |
| 33 | +#### 节点下线 |
| 34 | +- 客观下线 |
| 35 | + - 所有 Sentinel 节点对 Redis 节点失败要达成共识,即超过 quorum 个统一. |
| 36 | +- 主管下线 |
| 37 | + - 即 Sentinel 节点对 Redis 节点失败的偏见,超出超时时间认为 Master 已经宕机. |
| 38 | +#### leader选举 |
| 39 | +- 选举出一个 Sentinel 作为 Leader:集群中至少有三个 Sentinel 节点,但只有其中一个节点可完成故障转移.通过以下命令可以进行失败判定或领导者选举. |
| 40 | +- 选举流程 |
| 41 | + 1. 每个主观下线的 Sentinel 节点向其他 Sentinel 节点发送命令,要求设置它为领导者. |
| 42 | + 1. 收到命令的 Sentinel 节点如果没有同意通过其他 Sentinel 节点发送的命令,则同意该请求,否则拒绝. |
| 43 | + 1. 如果该 Sentinel 节点发现自己的票数已经超过 Sentinel 集合半数且超过 quorum,则它成为领导者. |
| 44 | + 1. 如果此过程有多个 Sentinel 节点成为领导者,则等待一段时间再重新进行选举. |
| 45 | +#### 故障转移 |
| 46 | +- 转移流程 |
| 47 | + 1. Sentinel 选出一个合适的 Slave 作为新的 Master(slaveof no one 命令). |
| 48 | + 1. 向其余 Slave 发出通知,让它们成为新 Master 的 Slave( parallel-syncs 参数). |
| 49 | + 1. 等待旧 Master 复活,并使之称为新 Master 的 Slave. |
| 50 | + 1. 向客户端通知 Master 变化. |
| 51 | +- 从 Slave 中选择新 Master 节点的规则(slave 升级成 master 之后) |
| 52 | + 1. 选择 slave-priority 最高的节点. |
| 53 | + 1. 选择复制偏移量最大的节点(同步数据最多). |
| 54 | + 1. 选择 runId 最小的节点. |
| 55 | +#### 读写分离 |
| 56 | +#### 定时任务 |
| 57 | +- 每 1s 每个 Sentinel 对其他 Sentinel 和 Redis 执行 ping,进行心跳检测. |
| 58 | +- 每 2s 每个 Sentinel 通过 Master 的 Channel 交换信息(pub - sub). |
| 59 | +- 每 10s 每个 Sentinel 对 Master 和 Slave 执行 info,目的是发现 Slave 节点、确定主从关系. |
| 60 | + |
| 61 | +### 分布式集群(Cluster) |
| 62 | +#### 拓扑图 |
| 63 | + |
| 64 | + |
| 65 | + |
| 66 | +#### 通讯 |
| 67 | +##### 集中式 |
| 68 | +> 将集群元数据(节点信息、故障等等)几种存储在某个节点上. |
| 69 | +- 优势 |
| 70 | + 1. 元数据的更新读取具有很强的时效性,元数据修改立即更新 |
| 71 | +- 劣势 |
| 72 | + 1. 数据集中存储 |
| 73 | +##### Gossip |
| 74 | + |
| 75 | + |
| 76 | +- [Gossip 协议](https://www.jianshu.com/p/8279d6fd65bb) |
| 77 | + |
| 78 | +#### 寻址分片 |
| 79 | +##### hash取模 |
| 80 | +- hash(key)%机器数量 |
| 81 | +- 问题 |
| 82 | + 1. 机器宕机,造成数据丢失,数据读取失败 |
| 83 | + 1. 伸缩性 |
| 84 | +##### 一致性hash |
| 85 | +-  |
| 86 | + |
| 87 | +- 问题 |
| 88 | + 1. 一致性哈希算法在节点太少时，容易因为节点分布不均匀而造成缓存热点的问题。 |
| 89 | + - 解决方案 |
| 90 | + - 可以通过引入虚拟节点机制解决：即对每一个节点计算多个 hash，每个计算结果位置都放置一个虚拟节点。这样就实现了数据的均匀分布，负载均衡。 |
| 91 | +##### hash槽 |
| 92 | +- CRC16(key)%16384 |
| 93 | +- |
| 94 | + |
| 95 | + |
| 96 | + |
| 97 | + |
| 98 | + |
| 99 | + |
| 100 | + |
| 101 | +## 使用场景 |
| 102 | +### 热点数据 |
| 103 | +### 会话维持 session |
| 104 | +### 分布式锁 SETNX |
| 105 | +### 表缓存 |
| 106 | +### 消息队列 list |
| 107 | +### 计数器 string |
| 108 | + |
| 109 | + |
| 110 | + |
| 111 | + |
| 112 | + |
| 113 | +## 缓存设计 |
| 114 | +### 更新策略 |
| 115 | +- LRU、LFU、FIFO 算法自动清除:一致性最差,维护成本低. |
| 116 | +- 超时自动清除(key expire):一致性较差,维护成本低. |
| 117 | +- 主动更新:代码层面控制生命周期,一致性最好,维护成本高. |
| 118 | +### 更新一致性 |
| 119 | +- 读请求:先读缓存,缓存没有的话,就读数据库,然后取出数据后放入缓存,同时返回响应. |
| 120 | +- 写请求:先删除缓存,然后再更新数据库(避免大量地写、却又不经常读的数据导致缓存频繁更新). |
| 121 | +### 缓存粒度 |
| 122 | +- 通用性:全量属性更好. |
| 123 | +- 占用空间:部分属性更好. |
| 124 | +- 代码维护成本. |
| 125 | + |
| 126 | +### 缓存穿透 |
| 127 | +> 当大量的请求无命中缓存、直接请求到后端数据库(业务代码的 bug、或恶意攻击),同时后端数据库也没有查询到相应的记录、无法添加缓存. |
| 128 | + 这种状态会一直维持,流量一直打到存储层上,无法利用缓存、还会给存储层带来巨大压力. |
| 129 | +> |
| 130 | +#### 解决方案 |
| 131 | +1. 请求无法命中缓存、同时数据库记录为空时在缓存添加该 key 的空对象(设置过期时间)，缺点是可能会在
84FB
存中添加大量的空值键(比如遭到恶意攻击或爬虫)，而且缓存层和存储层数据短期内不一致； |
| 132 | +1. 使用布隆过滤器在缓存层前拦截非法请求、自动为空值添加黑名单(同时可能要为误判的记录添加白名单).但需要考虑布隆过滤器的维护(离线生成/ 实时生成). |
| 133 | +### 缓存雪崩 |
| 134 | +> 缓存崩溃时请求会直接落到数据库上,很可能由于无法承受大量的并发请求而崩溃,此时如果只重启数据库,或因为缓存重启后没有数据,新的流量进来很快又会把数据库击倒 |
| 135 | +> |
| 136 | +#### 出现后应对 |
| 137 | +- 事前:Redis 高可用,主从 + 哨兵,Redis Cluster,避免全盘崩溃. |
| 138 | +- 事中:本地 ehcache 缓存 + hystrix 限流 & 降级,避免数据库承受太多压力. |
| 139 | +- 事后:Redis 持久化,一旦重启,自动从磁盘上加载数据,快速恢复缓存数据. |
| 140 | +#### 请求过程 |
| 141 | +1. 用户请求先访问本地缓存,无命中后再访问 Redis,如果本地缓存和 Redis 都没有再查数据库,并把数据添加到本地缓存和 Redis； |
| 142 | +1. 由于设置了限流,一段时间范围内超出的请求走降级处理(返回默认值,或给出友情提示). |
| 143 | + |
| 144 | + |
| 145 | + |
0 commit comments