玩转Redis的高可用（主从、哨兵、集群）

所谓的高可用，也叫 HA（High Availability），是分布式系统架构设计中必须考虑的因素之一，它是保证系统SLA的重要指标。Redis 高可用的主要有三种模式： 主从模式 ， 哨兵模式和集群模式 。

Redis 提供了 Redis 提供了复制(replication)功能，当一台 redis 数据库中的数据发生了变化，这个变化会被自动地同步到其他的 redis 机器上去。

Redis 多机器部署时，这些机器节点会被分成两类，一类是主节点（master 节点），一类是从节点（slave 节点）。一般 主节点可以进行读、写 *** 作 ，而 从节点只能进行读 *** 作 。一个主节点可以有多个从节点，但是一个从节点只会有一个主节点，也就是所谓的 一主多从结构 。

· 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离;

· Master 是以非阻塞的方式为主 Slaves 提供服务。所以在 Master-Slave 同步期间，客户端仍然可以提交查询或修改请求;

· Slave 同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis 则返回同步之前的数据。

· Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的 IP 才能恢复;

· 主机宕机，宕机前有部分数据未能及时同步到从机，切换 IP 后面还会引入数据不一致的问题，降低了系统的可用性;

· Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂;

· Redis 的主节点和从节点中的数据是一样的，降低的内存的可用性

实际生产中，我们优先考虑哨兵模式。这种模式下，master 宕机，哨兵会自动选举 master 并将其他的 slave 指向新的 master。

在主从模式下，redis 同时提供了哨兵命令 redis-sentinel ，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵进程向所有的 redis 机器人发送命令，等待 Redis 服务器响应，从而监控运行的多个 Redis 实例。一般为了便于决策选举，使用 奇数个哨兵 。多个哨兵构成一个哨兵集群，哨兵直接也会相互通信，检查哨兵是否正常运行，同时发现 master 战机哨兵之间会进行决策选举新的 master

哨兵模式的作用:

· 通过发送命令，让 Redis 服务器返回监控其运行状态，包括主服务器和从服务器;

· 然而一个哨兵进程对 Redis 服务器进行监控，也可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多种哨兵模式。

哨兵很像 kafka 集群中的 zookeeper 的功能。

· 哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。

· 主从可以自动切换，系统更健壮，可用性更高。

· 具有主从模式的缺点，每台机器上的数据是一样的，内存的可用性较低。

· Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

Redis 集群模式本身没有使用一致性 hash 算法，而是使用 slots 插槽 。

Redis 哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台 Redis 服务器都存储相同的数据，很浪费内存，所以在 redis30 上加入了 Cluster 集群模式，实现了 Redis 的分布式存储，对数据进行分片，也就是说每台 Redis 节点上存储不同的内容；每个节点都会通过集群总线(cluster bus)，与其他的节点进行通信。 通讯时使用特殊的端口号，即对外服务端口号加 10000。例如如果某个 node 的端口号是 6379，那么它与其它 nodes 通信的端口号是 16379。nodes 之间的通信采用特殊的二进制协议。

对客户端来说，整个 cluster 被看做是一个整体，客户端可以连接任意一个 node 进行 *** 作，就像 *** 作单一 Redis 实例一样， 当客户端 *** 作的时候 key 没有分配到该 node 上时，Redis 会返回转向指令，指向正确的 node，这有点儿像浏览器页面的 302 redirect 跳转。

根据官方推荐，集群部署至少要 3 台以上的 master 节点，最好使用 3 主 3 从六个节点的模式。

在 Redis 的每一个节点上，都有这么两个东西， 一个是插槽（slot），它的的取值范围是：0-16383， 可以从上面 redis-tribrb 执行的结果看到这 16383 个 slot 在三个 master 上的分布。还有一个就是 cluster，可以理解为是一个集群管理的插件，类似的哨兵。

