我来曝光一个很多人都不知道的学习网站。

这期我想给大家分享一个很多人都不知道的学习网站。

就是阿里云。

我估计有很多人看到“阿里云”这几个字出来的时候，就浮现出不好的感觉，心中暗喊：不好，感觉这是一个广告。赶紧跑。

但是，你放心，这真不是广告。

确实，从本质上来讲，这是一个卖服务的网站。但是壮士请留步啊，我又不叫你去这上面买服务，我真的在这上面学到了很多有用的知识。

放心，学这些知识不要钱的。

当然了，阿里云要是能看到我的文章，想要给我打一笔钱我也是很乐意的。

好了，话不多说，发车。

帮助中心

如果你觉得阿里云是一个卖服务的网站，是一个让你花钱的地方，说明你的打开方式是官方期望的打开方式。

但是如果你用我的打开方式，它就会摇身一变，变成一个免费的学习网站。

我的打开方式，就是从它的“帮助中心”进去：

https://help.aliyun.com/

然后，关注它右边导航栏的这一溜栏目。

比如，数据库这里，我随便圈几个：

再比如，中间件这里，我也圈几个：

当然，还有很多其他的可以看的东西，我就不一一展示了，大家感兴趣自己去翻就行了。

在帮助中心里面展示的东西，就是阿里云能卖的服务。

而他们要卖服务，一定要有对应的文档说明。

就是“吹牛逼”嘛，说我的服务多么多么好，多么多么稳定，多么多少省心，有那些应用场景，巴拉巴拉巴拉...

所以去翻阅对应技术点他们提供的文档，就是正确的打开方式。

下面我用 Redis 来举个例子。

阿里云 Redis 文档

我觉得阿里云里面 Redis 的技术文档是做的最好的，所以带你看看。

https://help.aliyun.com/product/26340.html

这个学习路径里面，就有很多值得我们关注的地方。

比如我们先看这个几个地方的内容：

应用场景

第一个Redis 有哪些应用场景？

这个问题是不是面试的时候面试官也经常问你：Redis 在你的应用里面是干啥用的？

你怎么回答？

保守一点的说，95% 的人都会说：拿来当做缓存用。

确实，基本上都是拿来当个缓存用用而已。但是你是不是可以补充一句：除了可以当缓存用，我还知道它有其他的一下应用场景，比如：

https://help.aliyun.com/document_detail/43829.html

咔咔咔，就直接把文档上举的例子再罗列一下，有行业，有场景，这样的回答肯定比你干瘪瘪的回答一个“缓存”好吧。

灾备方案

然后我们看“灾备方案”这一部分：

https://help.aliyun.com/document_detail/100734.html

也许你听过“灾备”这个概念，但是大多是运维人员关系的，我们作为开发其实了解的不多。

但是如果你会，那就是加分项。

阿里云介绍了三种灾备方案。

• 单可用区高可用方案，灾备级别最低，主备节点部署在同一可用区中的不同机器上，当任一节点发生故障时，由高可用HA（High Availability）系统自动执行故障切换，避免单点故障引起的服务中断。
• 同城容灾方案，灾备级别中等，主备节点分别部署在同一地域下两个不同的可用区，当任一可用区因电力、网络等不可抗因素失去通信时，高可用HA系统将执行故障切换，确保整个实例的持续可用。
• 跨地域容灾方案，灾备级别最高，由多个子实例构成全球分布式实例，所有子实例通过同步通道保持实时数据同步，由通道管理器负责子实例的健康状态监测、主备切换等等异常事件的处理，适用于异地灾备、异地多活、应用就近访问、分摊负载等场景。

而单单一个灾备级别最低的“单可用区高可用方案”也有多种不同的部署架构：

比如下面这个标准版-双副本高可用架构：

它采用了双机主从（Master-Replica）架构，高可用 HA 模块侦测到主节点故障时，会自动进行主从切换，将 Replica 提升为 Master，而原来的 Master 恢复连接后会成为新的 Replica。

这就是一个要实现高可用的最基本最简单的架构图。

但是这个架构的问题在于只有一个集群，要是这整个集群都挂了怎么办呢？

没办法，只有演进架构。

