又拍云 Redis 的改进之路-低调大师

又拍云 Redis 的改进之路

2022-06-29 405

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

最初的架构如下：

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

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

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

因为之前妥协导致的问题和副作用，以至于我们现在必须要付出额外的时间和精力进行重构，把架构改善为最佳实现方式。

我们把改造过程分成几个步骤：

加强 SSL 的安全防护，尽可能升级到 OpenSSL 最新的稳定版本

SSL 可能是大家接触比较多的互联网安全协议之一，一般网站地址用了“https://”开头，就是采用了 SSL 安全协议。OpenSSL 是一种开放源码的 SSL 实现，用来实现网络通信的高强度加密，现在被广泛地用于各种网络应用程序中。如此重要的项目多年来始终面临着资金和人手不足的窘境，多数工作都要由为数不多的黑客和爱好者及志愿者来完成。幸好现在纳入 Linux 基金会资金资助对象，不过依然有新漏洞不断暴露，需要及时关注和跟进。

参考最新的 OpenSSL 漏洞危险等级报告：

鉴于 RC4 算法安全漏洞太多，建议编译时选择禁用。

使用最新的 stunnel 版本，优化性能，基于安全 OpenSSL 依赖库，支持 TLSv1.2+ 以上

从下图的红色框中可以看出，stunnel 在某些算法下的性能是最强的，所以在配置文件中推荐优先使用：

./configure --prefix=/opt/stunnel --with-ssl=/opt/openssl

来看一下推荐配置中的优化选项：

verify = 3
sslVersionMax = TLSv1.3
sslVersionMin = TLSv1.2
options = NO_SSLv2
options = NO_SSLv3
.......
ciphers = ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4:!DH:!DHE

可以通过亚洲诚信的网站来做 HTTPS 的可信等级检测和验证。

编译最新的 Redis-6.2.x 稳定版，功能强大丰富且无需依赖高版本的 GCC

Redis6.2 与 7.0 对比来看的话，肯定是 7.0 版本更为强大一点。Redis7.0 几乎包括了对各个方面的增量改进，其中最值得注意的是 Redis Functions、ACLv2、command introspection 和 Sharded Pub/Sub。7.0 版添加了近 50 个新命令和选项来支持这种演变并扩展 Redis 的现有功能。

但是尽管 Redis7.0 更加强大，可是综合考虑到与原来的 Redis 代码的完全兼容性，以及生产环境的稳定，我们最终选择了 Redis6.2。因为 Redis6.2 的优点也足够多，功能也很强大，而且更能满足我们生产环境的要求，比如：

多线程 IO（Threaded I/O）
众多新模块（modules）API
更好的过期循环（expire cycle）
支持 SSL
ACLs 权限控制
RESP3 协议
客户端缓存（Client side caching）
无盘复制&PSYNC2
Redis-benchmark 支持集群
Redis-cli 优化、重写 Systemd 支持
Redis 集群代理与 Redis6 一同发布（但在不同的 repo）
RDB 更快加载
SRANDMEMBER 和类似的命令具有更好的分布
STRALGO 命令
带有超时的 Redis 命令更易用

重点介绍一下 PSYNC2 的特性，这也是我们架构改进升级的重点特性之一。

