你好呀，我是歪歪。
这期我想给大家分享一个很多人都不知道的学习网站。
就是阿里云。
我估计有很多人看到“阿里云”这几个字出来的时候，就浮现出不好的感觉，心中暗喊：不好，感觉这是一个广告。赶紧跑。
确实，从本质上来讲，这是一个卖服务的网站。但是壮士请留步啊，我又不叫你去这上面买服务，我真的在这上面学到了很多有用的知识。
放心，学这些知识不要钱的。
当然了，阿里云要是能看到我的文章，想要给我打一笔钱我也是很乐意的。
好了，话不多说，发车。
帮助中心
如果你觉得阿里云是一个卖服务的网站，是一个让你花钱的地方，说明你的打开方式是官方期望的打开方式。
但是如果你用我的打开方式，它就会摇身一变，变成一个免费的学习网站。
我的打开方式，就是从它的“帮助中心”进去：
然后，关注它右边导航栏的这一溜栏目。
比如，数据库这里，我随便圈几个：
再比如，中间件这里，我也圈几个：
当然，还有很多其他的可以看的东西，我就不一一展示了，大家感兴趣自己去翻就行了。
在帮助中心里面展示的东西，就是阿里云能卖的服务。
而他们要卖服务，一定要有对应的文档说明。
就是“吹牛逼”嘛，说我的服务多么多么好，多么多么稳定，多么多少省心，有那些应用场景，巴拉巴拉巴拉...
所以去翻阅对应技术点他们提供的文档，就是正确的打开方式。
下面我用 Redis 来举个例子。
阿里云 Redis 文档
我觉得阿里云里面 Redis 的技术文档是做的最好的，所以带你看看。
这个学习路径里面，就有很多值得我们关注的地方。
比如我们先看这个几个地方的内容：
应用场景
第一个Redis 有哪些应用场景？
这个问题是不是面试的时候面试官也经常问你：Redis 在你的应用里面是干啥用的？
你怎么回答？
保守一点的说，95% 的人都会说：拿来当做缓存用。
确实，基本上都是拿来当个缓存用用而已。但是你是不是可以补充一句：除了可以当缓存用，我还知道它有其他的一下应用场景，比如：
咔咔咔，就直接把文档上举的例子再罗列一下，有行业，有场景，这样的回答肯定比你干瘪瘪的回答一个“缓存”好吧。
灾备方案
然后我们看“灾备方案”这一部分：
也许你听过“灾备”这个概念，但是大多是运维人员关系的，我们作为开发其实了解的不多。
但是如果你会，那就是加分项。
阿里云介绍了三种灾备方案。
- 单可用区高可用方案，灾备级别最低，主备节点部署在同一可用区中的不同机器上，当任一节点发生故障时，由高可用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 命令是拿来续租的，可以自己去看看。
同时文中还提到了如何保障一致性的问题：
如果你理解不了“如果丢失的数据跟分布式锁有关，则会导致锁的机制出现问题，从而引起业务异常”这句话，也就理解不了后面说的“红锁”的解决方案。
那么这里是不是又是一个引子，让你找到在这个体系里面新的要学习的东西？
而关于这个点，其实我之前也写文章解释过《【求锤得锤的故事】Redis锁从面试连环炮聊到神仙打架。》，你要不清楚，也可以去看看。
除此之外，你可以看到它左边的导航栏里面举了好几个例子：
这些都是自研的，但是其实一部分命令其实都是开源的，包括前面提到的 CAD 和 CAS 命令：
是不是又找到一个可以学习的方向？
比如有个 TairZset 命令。
我们知道，Redis 原生的 zset 主要可以用来做排行榜，但是只支持单维度的排序。
阿里搞了个 TairZset 命令，扩展了一下，就支持多维度了：
这个命令也是开源的。
性能排查与调优
这一部分的内容，简直就是绝了。
光看标题就知道是干货了。
比如我举其中的一个例子来说：
请问，Redis 的 CPU 使用率高了，你有哪些解决方案或者说是排查思路？
不知道没有关系，这里写了三种。
第一种是查找并禁用高消耗命令。
高消耗命令：即时间复杂度为O(N)或更高的命令。通常情况下，命令的时间复杂度越高，在执行时会消耗较多的资源，从而导致CPU使用率上升。
由于 Redis 的特性，在执行高消耗命令时会引发排队导致应用响应变慢。
极端情况下，甚至可能导致实例被整体阻塞，引发应用超时中断或流量跳过缓存层直接到达后端的数据库侧，引发雪崩效应。
那么我们怎么找到高消耗的命令呢？
这个就是它们产品提供的一个功能了：
这里面连数据都给你截上了，基本上看的是一清二楚。
那如果我们不用它的可视化页面，用原生的功能，怎么做呢？
slowlog-log-slower-than 和 slowlog-max-len 这个两个参数配置了解一下，前者是设置慢查询的阈值，后者是存放慢查询的记录。
而且，就算你面试的时候说，我们是通过可视化页面找到的高消耗命令，我也觉得没啥问题，毕竟主要是看你有那些思路。
有思路了，找到对应的解决方案还不是手到擒来的事情。
除此之外，还有这几个方案：
如果经过这些操作之后， CPU 的使用率还是很高怎么办？
在评估业务正常的情况下，加钱，加机器，升级配置。
最佳实践
一定一定一定要去看每个技术点对应的最佳实践这一部分。
比如在游戏玩家积分排行榜的这个实践中，还给你提供了一套环境以及直接可以运行的代码：
你只管按照步骤操作就行了。
又比如在JedisPool资源池优化的这里面。
针对 Redis 的配置给出了说明和建议值。合理的配置能够提升 Redis 的服务性能，降低资源开销。
这些都是很重要的关于参数的配置。
也许你自己配置的时候，从其他项目中随便就拷贝一个过来了，项目也跑的好好的，你甚至不知道每个参数是干啥的。
但是在这里，你能找到答案。
还有包括秒杀和双十一，这些看起来很厉害的东西，这里都有：
其他
比如在 RabbitMQ 里面，有关于消息幂等的最佳实践：
也有关于消息重试、延时队列等的高级特性的描述：
比如在数字金融里面有个这东西：
是一套在金融领域可复用的技术解决方案，而相关的技术栈的绝大部分都是开源的。
如果你之前不了解 SOFAStack 这个玩意，那么这个地方就是你了解它的入口。
上次有个读者问我关于 RocketMQ 的事务消息的问题，我虽然没有用过，但是我给他发过去一个连接：
这里面，就有他想要找的东西：
当时他问我：怎么随便一搜就能搜到一篇高质量的文章？
我说恰好之前看过而已。其实，我之前没有看过。
但是我知道阿里云上面肯定有卖 RocketMQ 服务的，那么它这里面大概率有这方面的资料。
所以我就上去那么随便一翻，就找到了。
这也是我想要把这个“学习网站”分享给你的原因，以后多一个找资料的地方，多一个学习新东西的地方，挺好的。