开篇词:从中间件开始学习分布式

开篇词:从中间件开始学习分布式

课程背景

谈及“分布式系统”,初学者的第一感觉多半是“高大上”和“深不可测”,犹如武林绝学——飞鸟投林、踏浪行波,行走江湖,即便没有见过,也应听过其名。

盛名之下无虚士,分布式系统凭借其高吞吐、高并发、低延迟和负载均衡的特点,迎合了互联网飞速发展背后的巨大承载量需求,民间和官方都有忠实粉丝为其著书立说,然而,大多倾向于理论,对于初学者有一定难度。鉴于此,我期望通过本课程中的系列文章,用理论与实践结合的方式阐明分布式系统的原理、优势及面临的挑战,进而指导实践。

那么,如何将理论与实践结合呢?切入点的选取是关键,几经考量,我选择了一个最具“通用性”的角度——中间件(Middleware)。如果你不清楚什么是中间件,那你也应该听说过 Redis、Kafka、ZooKeeper、Etcd、RabbitMQ、Nginx 之一,它们都是常用的中间件,可实现缓存、消息队列、锁以及负载均衡等。中间件是基础软件的一大类,属于可复用软件的范畴,顾名思义,中间件处于操作系统软件与用户的应用软件的中间,因此,中间件具有很好的独立性,可作为一个独立的软件系统运转。

随着互联网的飞速发展,高吞吐、高并发、低延迟和负载均衡已成为普遍需求,为此,作为枢纽的中间件也从“集中式”发展为“分布式”——如基于 Redis 的分布式缓存、基于 Kafka 的分布式消息队列、基于 ZooKeeper 的分布式锁等等。青山遮不住,毕竟东流去,随着“云时代”的到来,作为通用软件的中间件再次华丽转身,阿里云、腾讯云、华为云都竞相推出了“云中间件服务”——如 TencentDB for Redis、消息队列 CMQ、云数据库 Redis 等等,几乎应有尽有。

从另一角度来看,作为一名 IT 行业的研发人员,从普通研发工程师到架构师的成长之路上,分布式中间件是绕不过去的。青丝弹指雪,刹那芳华,如果可以,何不从现在开始学习?

课程框架

本课程从分布式系统切入,首先介绍了集中式系统到分布式系统的演进,并对分布式系统的特性和常见问题进行了阐述。而后进入正题,依次介绍了三大分布式中间件:分布式缓存、分布式锁以及分布式消息队列。

本课程分为四部分:

第一部分(第01课):基础篇。

优秀的理论可以指导实践,为了使读者更好的理解分布式系统和中间件,本部分内容以简练的笔触介绍了集中式系统到分布式系统的演进,并对分布式系统的特性和相关理论进行了阐述。最后,从应用场景出发,引出了三大分布式中间件。

第二部分(第02-06课):分布式缓存。

分布式缓存是应用范围最为广泛的中间件之一,因此最先介绍它。本部分内容首先对当前主流的分布式缓存方案进行了解读;随后浓墨重彩的阐述了 Redis-Cluster 的集群原理和基于 Redis 的分布式缓存实现,并列举了实际应用中 Redis 的典型异常、根因分析及解决方案;最后,结合源码分析了 Redis-Cluster 主节点故障场景下的调优策略。

第三部分(第07-10课):分布式锁。

在分布式系统中,为保障不同进程争夺共享资源的安全性,需要分布式锁协助。实现分布式锁的方案很多,本部分内容首先对比分析当前主流的分布式锁方案,之后详细解读了基于 Redis 的分布式锁实现和基于 Etcd 的分布式锁实现;特别是 Etcd,作为后起之秀,在很多方面优于 ZooKeeper,但目前在网上几乎找不到完整的方案,鉴于此,本部分对其进行了详细解读。

第四部分(第11-13课):分布式消息队列。

消息队列是分布式应用间交换信息的重要组件,可以解决应用解耦、异步消息、流量削锋等问题,是实现高性能、高可用、可伸缩和最终一致性架构中不可或缺的一环。本部分内容首先对当前主流的分布式消息队列方案进行了解读,之后深入浅出的阐述了基于 Kafka 的分布式消息队列实现和基于 RocketMQ 的分布式消息队列实现。

选择本课程的理由

如果你正在看这段内容,我相信你对本课程是感兴趣的,虽然我很期待你选择本课程,但坦诚地讲,并没有十分具有说服力的理由,选择与否,主要还在于你对 “效率” 这个词的理解。只要你有足够的耐心和时间,本课程中的部分知识在网上也能找到,当然,我并不推荐这种方式。对于分布式系统、中间件这类需要系统性学习的知识,网络搜索不仅费时费力,而且可信度存疑。

来自实践,服务实践

本课程是我从事中间件研发的经验总结,来自实践,服务于实践。课程主要包括分布式缓存、分布式锁、分布式消息队列三大部分内容,涉及 Redis、Etcd、Kafka、RocketMQ 等众多主流开源软件的使用方案。不仅提供关键源代码供读者快速实践,而且阐明其中原理并给出踩坑案例和调优分析,致力于授读者以渔。

理论加持,事半功倍

在 “多、快、好、省,跑步前进……”的“实用主义”熏陶下,理论二字,很多时候是令人反感的,似乎成了虚无、不切实际、缺乏实践意义的代名词。但凡事不可一概而论,事实证明,成功的实践背后常常有优秀的理论指导。

以 Redis 为例,官方推出的 Redis Cluster 号称最大可支持1000个实例的集群,为什么不可以再多一点,比如2000个呢?又或者这样问:为什么 BAT 都没有采用 Redis Cluster?如果读者知道 Redis Cluster 所采用的分布式一致性协议及其原理,那么一定不难回答上面的问题。

在实践中,理论加持常常可以达到事半功倍的效果,因此,本课程并不局限于方案的简单实现,而是在介绍方案的同时,对其背后的原理进行了深入浅出的论述。

方案对比,注重迁移

没有一种方案可以打遍全场,在中间件选型和方案设计的时候,需结合性能需求、开发成本、可扩展性、可维护性等进行综合评估。例如:基于 ZooKeeper 实现分布式锁的方案非常成熟,参考资料详实,但它并不一定适合你的应用场景,何不考虑一下 Etcd?等等,你是不是根本没有听说过 Etcd?

本课程介绍了三大中间件:缓存、锁、消息队列,并对每一种中间件的主流实现方案进行了对比分析,以便读者举一反三,迁移应用。

上一篇
下一篇
目录