公司网站维护做期货苯乙烯的网站

公司网站维护,做期货苯乙烯的网站,app推广有哪些渠道,国外免费空间申请在前面的文章中#xff0c;我们聊了 Redis 的持久化、锁机制以及热 Key 问题。今天#xff0c;我们跳出具体的命令细节#xff0c;从宏观架构的角度来看看 Redis 是如何一步步“做大做强”的。在生产环境中#xff0c;我们几乎不会只部署一台 Redis。为什么#xff1f;因为…在前面的文章中我们聊了 Redis 的持久化、锁机制以及热 Key 问题。今天我们跳出具体的命令细节从宏观架构的角度来看看 Redis 是如何一步步“做大做强”的。在生产环境中我们几乎不会只部署一台 Redis。为什么因为单机 Redis (Single Node)存在三个无法回避的致命伤单点故障 (SPOF)万一机器宕机全村吃饭。容量瓶颈一台机器的内存终究有限存不下海量数据。性能瓶颈QPS 再高也受限于单机的 CPU 和网卡带宽。为了解决这些问题Redis 的架构经历了从主从复制到哨兵模式再到分片集群的进化之路。前置知识什么是高可用简单来说redis单节点存在比如性能瓶颈、宕机风险等问题可用性低那高可用就是解决这个单节点低可用的问题。一、 第一阶段主从复制 (Master-Slave) —— 解决“备份与分流”为了防止“单点故障”最直接的思路就是找个替补。这就是主从架构的初衷。我们部署多台 Redis一台做主节点 (Master)几台做从节点 (Slave)。1. 核心架构Master唯一的“写”入口。负责接收写请求并将数据异步同步给 Slave。Slave只读副本。负责接收读请求并被动同步 Master 的数据。2. 为什么要读写分离这源于一个业务常识在绝大多数互联网场景中读操作远远多于写操作比如微博看的人多发的人少。如果不分离所有压力都在 Master 身上。分离后Master 专注处理那 10% 的写请求N 个 Slave 分担那 90% 的读请求。这样既提高了并发量又避免了写操作如持久化阻塞读请求。3. 依然存在的问题主从架构解决了**“数据备份”和“读性能”**问题但它有一个致命的缺陷不够智能。如果 Master 突然宕机Slave 不会自动变成 Master。运维人员必须半夜爬起来手动修改配置把 Slave 提拔上来。在人工介入的这段时间服务是不可写的。二、 第二阶段哨兵模式 (Sentinel) —— 解决“自动故障恢复”为了解决主从架构“人工恢复慢”的问题Redis 引入了 哨兵 (Sentinel) 机制。你可以把哨兵理解为一群**“自动化的运维巡逻队”**。它们不存数据只干三件事监控、选主、通知。1. 哨兵的三大职责监控 (Monitoring)哨兵集群通过心跳机制Ping每秒检查 Master 和 Slave 是否活得好好的。主观下线一个哨兵觉得 Master 没回消息。客观下线超过半数Quorum哨兵都觉得 Master 没回消息那才是真挂了。自动故障恢复 (Failover)当 Master 挂了哨兵会自动从剩下的 Slave 中选出一个新的 Master。通知 (Notification)哨兵充当了服务发现的角色。客户端连接的是哨兵当 Master 换人了哨兵会把新地址推给客户端。2. 新 Master 是怎么选出来的当 Master 倒下哨兵会按照以下规则依次筛选 Slave排除法先把那些断开连接很久、不健康的 Slave 踢出局。拼优先级看slave-priority配置数字越小优先级越高0 表示永不当选。拼进度 (Offset)谁的数据最全Offset 最大谁就当选。这意味着它和旧 Master 的数据差异最小。拼人品 (RunID)如果以上都一样就按运行 ID 排序选 ID 小的。3. 依然存在的问题哨兵模式实现了高可用 (High Availability)但它依然是**“主从模式”**的变种。写瓶颈依然只有一个 Master 负责写无法应对高并发写请求。容量瓶颈所有节点存的数据都是一样的无法突破单机内存上限比如你只有 64G 内存就存不下 100G 数据。 解释比如我有 3 台机器每台 64G加在一起我就能存 $64 \times 3 192G$ 的数据。但在 Redis 主从/哨兵架构下这是错的你依然只能存 64G。Master 有什么Slave 就必须有一份一模一样的。三、 第三阶段分片集群 (Cluster) —— 解决“海量数据与高并发写”为了解决“存不下”和“写不过来”的问题Redis 3.0 推出了 Redis Cluster。这是真正的分布式去中心化方案实现了多主多从。1. 核心原理散列插槽 (Hash Slots)见下文解释Redis Cluster 没有把数据直接绑定到节点上而是引入了一个概念插槽 (Slot)。整个集群被逻辑切分为16384个插槽。数据绑定插槽当存一个 Key 时Cluster 会根据CRC16(key) % 16384计算出这个 Key 属于哪个插槽。插槽绑定节点这 16384 个插槽被均匀分配给集群中的多个 Master 节点。2. 为什么要这么设计解耦数据跟节点没关系只跟插槽有关系。易扩容如果你想增加一个 Master 节点只需要从其他节点挪一些“插槽”给新节点即可。数据迁移时通过插槽搬运非常方便不需要全量重新哈希。3. Cluster 的能力多主写入集群中有多个 Master每个 Master 负责一部分插槽。这意味着写请求被分散了性能线性提升。高可用每个 Master 都有自己的 Slave。如果某个 Master 挂了它的 Slave 会自动顶上集群内部实现了类似哨兵的选举机制。智能路由客户端请求任意一个节点如果数据不在该节点它会返回重定向错误告诉客户端去哪个节点找。附对于插槽——全量哈希的优化以及解耦思想的理解1. 如果没有插槽直接哈希 (The Old Way)假设你是一个物流主管你有 3 辆车 (Node A, B, C)你要运送 10 万个包裹 (Keys)。最笨的办法直接绑定节点规则拿到包裹看一下单号除以 3 取余数。余数 0 - 扔进 A 车。余数 1 - 扔进 B 车。余数 2 - 扔进 C 车。灾难发生了扩容生意太好你买了一辆新车 D 车节点增加到 4 个。 规则变了现在要除以 4 取余数。后果原来的包裹单号是 33 % 3 0 (在 A 车)。现在的包裹单号是 33 % 4 3 (得去 D 车)。你会发现几乎所有的包裹都需要从原来的车里翻出来重新分配到新车去。 这就叫“全量重新哈希”。在数据迁移期间你的物流系统基本瘫痪了。2. 有了插槽引入“中间层” (The Slot Way)Redis Cluster 说“别把包裹直接扔车里先把包裹装进统一的箱子里” 这 16384 个插槽就是 16384 个固定的塑料收纳箱。步骤一包裹进箱子这一步永远不变不管你有几辆车我的规则是铁打不动的 包裹 (Key) - 经过 CRC16 算法 - 算出它属于 第 500 号箱子 (Slot 500)。重点这个包裹永远属于第 500 号箱子天塌下来它也在这个箱子里。步骤二箱子上车这一步灵活多变现在你有 3 辆车 (Node A, B, C)。 你只需要分配箱子就行了A 车负责运送 0 ~ 5000 号箱子。B 车负责运送 5001 ~ 10000 号箱子。C 车负责运送 10001 ~ 16383 号箱子。3. 为什么这样扩容就容易了现在生意好了你又买了一辆新车 D 车。 这就是插槽的魔力时刻不需要动包裹你不需要去把每一个包裹拿出来重新算。包裹依然在它原来的箱子里。只需要挪箱子 你对 A 车说“把你那里的 0~1000 号箱子搬给 D 车。” 你对 B 车说“把你那里的 5001~6000 号箱子搬给 D 车。” 你对 C 车说“把你那里的 10001~11000 号箱子搬给 D 车。”结果A、B、C 车腾出了一点空间。D 车也有活干了。整个过程只是搬运了几个箱子而不是把几十万个散落的包裹重新分拣。4. 总结如何理解“解耦”插槽就是一个**“中间商”**。没有插槽时数据 - 节点直接强绑定节点变了数据位置全乱。有插槽时数据 - 插槽强绑定由于插槽数量 16384 是固定的所以这个关系永远不变。插槽 - 节点弱绑定可以随时把插槽从这个节点挪到那个节点。一句话总结插槽就像是搬家时的**“打包箱”**。 如果没有打包箱搬家时你要一双袜子、一本书地搬数据迁移极慢。 有了打包箱你只需要把箱子搬上车至于哪个箱子在哪个车上随时可以调整。这就是 Redis Cluster 灵活扩容的秘密。四、 总结与选型我们将这三个架构做一个最终对比架构模式核心特点解决的问题遗留的问题适用场景主从复制一主多从读写分离单点故障、读性能瓶颈故障恢复需人工、单机容量限制读多写少、数据量小、允许短暂宕机哨兵模式主从 自动监控自动故障恢复 (HA)依然是单主写入、单机容量限制读多写少、对可用性要求高分片集群多主多从数据分片海量数据存储、高并发写架构复杂、不支持部分跨 Slot 操作海量数据、高并发写、核心业务一句话总结如果你的 Redis 只是为了做缓存且数据量不大主从就够了。如果你不能忍受机器挂了要半夜起来修那就上哨兵。如果你有100G 以上的数据或者每秒 10 万次的写请求请毫不犹豫地使用Redis Cluster。最后说一下我自己对于扩容的理解我觉得容量问题的解决可以从两个维度去理解第一个是多主多从这多主之间并不是和主从一样是复制备份的关系另外引入插槽的概念它优化了扩容带来的全量哈希的危害。所以集群架构解决了容量问题。