在 Redis cluster 的实际生产运营中，实例的维护性重启、主实例的故障切换（如cluster failover）操作都是比较常见的(如实例升级、rename command 和释放实例内存碎片等）。而在 Redis4.0 版本前，这类维护性的处理 Redis 都会发生全量重新同步，导到性能敏感的服务有少量受损。而 PSYNC2 主要让 Redis 在从实例重启和主实例故障切换场景下，也能使用部分重新同步。

直接下载源代码编译：

# make BUILD_TLS=no

推荐配置，添加以下选项增强性能：

io-threads-do-reads yes
io-threads 8
aof-use-rdb-preamble yes

在我们的测试过程中，发现 Redis+TLS 有几个问题：

Redis 开启 TLS后，性能下降 30%。
Redis 对 OpenSSL 的强依赖性. 考虑到 OpenSSL 的过往高危漏洞不断，如果要不断修复漏洞要重新编译 Redis，导致运维更新成本过高。
Redis 升级后，要重新同步数据，增加了出故障的机率或让生产停摆。

所以，我们还是决定使用第三方程序 stunnel 来加固安全，方便升级和修复漏洞。又不影响后端连接，从而保障了 Redis 的工作连续性和稳定可靠性。

基于 APISIX+TLS 托管，使用 TCP 的哈希一致性做负载均衡来替换 DNS 的轮询，效能显著

APISIX 使用 TCP 代理，这部分直接配置后就可以使用，和 Redis 改造关系不大，我们就直接略过，大家可以直接看一下改造后的连接数统计截图。从实际的 APISIX 的连接数可以看出负载被数量均衡地分摊到了不同的后端，而且边缘服务器重启也利用 PSYNC2 做了快速的增量同步。

使用 Redis-shake 做定制化的数据同步

在架构改进的过程中，我们也看了 redis-shake 这个工具，它是阿里云 Redis&MongoDB 团队开源的用于 Redis数据同步的工具。它支持 解析、恢复、备份、同步 四个功能。给大家主要介绍同步 sync：

恢复 restore：将 RDB 文件恢复到目的 Redis 数据库。

备份 dump：将源 Redis 的全量数据通过 RDB 文件备份起来。

解析 decode：对 RDB 文件进行读取，并以 json 格式解析存储。

同步 sync：支持源 Redis 和目的 Redis 的数据同步，支持全量和增量数据的迁移。

同步 rump：支持源 Redis 和目的 Redis 的数据同步，仅支持全量的迁移。采用 scan 和 restore 命令进行迁移，支持不同云厂商不同 Redis 版本的迁移。

我们原来有一个做过源代码修改过的 Redis，只会同步想要的空间。虽然好用，但还是需要在新代码上重新编译一个，可是原来的负责人已经找不到了。这也是很多年久失修项目的通病，但通过 redis-shake 这样的开源工具，只要通过它简单配置一下就可以实现我们想要的功能：

  - filter.db.whitelist / blacklist
  - filter.key.whitelist / blacklist
  - filter.command.whitelist / blacklist

现在的架构及未来的展望

在现在的架构中，我们在原来的三层架构基础上，又拆分和强化了三层架构：

DNS 层解析到 VIP，VIP 利用了 BGP/OSPF 的动态网关路由协议，对应后面一组服务器集群服务。
负载均衡层：利用 “apisix ”+ “tls1.2+ ”+ “tcp的哈希一致性连接”，把 Redis 的主从连接均衡，故障转移。
边缘 CDN 节点，利用 Redis 高版本所带来的技术红利，psync 的增量同步，加上 stunnel+tls1.2 实现了加密传输。

下一个阶段，还要继续把数据中心的 Redis 主改造成 Redis 哨兵模式（考虑到程序代码要对哨兵模式做兼容性改造，第一阶段先不上，一切都为了生产环境中的稳定性）。

参考文档：

如何检查网站的 TLS 版本：https://wentao.org/post/2020-11-29-ssl-version-check/

Redis 特性之复制增强版 PSYNC2：https://www.modb.pro/db/79478

通俗易懂的 Redis 架构模式详解：https://www.cnblogs.com/mrhelloworld/p/redis-architecture.html

SOFARegistry 源码｜数据同步模块解析

文｜宋国磊（GitHub ID：glmapper ) SOFAStack Committer、华米科技高级研发工程师负责华米账号系统、框架治理方向的开发本文 3024 字阅读10 分钟｜前言｜本文主要围绕 SOFARegistry 的数据同步模块进行了源码的解析。其中，对于注册中心的概念以及 SOFARegistry 的基础架构将不再做详细的阐述，有兴趣的小伙伴在《海量数据下的注册中心 - SOFARegistry 架构介绍》[1]一文中获取相关介绍。本文主要的思路大致分为以下 2 个部分： - 第一部分，借助 SOFARegistry 中的角色分类来说明哪些角色之间会进行数据同步； - 第二部分，对数据同步的具体实现进行解析。 PART. 1——SOFARegistry 的角色分类如上图所示，SOFARegistry 包含以下 4 个角色： Client 提供应用接入服务注册中心的基本 API 能力，应用系统通过依赖客户端 JAR 包，通过编程方式调用服务注册中心的服务订阅和服务发布能力。 SessionServer 会话服务器，负责接受 Client 的服务发布和服务...

2022-06-29

405

上一篇，介绍了测试活动测试输入、测试执行、测试分析、测试定位和测试评估五个步骤中测试输入智能化研究和实践，包含异常单测生成、接口用例生成、动作集生成等研究与实践。本章节重点介绍测试执行环节的智能化实践。测试执行是指将测试生成的用例集、数据集利用手动和自动化的方式对这些集合运行，测试执行本质上不能提升揭错水平，但如何高效稳定的执行完测试集合也是影响测试效果的关键。测试执行智能化通过将数据、算法、工程等相关技术有机结合，一般包含测试用例推荐、测试流量筛选、测试任务调度、智能构建、执行自愈等方面，在学术界和工业界均有非常优秀的研究和实践。方法论上一般包含基于覆盖率相关性选择算法、基于数据建模或两者结合的方式。本章节将从多个实践的角度，介绍相关领域的目标、思路、涉及到的技术点、效果，希望能给到大家一定参考。 01 基于风险的手工用例推荐测试执行，因为代码变化、环境等因素，往往不需要执行全部的用例，如何在用例全集中找到最有可能揭错的用例，是本方向的研究领域，也是业绩研究最多的领域。手工测试用例推荐主要指通过代码变更推荐出关联手工用例，一个关键目标是希望能精选覆盖度高的用例组合，尽早发现问题...

2022-06-29

496

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。