又拍云 Redis 的改进之路

又拍云 UPYUN

已于 2022-06-29 10:23:09 修改

阅读量812

点赞数 1

分类专栏：前端架构文章标签：前端架构

于 2022-06-29 10:22:53 首次发布

本文链接：https://blog.csdn.net/github_36774378/article/details/125515494

版权

文章讲述了又拍云在Redis技术选型中遇到的问题及解决策略，包括使用Redis2.8作为数据同步解决方案带来的技术债，以及后续的改进措施，如升级到Redis6.2以实现多线程IO、支持SSL和PSYNC2，通过stunnel加强安全防护，使用APISIX进行负载均衡，以及利用Redis-shake进行数据同步。

摘要由CSDN通过智能技术生成

作为推出国内首创可编程 CDN 服务的专业云服务提供商，又拍云利用 CDN 边缘网络规模和性能，允许客户自定义编写规则来满足常用业务场景。而为了保证这些源数据，如边缘重定向、请求限速、自定义错误页面、访问防盗链控制、 HTTP 头部管理等，能快速同步到边缘的节点服务器，在对比了多个方案以后，又拍云于 2014 年初开始使用 Redis2.8 版本作为数据同步的解决方案。

最初的架构如下：

在继续谈 Redis 改进前，我们要先了解一下技术债。这里说的技术债指的是技术负债，通常开发人员为了加速软件开发，在应该采用最佳方案时可能进行妥协，改用短期内能加速软件开发的方案。而这种方案在未来给自己带去了额外开发负担。这种虽然眼前看起来可以得到好处，但必须在未来偿还的选择，就像债务一样，所以被叫做技术债。

而我们上面说到的这个方案就埋下了技术债的引子。在过去的几年里它虽然起到重要的作用，但架构的缺点明显，而且随着边缘服务器数量和同步数据量的增加，再加上服务器硬件的老化故障等等原因，造成了很多问题，比如如下问题：

出于安全考虑，相互 Redis 之间的通信数据都需要加密，但 Redis 本身不支持 SSL 加密。因此所有的边缘服务器都必须通过 stunnel 套接做中转服务器。然而实际工作状态下，stunnel 的性能不足，导致服务器 CPU 负载过高。
Redis 的数据主从都是长连接且尽量保持从同一源做同步，因此早期边缘服务器都是通过域名解析的方式来获取源服务器的 IP 地址。这样的好处是实施部署简单，缺点是 DNS 无法获知后端服务器的处理能力，造成每台机器上的长连接负载不均衡。而且后端服务出故障后 DNS 也无法自动处理，即便及时对 DNS 进行了切换解析，也会因为 TTL 生效前的真空期引起数据不一样，导致只能使用旧数据应急。
因为历史遗留原因，边缘 Redis 版本大都是 2.x 低版本，而低版本只能通过 sync 做全量同步。因此中转服务器和主服务器的异常都会造成全网的雪崩效应，从而同步阻塞，无法快速同步元数据到边缘。
因为早期 Redis 只有主从模式可以采用，也没有实现哨兵和集群改造。所以让如今主服务器成为了单点风险，很容易造成源头上的重大故障。

因为之前妥协导致的问题和副作用ÿ