所以，还有集群版的双副本高可用架构：

集群架构（双副本）实例中的数据分片用于承载数据，每个数据分片均为双副本（分别部署在不同机器上）高可用架构，主节点发生故障后，系统会自动进行主备切换保证服务高可用。

然后还有经常提到的读写分离架构：

另外的同城容灾方案、跨地域容灾方案我就不一一介绍了，大家自己去翻一下就行。

命令支持

在命令支持这块，我也有新的发现：

有一些企业版才支持的命令，也就是说这是阿里对于 Redis 进行了二次开发，对某些命令进行了加强。

比如这两个命令：

它们是干啥的呢？

来，我问你一个问题：用 Redis 做分布式锁的时候，解锁用的命令是什么？

是 DEL 命令，是的，回答的很好。

那么解锁的时候需要注意什么呢？

是不是需要检查解锁的线程和加锁的线程得是同一个。

你要是不明白为什么也没关系，官网上举个了这么一个例子：

• t1时刻，App1设置了分布式锁resource_1，过期时间为3秒。
• App1由于程序慢等原因等待超过了3秒，而resource_1已经在t2时刻被释放。
• t3时刻，App2获得这个分布式锁。
• App1从等待中恢复，在t4时刻运行DEL resource_1将App2持有的分布式锁释放了。

哦豁，不是自己加的锁，却把锁给释放了？

所以，从上述过程可以看出，一个客户端设置的锁，必须由自己解开。

因此客户端需要先使用 GET 命令确认锁是不是自己设置的，然后再使用 DEL 解锁。

先获取、再判断、接着删除，很明显，这不是一个原子性的操作，怎么办？

是的，lua 脚本。

在 Redis 中通常需要用 lua 脚本来实现自锁自解的功能，比如这样：

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

是不是感觉有点麻烦呀？

所以，阿里自己搞了一个 CAD 命令。

加锁逻辑还是一样：

SET resource_1 random_value NX EX 5

解锁就变成了这样：

/* if (GET(resource_1) == my_random_value) DEL(resource_1) */
CAD resource_1 my_random_value

是不是简洁了很多？

而它的底层我没去看，但是猜也知道，就是对 lua 脚本的一个封装。

CAS 命令是拿来续租的，可以自己去看看。

https://help.aliyun.com/document_detail/146758.html

同时文中还提到了如何保障一致性的问题：

如果你理解不了“如果丢失的数据跟分布式锁有关，则会导致锁的机制出现问题，从而引起业务异常”这句话，也就理解不了后面说的“红锁”的解决方案。

那么这里是不是又是一个引子，让你找到在这个体系里面新的要学习的东西？

而关于这个点，其实我之前也写文章解释过《【求锤得锤的故事】Redis锁从面试连环炮聊到神仙打架。》，你要不清楚，也可以去看看。

除此之外，你可以看到它左边的导航栏里面举了好几个例子：

这些都是自研的，但是其实一部分命令其实都是开源的，包括前面提到的 CAD 和 CAS 命令：

https://github.com/alibaba/TairString/blob/main/README-CN.md

是不是又找到一个可以学习的方向？

比如有个 TairZset 命令。

我们知道，Redis 原生的 zset 主要可以用来做排行榜，但是只支持单维度的排序。

阿里搞了个 TairZset 命令，扩展了一下，就支持多维度了：

这个命令也是开源的。

性能排查与调优

https://help.aliyun.com/document_detail/265988.html

这一部分的内容，简直就是绝了。

光看标题就知道是干货了。

比如我举其中的一个例子来说：

请问，Redis 的 CPU 使用率高了，你有哪些解决方案或者说是排查思路？

不知道没有关系，这里写了三种。

第一种是查找并禁用高消耗命令。

高消耗命令：即时间复杂度为O(N)或更高的命令。通常情况下，命令的时间复杂度越高，在执行时会消耗较多的资源，从而导致CPU使用率上升。

由于 Redis 的特性，在执行高消耗命令时会引发排队导致应用响应变慢。

极端情况下，甚至可能导致实例被整体阻塞，引发应用超时中断或流量跳过缓存层直接到达后端的数据库侧，引发雪崩效应。

那么我们怎么找到高消耗的命令呢？

