目录：
- cacheCloud redis运维系统业务架构讲解
- 运维涵盖的事项:
2.1 系统提供的能力支撑
2.2 系统维护，排查问题，系统优化，新功能规划，等
2.3 监控报警
2.4 故障应急处理 - 指标监控
3.1 指标分布
3.2 指标阈值
3.3 指标统计方式 - 故障处理全流程
- 高可用架构
5.1 集群、哨兵
5.2 同城双活;
5.3 两地三中心;
5.4 异地多活; - 安全
- 发展方向
7.1 上云部署
7.3 模块管理方向研究
1. cacheCloud redis运维系统业务架构讲解
cachecloud 是搜狐开源的redis 运维管理工具，非常优秀，功能全面。
总体业务架构如下：
其核心是构建 应用 模型，关联了 实例，机器，客户端等模型，提供了伸缩性、自动运维、监控统计等功能；如下图总结：
体验路径：
http://42.192.17.74:8088/manage/login
admin
admin
2. 运维涵盖的事项:
如下我们来讲解下我们所说的运维到底涵盖了哪些事项:
2.1 系统提供的能力支撑
2.2 系统维护，排查问题，系统优化，新功能规划
2.3 监控&监控指标
2.4 故障处理
2.1 系统提供的能力支撑
| 功能 | 具体子功能 |
|---|---|
| 应用管理 | 申请，审批，部署，客户端接入，日报，下线，统计; |
| 用户账号 | 账号申请，账号管理，权限管理 |
| 实例管理 | 实例运维，实例工具，实例监控，实例统计，实例迁移 |
| 客户端管理 | 客户端接入、客户端统计、客户端监控 |
| 系统功能 | 系统配置、工单审核等 |
2.2 系统维护
系统维护： 包含系统日常维护，问题排查，系统优化、新功能规划等;
2.3 监控&监控指标
- 监控指标梳理 --- 见后续第N姐详细讲解;
- 监控预警配置;
2.3 故障处理
故障处理 详见 4.故障处理 章节；
3.监控指标
从运维角度看，监控指标是我们从系统中提取的关键信息，可以帮助我们掌握系统的运行情况、发现系统问题、预判问题发生，给系统优化提供数据支撑，所以指标是非常重要的。
3.1 指标分布分类
3.2 指标阈值参考范围
3.3 指标统计方式
指标统计方式：
3.3.1 客户端通过 改写客户端工具埋点写入，可以上报客户端的异常，命中率，慢耗时请求统计等；
3.3.2 redis实例：通过redis 的命令 info ，monitor 等;
3.3.3 机器： 通过shell脚本定时执行上报;
4. 故障处理全流程
主要从故障时间入手分析，减少故障时间：
- 预防规避故障发生;
1.1 架构优化
1.2 故障复盘优化
1.3 日常巡检
1.4 研发规范培训
1.5 应用降级方案 - 减少故障发现时间；
2.1 监控覆盖全
2.2 监控阈值灵敏度调高 - 减少故障排查时间;
3.1 工具支撑
3.2 经验总结积累 -
减少故障恢复时间；
4.1 应急止血
4.2 预案执行
4.3 工具快恢
4.4 自动恢复
image.png
5. 高可用架构
高可用架构，保障服务最大的可用，一般采用冗余策略实现，如复制、备份等;
有一些灾备及专业术语可以参考：
容灾标准： Share 78 容灾国际标准
https://www.chinastor.com/baike/dr/12231U152015.html
根据业务要求，实现不同业务等级要求，选择不同的容灾等级方案。
冷备、热备、温备
https://blog.csdn.net/dl674756321/article/details/103655135
分布式系统架构设计：同城灾备、同城双活、两地三中心、异地多活等概念
https://blog.csdn.net/sinat_33718563/article/details/124703630
5.1 redis 高可用架构: 集群、哨兵
哨兵提供单机的高可用方案，在主节点down掉后，通过哨兵节点选举从节点，拉起从节点为主节点继续为业务提供服务。
集群通过hash槽分派到不同主节点，完成节点资源的水平扩展。同时有从节点，主节点down掉后，从节点被主节点集群选举代替主节点继续工作;
运维部署注意事项： 分布式高可用主要是抗 单节点故障，单机器故障，单机架故障， 所以在运行时，要把控好主节点，从节点之间的机房物理部署关系。 主节点和从节点尽量分散到不同主机，不通过机架上。主节点和主节点尽量部署在不同的主机和机架上。
5.2 同城灾备: 冷备、热备
同城灾备是在 同城架设新机房，将redis 数据 通过冷备（定时同步快照），热备（实施同步）方式同步到备份机房，并且备份机房需要具备且两后能代替主机房继续工作.
拓扑架构图：
5.3 同城双活：
同城双活，是在同城灾备的基础上，让备份机房的redis 也同时对外提供服务。这样做的好处：
- 资源利用率高: 备份机房也是资源，只是提供备份，浪费资源；
- 备机状态维护：一个长时间不用的备份机房，突然发生故障要启用，很难说不出问题，因为日常发布变更可能和主机房不一致，服务性能器性能配置等不一致，所以日常流量就是灾备最好的演练.
-
灾备切换时间快：如果入口有重试机制，可能最小维度降低主机房故障影响，流量自动走入备机房。
备机房的redis 可以读能力，如果写需要通过同城光纤到主机房去更新。
拓扑结构：
同城双活
5.4 两地三中心：
两地三中心是在同城双活的基础上，在其他城市增加C机房当备份机房，可能通过定时 冷备的方式，把redis 的数据备份出去，防止主城市发生不可抗力灾难。
拓扑结构：
5.5 异地多活：
异地多活是保障类全球多节点可同时并发提供服务，并且在redis 存储层可以有全量数据。
具体做法是，需要有一个中心机房，所有其他机房都想中心机房双向同步数据，这样所有机房都会有全量数据。
流量入口：流量需要通过用户id去在入口去拆分，比如华南的用户从华南机房进入运行。 这样避免数据层 数据更新冲突。
数据同步： 每个节点有全量数据，自己产生的实时数据以及 其他机房异步同步的数据 合集。
拓扑结构：
6. 安全
6.1 安全手段:
- 端口不暴露在公网
- 必须使用密码
- bind 绑定网卡
- 不用root权限
- 重命名掉危险命令： flushdb,flushall, shutdown ，sleep 等命令;
- 规范验证 dir + dbfile 路径及名称。
6.2 已知安全漏洞;
- redis 写入 ssh公钥登陆 ;
- redis 写入 定时任务反弹shell;
- redis 写入webshell 脚本;
- 主从复制rce ，加载定制模块;
- Redis Lua 沙盒绕过rce;
7. 发展方向
7.1 上云部署
如果我们维护资源有限，又不想自己从0搭建redis 集群及管理工具，可以选择 云服务产品，比如 阿里云、腾讯云等，都提供了完善的运维管理工具、高可用的设计架构、可供选择合适经济的套餐。
阿里云-云数据库Redis版与自建Redis的对比：https://help.aliyun.com/document_detail/134776.html
如果公司有实力也可自行发布开源产品，供内外部使用。
7.2 模块管理方向研究：
增对模块，是未来redis功能扩展的主要途径和优势，对redis 的功能扩展主要体现形式 为对模块的管理和扩展。 这样很容易就把redis 功能丰富，同时把不需要的功能不用加载。
模块管理目前的问题是存在一定的安全漏洞，未来如何给模块鉴权功能，是想研究的方向。
8总结
我们从cacheCloud redis 运维管理系统的介绍，引出其提供的redis运维具体功能、架构讲解，让我们在总体上对redis 运维有一个了解。随后用redis运维涵盖的事项，定义了我们redis运维的日常工作分类：包含系统日常维护，问题排查，系统优化、新功能规划等; 期中监控指标尤其重要，可以方便我们掌控集群运行情况，有问题能及时发现定位问题，指标的具体化分方法及指标的提取方式做了图示说明。 故障是在所难免的，我们要从 预防故障，减少故障发现时间，减少故障影响时间，减少故障恢复时间等角度入手，来展开稳定性相关的工作，这个划分是闭环合理的。 同时从redis 的高可用上分开介绍了： redis sentinel、redis cluster 的高可用，以及涉及容灾的 同城灾备、同城双活、两地三中心、异地多活的角度来看如何部署及使用redis。redis 的安全不容小视，要做好最基本的防护，同时关注漏洞发布及时补修。
如上是对redis运维的总结，感兴趣的小伙伴 点赞、关注、在看，谢谢支持。