当我们的存取的 Key 到达的时候，Redis 会根据 crc16 的算法对计算后得出一个结果，然后把结果和 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取 *** 作。

为了保证高可用， redis-cluster 集群引入了主从模式 ，一个主节点对应一个或者多个从节点。当其它主节点 ping 主节点 master 1 时，如果半数以上的主节点与 master 1 通信超时，那么认为 master 1 宕机了，就会启用 master 1 的从节点 slave 1，将 slave 1 变成主节点继续提供服务。

如果 master 1 和它的从节点 slave 1 都宕机了，整个集群就会进入 fail 状态，因为集群的 slot 映射不完整。 如果集群超过半数以上的 master 挂掉，无论是否有 slave，集群都会进入 fail 状态。

redis-cluster 采用去中心化的思想 ，没有中心节点的说法，客户端与 Redis 节点直连，不需要中间代理层，客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可。

对 redis 集群的扩容就是向集群中添加机器，缩容就是从集群中删除机器，并重新将 16383 个 slots 分配到集群中的节点上（数据迁移）。

扩缩容也是使用集群管理工具 redis-trirb。

扩容时，先使用 redis-trirb add-node 将新的机器加到集群中，这是新机器虽然已经在集群中了，但是没有分配 slots，依然是不起做用的。在使用 redis-trirb reshard 进行分片重哈希（数据迁移），将旧节点上的 slots 分配到新节点上后，新节点才能起作用。

缩容时，先要使用 redis-trirb reshard 移除的机器上的 slots，然后使用 redis-trirb add-del 移除机器。

采用去中心化思想，数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布;

可扩展性：可线性扩展到 1000 多个节点，节点可动态添加或删除;

高可用性：部分节点不可用时，集群仍可用。通过增加 Slave 做 standby 数据副本，能够实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave 到 Master 的角色提升;

降低运维成本，提高系统的扩展性和可用性。

1Redis Cluster 是无中心节点的集群架构，依靠 Goss 协议(谣言传播)协同自动化修复集群的状态。但 GosSIp 有消息延时和消息冗余的问题，在集群节点数量过多的时候，节点之间需要不断进行 PING/PANG 通讯，不必须要的流量占用了大量的网络资源。虽然 Reds40 对此进行了优化，但这个问题仍然存在。

2数据迁移问题

Redis Cluster 可以进行节点的动态扩容缩容，这一过程，在目前实现中，还处于半自动状态，需要人工介入。在扩缩容的时候，需要进行数据迁移。

而 Redis 为了保证迁移的一致性，迁移所有 *** 作都是同步 *** 作 ，执行迁移时，两端的 Redis 均会进入时长不等的阻塞状态，对于小 Key，该时间可以忽略不计，但如果一旦 Key 的内存使用过大，严重的时候会接触发集群内的故障转移，造成不必要的切换。

主从模式：master 节点挂掉后，需要手动指定新的 master，可用性不高，基本不用。

哨兵模式：master 节点挂掉后，哨兵进程会主动选举新的 master，可用性高，但是每个节点存储的数据是一样的，浪费内存空间。数据量不是很多，集群规模不是很大，需要自动容错容灾的时候使用。

集群模式：数据量比较大，QPS 要求较高的时候使用。 Redis Cluster 是 Redis 30 以后才正式推出，时间较晚，目前能证明在大规模生产环境下成功的案例还不是很多，需要时间检验。

服务器相信很多计算机专业和电脑爱好者都听过或者了解一些，真正的服务器我们是看不到的也就是现在所说的数据中心，是有保安严守的，闲杂人等一律不让进。比如我们每天浏览的网站、玩的游戏等，所有的数据均存在服务器。所以服务器里的数据非常重要。下面给大家揭开服务器神秘面纱，希望能够给电脑盲朋友一点帮助。

什么是服务器？

