侧边栏壁纸
博主头像
why

一个主要敲代码,经常怼文章,偶尔拍视频的成都人。

  • 累计撰写 181 篇文章
  • 累计创建 11 个标签
  • 累计收到 88 条评论

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

why
why
2022-02-28 / 0 评论 / 2 点赞 / 226 阅读 / 4,888 字
温馨提示:
关注公众号why技术,第一时间接收最新文章。

你好呀,我是歪歪。

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

就是阿里云。

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

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

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

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

好了,话不多说,发车。

帮助中心

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

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

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

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 服务的,那么它这里面大概率有这方面的资料。

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

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

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

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

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

荒腔走板

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

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

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

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

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

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

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

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

0

评论区