分布式中间件实践之路

课程介绍

在分布式系统中,中间件是非常重要的组成,具有较高的技术门槛。同时,中间件相关的开源软件众多,适用场景各异,学习不易,对于初学者,本达人课无疑是值得一看的参考资料。

课程注重理论与实战结合,不仅提供关键源代码供读者快速实践,而且阐明其中原理并给出踩坑案例,行文力求语言生动,图文并茂,致力于授读者以渔。

应书澜,毕业于 C9 高校,硕士学历,曾在 IEEE ITS、VSD 等顶级刊物发表论文,在各大 站撰写博客百余篇。擅长嵌入式 & 物联 、预测算法、分布式中间件等相关技术。曾在华为、阿里巴巴,上海电气,浙能集团等公司重要项目中担任技术负责人或核心研发成员,现专注于中间件技术。

课程内容

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

课程背景

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

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

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

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

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

课程框架

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

本课程分为四部分:

第一部分(第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,你是不是根本没有听说过 Etcdp>

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

点击了解更多《分布式中间件实践之路》

第01课:走进分布式中间件(课前必读)

1. 白话分布式系统

关于“分布式系统”的定义,《分布式系统原理和范型》一书中是这样阐述的:“分布式系统是若干独立计算机的集合,这些计算机对于用户来说就像是单个相关系统”。

关于上述定义,直白点,可以这样理解:

  • 首先,分布式系统相对来说比较强大,至少由数台计算机组成。以阿里云、腾讯云、华为云等服务商为例,他们的数据中心计算机规模都在万台以上;
  • 其次,虽然分布式系统很强大,但是“深藏不露”,对用户来说,根本感觉不到计算机集群的存在,与单机无异。

更进一步,从进程角度看,两个程序分别运行在两台计算机上,它们相互协作完成同一个服务(或者功能),从理论上讲,这两个程序所组成的系统,就可以称作是“分布式系统”。当然,这个两个程序可以是不同的程序,也可以是相同的程序。如果是相同的程序,我们又可以称之为“集群”。

1.1 分布式系统——应需求而生

分布式系统出现之前,软件系统都是集中式的,俗称单机系统。在很长的一段时期,单机系统通过升级硬件就能满足不断增长的性能需求,然而,随着互联 的飞速发展,高吞吐、高并发、低延迟逐渐成为“刚需”,单凭硬件升级已无能为力,分布式系统 “应需求而生”。

集中式系统跟分布式系统是完全相反的两个概念。集中式系统就是把所有的程序、功能都集中到一台主机上,进而对外提供服务。从用户的角度来看,集中式系统与分布式系统并没有什么不同。比如,打开手机 App 浏览 页,用户看到的只不过是服务器返回数据的呈现,至于服务器是单机还是集群,用户无感知,也无须感知。

既然如此,为何分布式系统会被广泛应用呢很简单:需求驱动。

退回到20年前,那时的互联 远不像今天这么普及,计算机还只是作为辅助工具,典型的应用场景如: 企业级信息管理(生产信息、财务信息等)、图书馆书籍管理和查询等,数据量不过几百 GB ,用户数量不过几千人,一台服务器(单机系统)足以支撑。

然而,随着互联 时代的到来,情形已经完全不同。以一年一度的“双十一”电商狂欢节为例,2017年天猫双11全球狂欢节开场5分22秒,支付峰值达25.6万笔/秒,刷新全球纪录;同时诞生的还有数据库处理峰值记录,4200万次/秒。如此巨大的数据处理量,单机系统恐怕只能掩面而泣了。

1.2 分布式系统——双刃剑

分布式系统是由一组通过 络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其本质是利用更多的机器,实现更强大的计算、存储能力。

说得直白点,就像开餐厅,每天供应50个人用餐,一个厨师,一个灶台就够了;倘若每天供应5000人用餐,恐怕请一个食神也搞不定吧,怎么办呢100个普通厨师,100个灶台同时开火,将5000人的用餐压力分散到各个厨师,并使用员工守则对厨师进行管理。

通常,只有在单机系统完全无法满足需求的时候,我们才考虑分布式系统。因为,分布式系统提供的服务与单机系统本质是一样的,但分布式系统更为复杂,会引入很多单机系统没有的问题,为了解决这些问题又会引入更多的机制、协议,进而带来更多的问题。鉴于此,单机系统能够解决的问题,不要盲目采用分布式系统。这一点很好理解:管理一个厨师很容易,管理100个厨师问题就多了。

2. 分布式系统特性

2.1 内聚性和透明性

分布式系统是建立在 络之上的软件系统。继承软件的特性,分布式系统同样具有高度的内聚性和透明性。

内聚性是指每一个节点高度自治;透明性是指系统对用户来说都是透明的,用户无法感知系统是如何实现的。

2.2 可扩展性

分布式系统的设计初衷就是利用集群多机的能力来处理单个计算机无法处理的任务,当任务增加的时候,分布式系统的处理能力需要随之增强,通常有两种方式:其一,优化系统的性能或者升级硬件(Scale Up,即垂直扩展);其二,增加计算单元(如服务器等)以扩展系统的规模(Scale Out,即水平扩展)。

一般来说,垂直扩展更容易实现,不过成本更高,且垂直扩展存在单点失效的可能。而水平扩展通常成本更低,更加可靠,不过相对于垂直扩展而言更难实现。

那么,究竟选择哪种扩展方式呢需要全盘考虑,实际应用中,需要分布式系统处理的任务规模往往是变化的,理想的情形是:当任务量增加的时候,系统的处理能力可随之增强(比如增加服务器的数量);当任务量减少的时候,系统的处理能力可以减弱(比如减少服务器的数量),以避免资源浪费,这就是所谓的动态伸缩。显然,垂直扩展并不具备动态伸缩的能力,因此,分布式系统通常采用的是水平扩展方式,不仅可以实现动态伸缩,还可以松耦合、提升系统的容错能力。

2.3 可用性

其标准定义为,在要求的外部资源得到保证的前提下,系统在规定的条件下和规定的时刻或时间区间内处于可执行规定功能状态的能力。以下通过一个计算公式来直观的感受可用性:

Availability = MTBF / (MTBF + MTTR)*100%

其中,MTBF(Mean Time Between Failure)是指相邻两次故障之间的平均工作时间,MTTR(Mean Time To Repair)是指系统由故障状态转为工作状态所需修复时间的平均值。通常,用 N 个9来表征系统可用性,比如99.9%(3-nines Availability),99.999%(5-nines Availability)。

2. 并行方式:将注册信息写入数据库成功后,发送注册邮件的同时,发送注册短信。以上三个任务完成后,返回给客户端。与串行的差别是,并行的方式可以提高处理的效率。

应用解耦

以电商 IT 架构为例,在传统紧耦合订单场景里,客户在电商 站下订单,订单系统接收到请求后,立即调用库存系统接口,库存减一,如下图所示:

流量削锋

像双11秒杀、预约抢购等活动,通常会出现流量暴增,当外部请求超过系统处理能力时,如果系统没有做相应保护,可能因不堪重负而挂掉。

这时,我们可以引入消息队列,缓解短时间内高流量压力:

  1. 用户的秒杀请求,服务器接收后,首先写入消息队列,然后返回成功。假如消息队列长度超过最大数量,则直接抛弃用户请求或跳转到失败页面;
  2. 秒杀业务根据消息队列中的请求信息,再做后续处理(根据数据库实际的select、insert、update 能力处理注册、预约申请)。

enter image description here
消息通讯

消息通讯很好理解,以微信群聊为例:

  1. A 通过客户端发送消息到群里,服务端将消息写入消息队列;
  2. 消息队列,负责消息数据的接收,存储和转发;
  3. B 通过客户端查看群消息,订阅并消费消息队列中的信息。

8. 总结

参考文献与致谢

  1. 什么是分布式系统,如何学习分布式系统
  2. 浅谈分布式缓存那些事儿
  3. 多线程并发常见问题
  4. 分布式缓存那些事儿
  5. 并发并行与分布式系统 CAP 理论中的 P 到底是个什么意思li>
  6. CAP 理论基础(注解)
  7. 浅谈分布式缓存那些事儿

点击了解更多《分布式中间件实践之路》

第02课:主流分布式缓存方案的解读及比较
第03课:分布式一致性协议 Gossip 和 Redis 集群原理解析
第04课:基于 Redis 的分布式缓存实现及加固策略
第05课:Redis 实际应用中的异常场景及其根因分析和解决方案
第06课:Redis-Cluster 故障倒换调优原理分析
第07课:基于 Redis 的分布式锁实现及其踩坑案例
第08课:分布式一致性算法 Raft 和 Etcd 原理解析
第09课:基于 Etcd 的分布式锁实现原理及方案
第10课:主流的分布式消息队列方案解读及比较
第11课:搭建基于 Kafka 和 ZooKeeper 的分布式消息队列
第12课:深入解读基于 Kafka 和 ZooKeeper 的分布式消息队列原理
第13课:深入浅出解读 Kafka 的可靠性机制

阅读全文: http://gitbook.cn/gitchat/column/5b7d127b84322801444db274

文章知识点与官方知识档案匹配,可进一步学习相关知识云原生入门技能树首页概览8826 人正在系统学习中 相关资源:Wikka高速可伸缩性软件v1.3.1-其它代码类资源-CSDN文库

声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2018年10月4日
下一篇 2018年10月4日

相关推荐