首先我们来看专业上服务器是怎么样定义的，服务器是一种高性能计算机，作为网络的节点，存储、处理网络上80％的数据、信息，因此也被称为网络的数据中心。也可以这样讲，服务器指一个管理资源并为用户提供服务的计算机软件，通常分为文件服务器、数据库服务器和应用程序服务器。运行以上软件的计算机或计算机系统也被称为服务器。相对于普通PC来说，服务器在稳定性、安全性、性能等方面都要求更高，因此CPU、芯片组、内存、磁盘系统、网络等硬件和普通计算机有所不同，在质量与处理器数据性能上更出色。

这里通俗的为大家再介绍下，简单的说，服务器和电脑功能都是一样的，我们也可以讲服务器称之为电脑，只是服务器对稳定性与安全性以及处理器数据能力有更高要求，比如我们每天浏览一个网站，发现这个网站每天24小时都能访问，为什么呢，原因在于网站服务器不能关闭，要保证长时间稳定运行，并且要承受很多人同时访问，因此服务器在稳定性、质量以及性能方面要比普通电脑有更苛刻要求。比如我们电脑如果一年四季不关机，可能很容易坏掉，但针对个人计算机，不可能这样做，因此电脑硬件的设计要求相比服务器要低不少。因此我们可以这样理解，其实服务器就是比我们一般电脑更高级的电脑，再各个硬件上拥有更高标准的做工，服务器内部硬件和一般电脑一样，均是由CPU、内存、主板、显卡、硬盘等组成，不过需要注意的是，服务器由于偏向处理器处理器数据能力，因此很多服务器主板均可以安装多个处理器、多条内存以及更多硬盘，因此看起主板、机箱等均比较庞大，最后服务器由于对于显示性能不是很重要，很多服务器都不需要显示器，远程管理即可，因此一般服务器均使用的是集成显卡。

服务器内部结构（与普通电脑相似，只是配置更高，硬件质量更好）

不过服务器与普通电脑的区别也不仅仅是硬件性能指标不同，在系统方面也很不相同，一般我们电脑是使用windows，但是服务器大多数用的是linux系统，这类系统为服务器量身定做比较稳定，服务器硬件与普通电脑硬件方面是有差异的，如果你是组装服务器，那么一定需要选择服务器专属的配件，比如ECC内存，SAS硬盘等。

无服务器架构（Serverless）是一种将应用与基础设施彻底分离的架构理念，开发人员无需关心基础设施的运维工作，只需专注于应用逻辑的开发，真正实现了d性伸缩与按需付费。当前各大云服务商和头部互联网企业的内部业务 Serverless 化升级改造已经开始小范围试水；中小企业基于 Serverless 的业务应用也初见端倪，已然可见初具规模的企业级应用，未来可期。Serverless 生态已初具规模，可以预见，Serverless 将成为下一代云计算服务形态的趋势。

在此背景下， 云函数（SCF）、d性微服务（TEM）和d性容器服务（EKS）联合其他相关产品，在 2021 年 Serverless 平台技术能力评估中，共同获得国内首批 Serverless 平台技术能力最高先进级认证。

今年 7 月，在中国信息通信研究院、中国通信标准化协会联合主办的 “2021 可信云大会” 上， 腾讯云拿下了 5 项大奖和 10 项可信云认证，在云存储、Serverless 等各细分领域评测中，获得 54 项可信云认证，数量位居中国云厂商第一 。腾讯云云函数（SCF）、d性微服务（TEM）和d性容器服务（EKS）深度参与了此次 Serverless 标准制定和实施过程，腾讯云的 Serverless 产品矩阵所提供的平台技术能力也得到了同行的一致认可。

通过本次 Serverless 标准，为大家带来以下几方面关于 Serverless 发展趋势的解读：

