共计 3962 个字符，预计需要花费 10 分钟才能阅读完成。
作为推出国内首创可编程 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-…
Redis 个性之复制增强版 PSYNC2：https://www.modb.pro/db/79478
通俗易懂的 Redis 架构模式详解：https://www.cnblogs.com/mrhel…
举荐浏览
【实操干货】做好这 16 项优化，你的 Linux 操作系统面目一新
Golang 常见设计模式之单例模式