得物自建 Redis 无人值守资源均衡调理计划与实现

1. 目录：
2. 一、为什么要做资源均衡调度
3. 二、为什么要做自动化资源均衡调度
4. 三、如何合理选择迁移节点
5. 四、如何保障迁移过程中可靠性
6.     1. 添加从节点
7.     2. 检查同步数据正常
8.     3. 执行主从切换
9.     4. 检查主从切换正常
10.     5. 删除待迁移节点
11.     6. 消息通知
12. 五、迁移任务管理展示
13. 六、总结

复制代码

文 / Miro-得物技能

一、为什么要做资源均衡调理
得物 Redis 管理平台目前管理着几百个集群、数万个 Redis-server 节点、几千台 server 宿主机，而且通过精致化运维管理，目前 Redis-server 宿主机均匀内存使用率和内存分配率均到达一个合理且较高的水位，资源管理处于业内第一梯队，使用最低的成本做到最大的支撑业务缓存需求。
同时，随着业务使用量的持续增长，单台宿主机上的内存使用率越来越高，为了保证宿主机上全部节点的业务日常增长需求或者突发的业务内存上涨，以便可以或许做到秒级快速垂直扩容，以及添加节点、RDB 离线分析等功能必要的资源，单台宿主机的内存使用率都必要动态的控制在一个合理水位线以下，于是，Redis 管理平台会每天定期自动巡检全部宿主机内存使用率，对于超过合理阈值的宿主机，会选择一部分 server节点举行打散，迁移到其他宿主机上。

二、为什么要做自动化资源均衡调理
在 Redis 系统承接业务后，资源使用量快速增长的初期，逐步出现必要举行资源均衡调理的需求，一开始也是 DBA 手动举行节点迁移。为此还特意开辟了一个批量选择节点举行添加从节点、主从切换、节点下线等批量操作功能。
然而纵然提供了批量操作功能，手动迁移依然必要 DBA 每天投入相当多的精神来举行资源均衡调理，并且存在稳定性风险。

• 首先，必要 DBA 每天都要关注资源整体的使用情况，一旦出现内存使用率较高的呆板，就必要举行打散迁移；
  
• 随着呆板增多、Redis 服务承接的业务快速增长，每天必要打散的呆板越来越多，每次必要打散的节点也越来越多，操作迁移花费的时间也越来越多，到后期差不多每周必要投入 2 人天的工时专门举行资源打散；
  
• 另外，由于人工操作，选择大量节点同时举行，难免出现漏操作、重复操作、误操作等情况，增长了资源迁移给集群稳定性带来的风险。
  

于是，Redis 管理平台计划并开辟了无人值守资源均衡调理功能，为了尽量降低迁移过程对业务的影响，默认选择在破晓5点业务低峰期举行执行，并且自动巡检、选择呆板、选择节点、节点迁移等整个资源均衡调理过程均是每天定点自动完成。
迁移过程中怎么合理的选择一部分节点还是无脑随机选择几个节点，怎么保证迁移的稳定性是核心能力？

三、怎样合理选择迁移节点
迁移过程的第一步是必要挑选内存使用率超过预设阈值的宿主机呆板，并且挑选呆板上部分节点举行迁移，使得这些节点迁移后，该宿主机内存使用率降落到合理水位线以下。
那么选择节点是不是无脑随机挑选一部分节点呢，理论上来说当然也没有什么问题，但是为了保证迁移过程对业务影响最小、且使得迁移后，全部集群节点分布更匀称，我们还是计划了一系列最优选择规则，选择最优节点原则包含：

• 优先节点数目多的实例节点，这样可以在资源均衡的同时，可以使得同一集群节点也更均衡，同一集群节点尽可能的分散到不同的呆板上。
  
• 优先实例等级为非 P0 的实例。
  
• 优先从节点：从节点迁移对大部分业务（同城双活业务除外）都没有任何影响。
  
• 优先节点规格中等规格（1-4G）实例、再选择 1G-5G 规格实例、最后选择其他规格的节点；假如选择的节点太小，为了满足条件必要迁移更多的节点，假如选择的节点规格太大，迁移时加载数据时间更长，另外假犹如时刚好对应节点的写流量比较大，加载数据时从节点连接池缓冲区写满会导致同步过程失败，也就是大规格节点迁移过程失败的概率更大。
  
• 不同时选择同一个集群同一个分组的节点。
  

选择节点算法流程图如下：

• 节点列表排序，对呆板上全部 server 节点按照所属同一集群的数目和内存巨细排序，从同一集群节点数目多的集群开始选择满足条件的符合节点；
  
• 前两轮选择中，均选择非 P0 集群节点，第一轮选择节点规格为 1-4G 的节点、第二轮选择节点规格为 1-5G 的节点；
  
• 第三轮选择则包含全部集群（即也包含 P0 集群）、节点规格为 1-4G 的节点；
  
• 最后假如还不满足必要迁移的节点内存，则按照遍历顺序直接选择恣意节点；
  
• 每轮选择过程中，均制止同一集群同一个分组的节点同时选中。
  

节点选择完成后，按集群 ID 天生迁移任务，迁移任务默认每天破晓 5 点定时执行，天生的迁移任务会同步发送给各业务域对应 DBA 确认，确认过程中可选择取消或者修改执行时间。

四、怎样保障迁移过程中可靠性
等候执行的迁移任务到达设置的定时执行时间后，开始执行自动迁移流程，整个迁移过程包含添加从节点、主从切换、删除迁移节点等步调。
迁移任务执行过程流程图如下所示：

迁移过程中，为了节点迁移不出现异常，每一步执行都举行多维度严酷的校验，确保正常才举行下一步操作，下面详细介绍迁移过程中每一步操作是怎样举行校验保障可靠性的。
添加从节点
到达某个节点的迁移任务执行时间时，第一步是先添加一个从节点来替换准备迁移的原有节点。