当我们把 Serverless 理念和这些产品结合时，Serverless 化的文件系统（CFS）、数据库（TDSQL-C）、网关（API Gatgeway）和中间件（TDMQ）等可大幅度降低 Serverless 应用的开发和运维成本，让开发者真正聚焦于业务的核心能力，把核心的研发力量和IT投资最大化企业的核心差异化竞争力。通过最终的需求驱动，我们可以预见到，各个云服务产品的 Serverless 化或许是未来云计算发展的必经之路。

过去场景化的 FaaS 是 Serverless 较为主流的应用形态，落地案例也以轻量级的站点、SSR 和云上“云上粘合剂”居多。在本次 Serverless 标准制定过程中，对于如何评估企业实际的 Serverless 落地形式大家展开了丰富的讨论和交流。我们认为 Serverless 的应用形态可以是 FaaS、微服务甚至是单体应用；运行环境可以是原生的运行时，也可以是容器镜像；具体落地时，可以用来对外提供 API 接口，也可以用来运行 音视频转码、直播推流 等计算任务，还可以用来完成 站点压测、AI 推理 等任务。

但是现有存量系统的 Serverless 化无法一蹴而就，这是一个不断设计和矫正的过程，应用 Serverless 化也需要经历迁移、优化和云原生架构改造的几个阶段，不同阶段之间需要有一个较为平滑的切换过程，借助于云函数的 Web Function 的功能可以让迁移过程更加平滑，只有实际负载运行在 Serverless 上之后，才能基于生产环境的实际运行结果、采集定量的指标持续进行 Serverless 应用的优化和云原生改造，进一步发挥出 Serverless 的价值。

当构建应用所依赖的服务逐渐向云上迁移的时候，开发环境也进一步“云”化，和本地开发相比也面临一些新的挑战，比如代码生效时间、本地测试、远程调试和离线开发等等，这些都是影响开发者效率的关键环节。在本次的 「Serverless 平台技术能力」标准中，单独把对于工具链的支持作为衡量 Serverless 平台技术能力的重要维度之一。一个成熟的 Serverless 开发者平台需要能够提供比较友好的IDE支持，让开发者使用熟悉的开发工具进行 Serverless 应用的开发，降低开发者的切换成本；除此之外从本地或者远程测试的时候，需要有良好的工具支持，可以方便地发起调用，触发应用执行并快速返回结果，当结果不符合预期的时候也需要有一系列监控、日志等排障手段帮助开发者快速定位问题。

作为 Serverless 社区最流行的一站式开发者工具， Serverless Framework 拥有百万级别的活跃应用程序以及 50000+ 的日下载量。Serverless Framework 早在 2019 年就已经和腾讯达成了大中华区独家的战略合作，和腾讯云的云函数等 Serverless 产品深度集成，同时社区也有大量开箱即用的插件和模板，帮助开发者快速上手 Serverless 应用开发。除此之外，云开发也是国内最大的微信小程序应用开发平台， 四川天府 健康 通、深圳机场智慧航旅服务等小程序应用都是运行在腾讯云的 Serverless 平台之上。

云函数（Serverless Cloud Function，SCF）是腾讯云为企业和开发者们提供的无服务器执行环境，帮助您在无需购买和管理服务器的情况下运行代码。只需编写核心代码并设置代码运行的条件，即可在腾讯云基础设施上d性、安全地运行代码。

只需简单修改监听端口，即可将目前流行的 Nodejs 框架直接部署上云，享受 Serverless 技术带来的免运维、低成本、按需扩缩容的众多优势。

突破传统 FaaS 形态产品的执行时长的限制， 首家支持运行长达 24 小时的长时任务的 FaaS 产品 ，支持体积较大的音视频文件处理、直播推流、数据分析等多种场景。

业界首发支持分配 120GB(122,880MB) 大内存环境，可以更加轻松地处理具有更高内存或更密集计算需求的工作负载，如音视频处理、大数据分析等。

通过 Web Function、容器化镜像等方式平滑把应用迁移至云函数之上，支持托管 H5 页面、API、SSR 应用、小程序等多种形态的应用形式，缩短研发周期，快速收集市场反馈从而加速产品迭代。

