沙龙晃荡 | 去哪儿、陌陌、ThoughtWorks在主动化运维中的实践！10.28不见不散！

我们在 Sky Betting&Gaming 中应用 Redis 作为共享内存缓存，用于那些须要跨 API 办事器或者 Web 办事器辨别令牌之类的操作。在 Core Tribe 内，它用来赞助处理日益宏大年夜的登录数量，特别是在劳碌的时刻，我们在一分钟内登录数量会跨越 20,000 人。这在很大年夜程度上实用于数据存放在大年夜量办事器的情况下(在 SSO 令牌用于 70 台 Apache HTTPD 办事器的情况下)。我们比来着手进级 Redis 办事器，此进级旨在应用 Redis 3.2 供给的原生集群功能。这篇博客欲望解释为什愦我们要应用集群、我们碰到的问题以及我们的解决筹划。

在开端阶段(或至少在进级之前)

我们的传统缓存中每个缓存都包含一对 Redis 办事器，应用 keepalive 确保始终有一个主节点监听浮动 IP floating IP地址。当出现问题时，这些办事器对须要很大年夜的精力来进行治理，而故障模式有时是异常各类各样的。有时，只许可攫取它所持有的数据，而不许可写入的从属节点却会获得浮动 IP 地址，这种问题是相对轻易诊断的，但会让无论哪个法度榜样试图应用该缓存时都很麻烦。

新的应用法度榜样

是以，这种情况下，我们须要构建一个新的应用法度榜样，一个应用共享内存缓存shared in-memory cache的应用法度榜样，然则我们不欲望对该缓存进行迂回的故障切换过程。是以，我们的请求是共享的内存缓存，没有单点故障，可以应用尽可能少的工资干涉来竽暌功对多种不合的故障模式，并且在事宜恢复之后也可以或许在很少的工资干涉下恢复，一个额外的请求是进步缓存的安然性，以削减数据泄漏典范围(稍后再说)。当时 Redis Sentinel 看起来很有欲望，并且有很多法度榜样支撑代劳 Redis 连接，比如 twemproxy。这会导致还要安装其它很多组件，它应当有效，并且人际交互起码，但它复杂而须要运行大年夜量的办事器和办事，并且互相通信。

将会有大年夜量的应用办事器与 twemproxy 进行通信，这会将它们的调用路由到合适的 Redis 主节点，twemproxy 将大年夜 sentinal 集群获取主节点的信息，它将控制哪台 Redis 实例是主，哪台是大年夜。这个设置是复杂的，并且如有单点故障，它依附于 twemproxy 来处理分片，来连接到精确的 Redis 实例。它具有对应用法度榜样透明的长处，所以我们可以在理论上做到将现有的应用法度榜样转移到这个 Redis 设备，而不消改变应用法度榜样。然则我们要大年夜头开端构建一个应用法度榜样，所以迁徙应用法度榜样不是一个必须前提。

荣幸的是，这个时刻，Redis 3.2 出来了，并且内置了原生集群，清除了对单一 sentinel 集群须要。

它有一个更简单的设置，但 twemproxy 不支撑 Redis 集群分片，它能为你分片数据，然则如不雅测验测验在与分片不一致的集群中如许做会导致问题。有参考的指南可以使其匹配，然则集群可以主动改变情势，并改变分片的设置方法。它仍然有单点故障。恰是在这一点上，我将永远感激我的一位同事发清楚明了一个 Node.js 的 Redis 的集群发明驱动法度榜样，让我们完全放弃了 twemproxy。

是以，我们可以或许主动分片数据，故障转移和故障恢复根本上是主动的。应用法度榜样知道哪些节点存在，并且在写入数据时，如不雅写入缺点的节点，集群将主动重定向该写入。这是被选的设备，这让我们共享的内存缓存相当结实，可以没有干涉地敷衍根本的故障模式。在测试时代，我们切实其实发清楚明了一些缺点。复制是在一个接一个节点的基本长进行的，是以如不雅我们损掉了一个主节点，那么它的大年夜节点会成为一个单点故障，直到逝世去的节点恢复办事，也只有主节点对集群健康投票，所以如不雅我们一下掉去太多主节点，那么集群无法自我恢复。但这比我们以前的好。

向进步

跟着应用集群 Redis 设备的新法度榜样，我们对于老式 Redis 实例的状况变得越来越不适应，然则新法度榜样与现有法度榜样的范围并不雷同(跨越 30GB 的内存专用于我们最大年夜的老式 Redis 实例数据库)。是以，跟着 Redis 集群在底层获得了证实，我们决定迁徙老式的 Redis 实例到新的 Redis 集群中。

因为我们有一个原生支撑 Redis 集群的 Node.js Redis 驱动法度榜样，是以我们开端将 Node.js 法度榜样迁徙到 Redis 集群。然则，若何将数十亿字节的数据年腋荷琐处所移动到另一个处所，而不会造成重大年夜问题?特别是推敲到这些数据是认证令牌，所以如不雅它们错了，我们的终端用户将会被登出。一个选择是请求网站完全下线，将所有内容都指向新的 Redis 群集，并将数据迁徙到个中，以欲望获得最佳效不雅。另一个选择是切换到新集群，并强迫所有效户再次登录。因为显而易见的原因，这些都不是异常合适的。我们决定采取的替代办法是将数据同时写仁攀老式 Redis 实例和正在调换它的集群，同时跟着时光的推移，我们将逐渐更多地向该集群攫取。因为数据的有效期有限(令牌在几个小时后到期)，这种办法可以导致零停机，并且不会稀有据损掉的风险。所以我们这么做了。迁徙是成功的。

剩下的就是办事于我们的 PHP 代码(个中还有一个项目是有效的，其它的最终是没须要的)的 Redis 的实例了，我们在这过程中碰到了一个艰苦，实际上是两个。起首，也是最紧急的是找到在 PHP 中应用的 Redis 集群发明驱动法度榜样，还如果我们正在应用的 PHP 版本。这被证实是可行的，因为我们进级到了最新版本的 PHP。我们选择的驱动法度榜样不爱好应用 Redis 的授权方法，是以我们决定应用 Redis 集群作为一个额外的安然步调 (我告诉你，这将有更多的安然性)。当我们用 Redis 集群调换每个老式 Redis 实例时，修复似乎很直接，将 Redis 授权封闭，如许它将会响应所有的请求。然而，这并不是真的，因为某些原因，Redis 集群不会接收来自 Web 办事器的连接。 Redis 在版本 3 中惹人的称为“保护模式”的新安然功能将在 Redis 绑定到任何接口时将停止监听来自外部 IP 地址的连接，并无需设备 Redis 授权暗码。这被证实相当轻易修复，但让我们保持当心。

　　推荐阅读

　　3行Python代码完成人脸识别

沙龙晃荡 | 去哪儿、陌陌、ThoughtWorks在主动化运维中的实践！10.28不见不散！ Face Recognition软件包这是世界上最简单的人脸辨认库了。你可以经由过程Python引用或者敕令行的情势应用它>>>详细阅读

本文标题：如何让网站不下线从Redis 2迁移到Redis 3

地址：http://www.17bianji.com/lsqh/38005.html

 1/2    1