一个缓存实例或节点的部署非常复杂，涉及呆板选择、端口分配、配置文件准备、节点安装与启动、槽位分配、主从关系设置、SLB 分配与绑定、以及相关组件的部署等一系列动作，目前 Redis 集群部署、以及单个节点部署都是自动化部署完成。

为了保证迁移过程中节点的高可用，迁移节点自动化部署过程中包含一些必要的部署规则：

• 新分配节点保持与待迁移的原节点在同一个可用区
  
• 新分配节点不能分配到待迁移的原有节点同一台宿主机上
  
• 新分配节点分配的宿主机保持在原节点所在同一资源分组
  
• 新分配节点的规格、版本与待迁移的原节点保持同等
  
• 制止同一个集群实例的多个 Redis-Server、Redis-Proxy 节点部署在相同的宿主机上
  
• 每个宿主机最多分配总内存容量的 90%，预留一定的数据增长空间
  
• 根据宿主机可用内存，优先推荐剩余可用内存多的呆板
  
• 
  

检查同步数据正常
完成添加从节点动作后，必要检查新节点是否分配正常、以及新节点同步数据是否正常，只有新节点同步数据正常才气可靠的执行主从切换或者删除原节点。
在 Redis 中，可以通过 info replication 命令查看主从节点同步状态，在自动迁移过程中，会分别从主节点和从节点的视角多维度综合判定当前主从同步是否正常。
一个状态正常的主从同步，从主节点视角通过 info replication 命令查看显示如下所示：

从主节点视角，自动迁移过程中，会判定连上主节点的从节点中是否包含了新增的从节点、并且新增从节点的同步状态 state=online 且 offset != 0
一个状态正常的主从同步，在从节点视角通过 info replication 命令查看显示如下所示：

在新增的从节点视角，自动迁移过程中，会判定节点角色为 slave、且当前同步的主节点信息与节点所在分组的主节点信息（ip 和 port）同等、并且与主节点的同步状态 master_link_status:up 且 master_repl_offset != 0
而且，自动迁移过程中，第一次检查新增节点主从同步成功后，会间隔一分钟后，再次检查一遍，确保节点的同步正常。
执行主从切换
假如待迁移的原节点角色是从节点，新增从节点成功后，直接进入删除待迁移节点流程即可。但是，假如待迁移的原节点角色是主节点，则必要先对新增的节点执行主从切换，将新增的从节点选举为新主节点后，才气删除待迁移原节点。
获取新增从节点，发起主从切换选举操作，也即对从节点执行 slaveof no one 命令，将从节点选举为新主节点，对分组中原主节点和原其他从节点执行 slaveof 命令，设置为新主节点的从节点，同步新主节点。
检查主从切换正常
检查主从切换是否正常，与前面介绍的检查同步数据是否正常逻辑基本一样。分别从新主节点和全部从节点的视角，通过 info replication 命令查看主从节点同步状态。
从主节点视角，查看新主节点角色是否为 master，包含的从节点数目是否不为 0，全部从节点的同步状态是否state=online 且 offset != 0
逐个检查每个从节点，通过从节点视角，判定节点角色为 slave、且当前同步的主节点与新主节点信息（ip 和 port）同等、并且与主节点的同步状态 master_link_status:up 且 master_repl_offset != 0
只有通过主从节点视角分别确认都正常，才以为整个迁移过程是正常的。
删除待迁移节点
待主从切换完成（或者待迁移节点原来就是一个从节点）且同步状态检查正常后，进入删除节点流程，下线待迁移节点。
下线节点前，仍然会二次确认做一些必要的检查，包罗分组的主节点是否正常、从节点同步是否正常等。
调用节点下线逻辑对待迁移节点举行下线操作，下线节点操作本身也会有一些必要检查，比如假如有业务连接访问 Proxy 和节点有数据的情况下，不允许删除主节点。
消息关照
假如节点迁移由于宿主机不足导致新节点分配失败等原因失败后，会发送一个消息关照，方便DBA了解迁移结果情况。
五、迁移任务管理展示
等候迁移和迁移中的任务管理展示，等候迁移的任务可以取消、修改执行时间、或者立刻执行。

迁移任务可以查看天生的待迁移节点详情列表。

查看已完成的汗青任务

六、总结
目前，得物 Redis 管理平台管理着几千台 Redis-server 宿主机，通过每日智能自动化均衡资源迁移，宿主机内存资源均匀使用率和内存分配率均到达一个合理且较高的水位，全部宿主机内存使用率都动态控制在设置的阈值以下，保持宿主机内存资源处于一个高使用率程度的同时，给每台宿主机也预留有充足的内存余量，支持我们的业务突发的内存增长从而快速垂直扩容。
自动迁移过程中会优先选择同一集群在同一宿主机上节点数较多的节点，新节点分配挑选呆板过程中会尽量分散同一集群的节点，有些集群由于早期资源较小可能分配的呆板比较集中，随着自动迁移过程，也会逐步打散到尽可能多的不同呆板上，淘汰呆板故障时对单个集群的影响。
节点自动迁移功能也可以用于呆板下线中，提高呆板下线效率。呆板下线前也必要迁移上面全部节点，Redis 管理平台也提供了运维选中节点后，天生迁移任务功能。
Redis 管理平台一直在优化和美满系统的自动化运维程度，提高自动化运维程度，尽量淘汰运维工作的人力投入，除了本文中提到的自动化资源均衡调理外，已经支持或者在规划开辟中的自动化运维操作还包罗有自动部署集群、节点自动垂直扩容、宿主机宕机自动启动节点、宿主机宕机自动恢复节点主可用区等，敬请期待后续更详细的介绍。