Redis架构+实用工具一一解决DBA痛点

• 快。因为随着我们业务的快速发展，我们每天可以运行N个系统，建立N个群体，让我们的业务不断增长。一个好的架构应该能够让你的业务更快、更人性化！
• 稳定。随着集群和机器数量的增加，运维过程中几乎每天都会遇到扩容、机器搬迁、维护等需求。那么当Redis集群底层节点发生变化时，必须保证业务不受影响。
• 准确。 Redis会因为宕机、误操作等原因发生切换。如何减少误切换的影响，需要良好的自动切换机制！

设定好小目标后，就该开始选择架构了。以下是已考虑的一些要点：

1。 Redis主从还是Redis集群？

• Redis主从：稳定、易维护，但扩容成本较高，牵引过程中会影响业务。
• Redis集群：维护成本高，扩展简单，相对复杂。卡住的时候就得学习源码，添加节点也比较困难。

所以我们在使用的时候，选择Redis主从，比较简单稳定的版本。当然我们还是用2.8等，只要性能还可以。

2。 Proxy或Proxy

• 可以隔离业务与底层Redis集群的关系，方便运维人员管理后端集群；
• 可以管理连接池；
• 可以控制HASH规则。

3。高可用性

我们提供Sentinel，当主机出现问题时可以自动升级从机。

4。元数据管理

包括前面提到的元数据，我们会考虑使用MySQL还是ZooKeeper。使用ZooKeeper的好处是当节点发生变化时，可以通知所有业务端。

对于我们来说，使用MySQL更容易维护，也可以更清楚地看到哪些业务与节点信息匹配。结果我们一开始只使用ZooKeeper，随着后来的发展，我们同时使用了MySQL+ZooKeeper。 架构设计

这是Redis架构访问示例的流程图。也是去哪儿近几年使用的架构，中间做了一些升级。

首先，客户端通过Proxy集群，根据Redis节点信息访问Redis集群。比如Key到达后，通过一些一致的Hash来访问，Redis节点信息可以理解为被Proxy集群捕获。或者将打包客户端访问为商业客户端。 架构扩展 - 代理

1。更改

因为我们为每个业务都定义了一个Namespace，里面存放了相关信息（一些主节点信息或者连接池大小可以在这里找到设置）。客户端登录时，首先从ZK中读取Redis信息，并从Namespace中获取这些信息。如果获取到三个节点信息，则可以立即根据上面配置的连接池大小确定对应的连接数。 ，所以当我们的业务来了，我们就得到了那个节点。

如果我的企业现在有另一把钥匙，我应该如何访问它？这个Key首先在Proxy或者客户端访问中通过一致性算法计算出来，然后就可以将一个特定的Key分配给集群中的某个节点。我们都可以请求这个节点，操作里面的数据，但是会出现一个问题：如果节点停止了怎么办？这里我们需要激活哨兵组。

Sentinel可以分布在各个机房，每个实例分配一组哨兵（每个实例可以有5个哨兵监控）。如果主节点出现故障，我们可以通过哨兵选举机制将Redis从实例提升为主实例。旧实例升级后可自动变更为从实例。但此时，业务方并不知道自己拿到的仍然是旧样本，只是发现现在无法连接了。

此时，我们使用Sentinel来修改ZK信息，因为切换Sentinel后，我们就会知道新的master实例在哪里。我们可能会酌情修改信息。修改完成后，我们就可以触发客户端了，我们可以让客户端知道新的主节点是谁后，重新建立连接，发现客户端连接到了新的地方。这是一个简单的Redis架构。

但是这个Redis架构有一个问题：如果集群一开始是3个节点，如何从3个节点扩展到5个节点？因为所有的数据都要重新进行哈希处理，所以我可以构建前五个实例，然后根据同步工具和我们自己写的新的哈希规则来分析这三个实例的AOF文件。通过不断分析AOF文件，将这三个样本数据集通过新的哈希规则哈希到五个节点，最后手动修改ZK信息告诉我们现在已经扩展到五个节点。

如果我们的同步工具的运行速度跟不上Redis的写入速度，可能会导致同步无法完成。因此，为了不影响我们的业务运营，我们可以修改这个区域。

首先我们使用简单的一致Hash，然后在上面创建第二层Hash，这样第一层Hash这个节点，和第二层Hash就可以简单求余了。对于我们来说，通过这种方式，扩展非常容易，并且主从模型有效。

2。自定义哈希规则

我们可以自定义哈希规则。如果一层Hash层不能解决问题，则创建第二层Hash层，并对某些节点进行扩容。相比之前只能扩容三个节点，这次可以扩容五个节点。然而，在进行第二层哈希时，每个节点都可以扩展。这样运维非常简单，只需要搭建两个slave即可。图书馆。