这个就是它们产品提供的一个功能了：

这里面连数据都给你截上了，基本上看的是一清二楚。

那如果我们不用它的可视化页面，用原生的功能，怎么做呢？

slowlog-log-slower-than 和 slowlog-max-len 这个两个参数配置了解一下，前者是设置慢查询的阈值，后者是存放慢查询的记录。

而且，就算你面试的时候说，我们是通过可视化页面找到的高消耗命令，我也觉得没啥问题，毕竟主要是看你有那些思路。

有思路了，找到对应的解决方案还不是手到擒来的事情。

除此之外，还有这几个方案：

如果经过这些操作之后， CPU 的使用率还是很高怎么办？

在评估业务正常的情况下，加钱，加机器，升级配置。

最佳实践

https://help.aliyun.com/document_detail/163162.html

一定一定一定要去看每个技术点对应的最佳实践这一部分。

比如在游戏玩家积分排行榜的这个实践中，还给你提供了一套环境以及直接可以运行的代码：

你只管按照步骤操作就行了。

又比如在JedisPool资源池优化的这里面。

针对 Redis 的配置给出了说明和建议值。合理的配置能够提升 Redis 的服务性能，降低资源开销。

这些都是很重要的关于参数的配置。

也许你自己配置的时候，从其他项目中随便就拷贝一个过来了，项目也跑的好好的，你甚至不知道每个参数是干啥的。

但是在这里，你能找到答案。

还有包括秒杀和双十一，这些看起来很厉害的东西，这里都有：

其他

比如在 RabbitMQ 里面，有关于消息幂等的最佳实践：

也有关于消息重试、延时队列等的高级特性的描述：

比如在数字金融里面有个这东西：

是一套在金融领域可复用的技术解决方案，而相关的技术栈的绝大部分都是开源的。

如果你之前不了解 SOFAStack 这个玩意，那么这个地方就是你了解它的入口。

上次有个读者问我关于 RocketMQ 的事务消息的问题，我虽然没有用过，但是我给他发过去一个连接：

https://help.aliyun.com/document_detail/43348.html

这里面，就有他想要找的东西：

当时他问我：怎么随便一搜就能搜到一篇高质量的文章？

我说恰好之前看过而已。其实，我之前没有看过。

但是我知道阿里云上面肯定有卖 RocketMQ 服务的，那么它这里面大概率有这方面的资料。

所以我就上去那么随便一翻，就找到了。

这也是我想要把这个“学习网站”分享给你的原因，以后多一个找资料的地方，多一个学习新东西的地方，挺好的。

好了，那本文的技术部分就到这里啦。

下面这个环节叫做[荒腔走板]，技术文章后面我偶尔会记录、分享点生活相关的事情，和技术毫无关系。我知道看起来很突兀，但是我喜欢，因为这是一个普通博主的生活气息。

你要不喜欢，退出之前记得文末点个“在看”哦。

荒腔走板

这周搞了一下家里的“工位”，整体来说就是搞得花里浮哨的。

之前桌面上的支架是我自己放的一块装修的时候的边角料，也就是一块长方形的中空玻璃，只是这玩意实在是太重了，而且脏了一点都能看的特别清楚，搞的我每天都要擦一次桌面。

于是我在网上买了一个木头的，看起来质量还不错，就是味儿大，我在阳台放了一周多，才把味道散去。

最后把家里各种各样的小玩偶全部都堆到这里来，发现我还是薅了各大平台很多手办羊毛的。

希望以后再接再厉，目标就是堆满。

家里整体风格是简约风，但是工作区域我就像弄的复杂一点，满满当当的，这样会比较有干劲儿。

哦，对了，这周还抽空去了一趟动物园，发了一期荒腔走板，可以看看，是个耍朋友的好地方：《歪歪带你耍成都。这个地方巴适哦！》

虽然阅读量非常低，但是希望以后能做成一个系列，就叫做“歪游记“，对标周董的“周游记”哈哈。

最后说一句(求关注)

好了，看到了这里了， 转发、在看、点赞 随便安排一个吧，要是你都安排上我也不介意。写文章很累的，需要一点正反馈。

给各位读者朋友们磕一个了：