一个很多人都不知道的学习网站。一个很多人都不知道的学习网

你好呀，我是歪歪。
这期我想给大家分享一个很多人都不知道的学习网站。
就是阿里云。

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

文章图片
确实，从本质上来讲，这是一个卖服务的网站。但是壮士请留步啊，我又不叫你去这上面买服务，我真的在这上面学到了很多有用的知识。
放心，学这些知识不要钱的。
当然了，阿里云要是能看到我的文章，想要给我打一笔钱我也是很乐意的。
好了，话不多说，发车。

文章图片
帮助中心如果你觉得阿里云是一个卖服务的网站，是一个让你花钱的地方，说明你的打开方式是官方期望的打开方式。
但是如果你用我的打开方式，它就会摇身一变，变成一个免费的学习网站。
我的打开方式，就是从它的“帮助中心”进去：

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 这个两个参数配置了解一下，前者是设置慢查询的阈值，后者是存放慢查询的记录。
而且，就算你面试的时候说，我们是通过可视化页面找到的高消耗命令，我也觉得没啥问题，毕竟主要是看你有那些思路。
有思路了，找到对应的解决方案还不是手到擒来的事情。
除此之外，还有这几个方案：