3。安全

安全方面是为了保护客户端免受危险命令的影响，首先不允许危险的DEL操作，包括更危险的FLUSH操作和一些新的操作。

这个操作很容易导致Redis死机，所以我们需要过滤有害命令。因此，在DBA运维过程中，当节点信息发生变化时，客户端可以自动更新，包括集群信息、连接池信息等。

4。连接池

根据连接池的规则，某个节点的连接数可能会太大，可能达到八九千甚至上万个连接，而客户也可能不会。连接肯定很多，而且有很多连接被废弃，所以我们要改变MySQL中数据池的数量，以便在检测到监控异常并通过ZK通知时快速响应。这不会对我们的业务产生影响。 架构扩展 - Sentinel

1。一对一：哨兵组为一个节点，维护成本较低。

2。多机房分配：更灵敏、准确。

3。自动切换：前提是从库一般不提供服务。当主库宕机时，会自动切换并通过ZK和配置中心推送新的主节点信息到业务端。让从库提升为主库。

4。注意：包括ZK业务端自动感知，包括业务上线时需要手动切换哨兵。同时还要检测高可用，机器是否可用，架构是否有问题等。此时可以通过Sentinel改变ZK，Proxy也会自动感知。

5。 DBA入口：登录后，必须查看监控信息和报警信息，确认哨兵是否真正开启，或者ZK信息是否更新，包括更新后是否收到业务。如果不被接受，则必须再次手动检查，但这种机制对我们来说相当简单，因为很多事情都可以通过该工具完成。 架构扩展-ZooKeeper

ZooKeeper主要负责两件事：记录配置信息和订阅通知。首先，它会为每个业务制定一个Namespace概念，这样与业务相关的各种信息都可以设置在这里。

另外，当集群节点信息发生变更时，会通过ZooKeeper通知客户端或者Proxy，以便快速响应。但有一个问题，发出通知时可能会失败。

流程及使用规则

设计好Redis架构后如何使用？

1。解释业务和沟通需求。 我们需要确认业务使用场景、容量、QPS等一系列信息。

2。发展集群模式。 要建立一个好的集群，您需要十到二十个节点。初始阶段需要配置模式来判断是否缓存。否则，报警信息会不同，信息监控点设置也会不同。

3。自动创建集群。 您可以使用自己的工具快速自动创建多个组。

4。部署高可用性和故障转移。 高可用部署一定要有故障转移机制，因为可能部署了但没有真正细化，手动翻转可能会出现问题。

这里我们做一个简单的工具，就是我们构建一个集群（有一百个实例），但是我们无法检测到每个实例，所以我们可以在级别上确定集群，如果是核心。集群中，我选择90%自动执行故障转移。如果集群是非核心的，我选择60%自动执行故障转移。

5。初始化配置中心并填写所有信息。

6。最后通知业务组业务组已经成立。

自动扩展

我只讲第一版和第二版的扩展方案和流程，这里详细整理一下。

首先，我们得到了生意。也许是压力扛不住，响应慢，容量不足，或者是运维方触发的，使得运维方一开始检测到的实际内容是10G，但是当我们监控的时候。 ，已经达到15G了，这个时候我们可能就需要扩容了。

随着不断的发展，我们一开始只设置了10G，但是慢慢会超过10G、20G，因为当Redis节点的存储容量越来越大时，运维成本也会增加。另外，10G搭建一个主从实例很简单，但是如果是20G或者30G的话，恢复时间会很长，所以运维方面也会触发需求。

如何拓展业务能力？其实业务不关心，但是运维难度很大。这就是刚才提到的第一个解决方案：编写自己的同步工具来扩展第一个Hash层。

如果我们有两层Hash，扩展就非常容易。只建两个从库和三个从库。但安装完成后会出现一个问题：数据中有冗余数据。

也就是说，我们清理环境、搭建主从的时候，只要把数据迁移到那里，然后更新配置，通知业务组，让他们检查就可以了。但是这里有可能集群从三个节点变成了五个节点，因为每个节点扩容后，一部分数据是垃圾数据，而一部分数据在做Hash的时候就不需要了，所以我们需要使用它根据新的Hash数据，清理旧信息，手动删除不会影响业务。这样我们的产能扩张就完成了。 优点和缺点

1.优点：

• 易于扩展：直接建一个从库即可。
• 易于设置：还可以控制节点设置、连接池信息等信息，自动感知业务。
• 易于维护。
• 稳定性：采用哨兵机制进行保护。

2。缺点：