无需运维虚拟机或者其他计算集群，利用云函数提供的极致d性、按量计费等特性，高效、低成本地进行音视频的录制、转码、混流、剪辑和推流等 *** 作，让企业聚焦于音视频处理逻辑本身，从而不断提升内容质量，优化视听体验。

可以通过触发器连接其他的云服务，如对象存储（COS）、日志服务（CLS）等其他服务，当上游的数据发送变化的时候自动触发函数执行计算逻辑，典型的使用场景包括：CDN 刷新和预热、中间件消息转存、文件备份等。

支持定时、消息队列等多种形式触发函数执行输出处理逻辑，进行数据采集、数据清洗、ETL 等数据处理 *** 作，处理之后的数据可以直接存储至下游的数据仓库、业务数据库或者 BI 分析系统等。

腾讯云d性微服务 (Tencent Cloud Elastic Microservice, TEM) 是面向微服务应用的 Serverless PaaS 平台，实现 Serverless 与微服务的完美结合，应用零改造上云，按量付费，免运维，提供开箱即用的微服务应用托管服务。

d性微服务拥抱开源，支持 Spring Cloud 等微服务应用零改造上云，提供应用运行托管、服务注册发现、微服务治理、多维度监控等能力，满足 Consul、Eureka 等多种注册中心需求。d性微服务帮助您创建和管理云资源，并提供秒级d性伸缩，您可按需使用、按量付费，极大降低资源和运维成本，让您充分聚焦企业核心业务逻辑，助力业务成功。

d性微服务通过应用托管、服务注册与发现、服务治理、调用链与多维度监控等功能力，为客户提供开箱即用的微服务解决方案。帮助企业用户快速构建微服务应用，大幅提升运维效率，降低服务治理的复杂度与技术门槛，让企业聚焦核心业务本身，助力客户成功。

在业务呈现潮汐特性、突发流量等场景下，容易出现访问响应超时、错误率提升等问题。腾讯云d性微服务提供秒级d性伸缩能力，帮助企业客户轻松应对流量高峰。

腾讯云d性微服务帮助客户持续集成与交付，实现微服务应用快速迭代。从代码开发到应用交付，d性微服务提供 IDE 插件、灰度发布等多发布策略的能力，助力企业客户快速验证业务价值。

d性容器服务 EKS（Elastic Kubernetes Service）是腾讯云容器团队的推出的 Serverless 化 Kubernetes 服务 ，无须用户购买节点，直接部署工作负载。其完全兼容原生 Kubernetes，支持使用原生方式购买及管理资源，按照容器真实使用的资源量计费。

无论是自建 K8s 集群，还是腾讯云 TKE 托管集群，只要网络互通，即可通过部署 EKS 虚拟节点的方式，几乎无成本扩展集群资源池。在扩容 Pod 时可自动或手动快速将 Pod 调度到「虚拟节点」对应的腾讯云公有云资源上。

相比传统的通过扩缩服务器去调度资源（流程重，耗时久），虚拟节点提供一种直接调度 Pod 的能力，可以更快、更高效的d性。

使用d性容器服务 EKS 来运行微服务，免除用户对计算节点的运维工作。服务可根据负载情况自动伸缩，使用最合理的资源量来承载应用，降低资源使用成本。

使用d性容器服务 EKS 运行离线计算任务，只需准备容器镜像，即可快速部署任务负载。另外，d性容器服务 EKS 仅收取任务真实运行时间所使用算力的费用，任务结束 Pod 自动释放即结束计费。

d性容器服务 EKS 支持使用 CPU、GPU 以及 vGPU 来运行在线推理服务，丰富的资源规格和d性伸缩的负载，使运行服务更高效、更经济。

立即体验腾讯云 Serverless Demo，领取 Serverless 新用户礼包 腾讯云 Serverless 新手体验

---