看麻了,竟然是个学习网站?
今天,我想给大家分享一个很多人都不知道的学习网站。
就是阿里云。
我估计有很多人看到“阿里云”这几个字出来的时候,就浮现出不好的感觉,心中暗喊:不好,感觉这是一个广告。赶紧跑。
但是,你放心,这真不是广告。
确实,从本质上来讲,这是一个卖服务的网站。但是壮士请留步啊,我又不叫你去这上面买服务,我真的在这上面学到了很多有用的知识。
放心,学这些知识不要钱的。
当然了,阿里云要是能看到我的文章,想要给我打一笔钱我也是很乐意的。
好了,话不多说,发车。
帮助中心
如果你觉得阿里云是一个卖服务的网站,是一个让你花钱的地方,说明你的打开方式是官方期望的打开方式。
但是如果你用我的打开方式,它就会摇身一变,变成一个免费的学习网站。
我的打开方式,就是从它「帮助中心」进去:
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 服务的,那么它这里面大概率有这方面的资料。
所以我就上去那么随便一翻,就找到了。
这也是我想要把这个“学习网站”分享给你的原因,以后多一个找资料的地方,多一个学习新东西的地方,挺好的。
完!