• 缩放比较复杂。如何将三个节点减少为两个节点？我还没有想到什么好的办法。您可以设置最大内存，例如从10G到5G。当然，事件数量保持不变。
• 升级客户端很困难。由于所有业务都需要升级，目前采用的原则是老业务仍然可以使用第一版本的哈希规则，新业务将使用第二版本。

有了良好的Redis架构之后，我们还需要其他工具或者平台来帮助DBA进行管理吗？在本节中，我将向您介绍我的经验。 运维小工具

我们可以创建多种运维小工具，包括部署相关的自动化小工具、平滑迁移、内存分析工具、数据清理等。

Redis管理平台

除了简单的小工具，你还可以安装一些人工智能的东西。我们只是创建了一个可以帮助您获取元数据、日常操作、监控和警报、自动化和其他管理的平台。其中：

• 元数据管理：包括机器、集群、节点和业务主管理。
• 日常操作：可供开发的操作，包括查询、调整参数、慢查询、数据清理等。
• 监控和警报：对于缓存，我们不设置最大内存警报。前面说过，使用集群时，需要决定是存储还是缓存。把这个部分分类之后，就可以在这个平台上进行很多操作了。
• 自动化：包括自动部署和自动扩展。

对于DBA来说，备份是日常工作，Redis也不例外。这里我们可以结合RDB+AOF功能。因为主数据库可能压力很大，而RDB可能每半小时运行一次。如果这半个小时主数据库卡住了怎么办？此时就可以打开从库了。

那为什么要把RDB和AOF结合起来呢？因为如果我们有RDB，数据可能会丢失，而如果我们只使用AOF文件，恢复过程会非常慢。有的商家说我可以允许一些数据丢失，但是需要尽快恢复。

因此，我们选择两者的结合。不仅恢复速度非常快，而且保证即使主从数据库宕机，数据仍然可以恢复。当然，我们还有另一个可用的机房，仅供核心使用。我们来谈谈吧。按理说，这两种解决方案的结合通常都能满足我们的需求。 4。总结

最后我们要了解一下业务，了解Redis是在哪里、如何使用的。一旦我们知道了这一点，我们就可以为我们的架构选择一种更简单、更合适的技术。包括做好自动化。因为如果要靠很多人来操作和维护的话，会很累。如果我们有一个好的管理平台和自动化工具来帮助我们，那么我们将会收到事半功倍的效果。

为了未来的探索，我们将研究一些新技术。理想的情况是使用一些简单的自动化来让DBA放松，节省时间学习新技术，解决工作中的其他问题。 问答环节

【问题1】在Redis架构中，是在机房放置一个守卫，还是有一组守卫？

答：如果您的公司目前只有一间机房，那么Sentry只能放在同一个机房​​。但如果你的公司有几个机房，比如去哪儿、陌陌，你可以在不同的机房设置警卫，每个机房配备一名警卫。例如，如果您要监控该实例，并且有五个机房，则安装五个哨兵组，一个哨兵组有五个节点。

【后续】如果哨兵安装在多个机房，哨兵出现脑裂怎么办？

答案：所以我们需要通过使用base来避免这个问题。

【问题2】如果元数据放在ZooKeeper中，ZooKeeper是否应该和Redis放在同一个机房​​？

答：建议将ZooKeeper集群中的几个节点放置在不同的机房，因为可能很多机房都会出现问题，这是不可避免的，但我们目前为止还没有使用过这种方法。问题，它可能比常规网络监控更敏感。 ？这不是很正常吗？

答：每个业务的监控值设置为不同的数字。

【跟进】这样计划就太麻烦了，而且生意有变化价格也不会浮动。你这边有好的解决办法吗？

答：首先我们可以通过管理平台看到每个实例，所以我们可以为每个实例设置监控值，包括QPS。我们可以设置20000报警和30000报警。如果此时的业务访问量比较大，比如6万，那么可以设置7万的报警。这可以实现非常细的粒度并针对每个样本。创建一个设置。因此，当我们构建它时，我们会知道“您的业务 QPS 大约是多少”。比如我的QPS是6万。您可以构建四个节点。有可能商家最初提供的报警数量是6万个。超过之后我们就可以报警了，然后我们就可以初始化并设置报警阈值。

【跟进】下到实例级别是什么意思？

答案：是的，具体到每个例子。每个样本的监测值都不同。

【问题4】老师们可以在PPT中多讲讲远程备灾吗？

答案：我们可以搭建一个核心集群，在远程机房再搭建一个从数据库。

【跟进】本地机房宕机时需要通知我吗？

答：这个时候可能就不需要哨点监控了。如果整个机房都宕机了，就需要人工了。因为此时异地容灾意味着整个机房不工作了，需要我人工干预。