当前位置: 首页 > news >正文

《深入理解分布式系统》之认识分布式系统

本文是阅读深入理解分布式系统第一章认识分布式系统时的笔记。

分布式系统的特点

  • 多进程
  • 不共享操作系统
  • 不共享时钟

分布式系统

  • 由多个可独立运行的子系统组成。
  • 每个子系统可以独立选择运行平台。
  • 不同的运行平台存在差异,比如操作系统,硬件规格等。
  • 由于底层平台不同,因此无法共享底层基础设施,比如:
    • 通信,无法使用单机常见的通信机制,只能使用消息来通信,比如TCP、消息队列等。
    • 时钟,不同平台的时钟精度不同,或多或少存在一定的误差,且无法完全避免。

传统的单体应用
与分布式系统相比:

  • 所有子系统或者组件在同一个进程内运行。
  • 所有子系统运行于相同的平台上,依赖相同的底层平台。
  • 所有的子系统需要适配共同平台的特点,适应优点和缺点。
  • 所有的子系统共享相同平台的基础设施。
    • 由于在同一个进程内,子系统之间通信时,可选择的方案很多,并且可靠。
    • 在同一个平台上,时钟的误差相对稳定,对所有子系统的影响是相同的。

分布式系统的异构优势
对于分布式系统而言,不同的子系统可以使用不同的底层平台和硬件规格,因此可以依据不同的需求,做出不同的选择。比如:

  • 对于计算密集型的子系统,可以配置核数多、计算频率高的CPU。
  • 对于缓存型业务的子系统,可以配置大的内存,尽可能将数据缓存至内存中,提升缓存的访问效果。
  • 对于网络I/O密集型的子系统,可以配置带宽大、处理能力强的网卡。
  • 对于文件I/O密集且时延敏感的子系统,可以配置SSD盘,降低I/O处理时延,提升I/O吞吐量。
  • 对于文件I/O密集且时延不敏感、吞吐量敏感的子系统,可以配置HDD盘,满足大带宽的访问能力,同时有效降低成本。

使用分布式系统的主要动力
使用分布式系统来承载业务交付的主要动力:

  • 高性能
    简单的堆砌硬件,提升硬件规格,可能已经无法满足客户对业务性能的诉求。
    提升硬件的规格目前面临物理定律的限制,提升的难度和成本快速增长,相比之下提升规格的效益和投入成本越来越不匹配。
    从单机系统迁移至多机的分布式系统,堆砌简单、低成本的硬件,期望换取性能的线性或者准线性增长。
  • 可扩展性
    性能不足时,可以通过向集群中增加新的节点,来提升性能,同时不会显著增加系统复杂度以及各类成本。
  • 高可用
    降低子系统失效时,对业务整体的影响。
  • 必要性
    不同地域,不同业务归属等原因,导致一些业务系统天然具备分布式系统的特征。

个人见解
在做技术选型时,从开发、验证、维护的角度来说,假如单体系统或者单体应用可以满足客户要求的功能、性能、扩展性等要求的话,优先选择单体的方案,快速交付、快速满足客户需求,争取到活下来的机会,然后再依据客户的诉求,业务发展的方向,逐步迁移技术路径,将单体应用逐步改造为分布式系统,支撑业务不断迭代和成长。

常见的分布式系统
依据Google的成功经验,梳理分布式系统的服务,如下:

  • 分布式锁服务
  • 分布式协调服务
  • 分布式缓存服务,键值对
  • 分布式存储服务
    • 分布式块服务
    • 分布式文件服务
    • 分布式对象服务
  • 分布式数据库
    • NoSQL数据库
    • 行式数据库
    • 列式数据库
  • 分布式缓存型数据库
    • 行式数据库
    • 列式数据库
  • 分布式批处理服务
  • 分布式流处理服务
  • 分布式计算服务
  • 分布式图计算服务
  • 分布式调度服务
    • 任务的类型
      • 定时任务
      • 一次性任务
    • 任务的操作
      • 新建
      • 执行
      • 暂停
      • 删除
    • 任务之间的依赖关系
    • 资源的分配和管理
  • 时钟服务
  • DNS服务
  • 集群管理
    • 扩容
    • 缩容
    • 隔离
    • 监控
      • 告警
      • 性能
    • 升级
    • 回退
    • 打补丁

常见的思维误区
设计、交付分布式系统时,常见的思维误区:

  • 网络是可靠的。
  • 子系统间传递信息的延迟为零。
  • 子系统间传递信息时的带宽是无限的。
  • 子系统间通信时的网络是安全的。
  • 网络拓扑结构不会发生改变。
  • 有单一、万能且不会犯错的管理员。
  • 子系统之间传递信息的传输成本为零。
  • 网络是同构的。

网络延迟类的问题
在传递消息时,发送者创建、发送消息,消息通过网络传递至接收者。

  • 从发送者角度来看

    • 消息丢失,即发送消息后,消息没有传递给接收端。
    • 在超时前,没有等到回应,即发送消息后,发送者等待一段时间后没有收到接收者的回应,从而判定消息丢失。但有可能接收者确实收到了消息,但整体上耗时超出发送者的预期。
    • 重试之后,仍然无法按照发送者预期的方式通信,导致发送者判定接收者失效,但接收者可能是正常的。
    • 网络传输消息时,可能无法保证时序,即发送者接收到响应消息,但顺序和预期存在差异。
  • 从接收者的角度来看

    • 发送者可能重复发送了消息,比如发送者设置的超时值太短。
    • 网络在传递消息时,可能由于各种原因,多次传递了消息,导致接收者收到了重复的消息。
    • 网络传输消息时,可能无法保证时序,即接收者收到消息时,消息的顺序和发送时的顺序不同。

部分失效的问题
客户期望分布式系统中个别子系统失效,不影响整体业务的表现。
但在分布式系统中,各子系统可能会以预想不到的方式出现失效,从而显著提升相关问题的定位、修复的难度。

时钟的问题
手表定律

拥有两块以上的手表并不能帮人更准确的判断时间,反而会制造混乱,让看表的人失去对时间的判断。

对于分布式系统而言,由于子系统运行在各种平台上,各自拥有不同的时钟,从而导致无法准确、一致的预计时间,因此判断事件的先后顺序,变成了一件极其有挑战的事情。

常规操作的规格
掌握常见操作的时延,有助于评估分布式系统场景下各业务处理流程的耗时,从而选择最佳的实现方案。

常见的评估指标
比如时延、带宽、吞吐量等。

相关文章:

  • C语言| 递归求1+2+...+100的和
  • Ragflow服务器上部署教程
  • 已经写好论文的AI率降低
  • VTK|结合qt创建通用按钮控制显隐(边框、坐标轴、点线面)
  • 嵌入式学习--江协51单片机day1
  • 【HDLBits刷题】Verilog Language——1.Basics
  • 代码随想录算法训练营总结篇
  • Kubernetes弹性伸缩:让应用自动应对流量洪峰与低谷
  • 购物|电商购物小程序|基于微信小程序的购物系统设计与实现(源码+数据库+文档)
  • OpenKylin安装Elastic Search8
  • k8s node 内存碎片化如何优化?
  • 文件上传漏洞篇:upload-labs靶场搭建
  • Ubuntu 系统中解决 Firefox 中文显示乱码的完整指南
  • 代码随想录算法训练营第五十六天| 图论2—卡码网99. 岛屿数量(dfs bfs)
  • 养生融入生活,畅享健康人生
  • MySQL8查询某个JSON类型的字段中出现过的所有键名(json key name)并去重返回
  • conda虚拟环境相关操作
  • 第三章:langchain加载word文档构建RAG检索教程(基于FAISS库为例)
  • Spring Boot项目集成Aviator实现成本计算模块
  • 【阿里云大模型高级工程师ACP习题集】3 总结与展望
  • 印媒证实:至少3架印军战机7日在印控克什米尔地区坠毁
  • 巴基斯坦:印度向巴3处地点发射导弹
  • 五一假期上海楼市延续向好态势,成交量同比增加36%
  • 默茨在德国联邦议院第一轮投票中未能当选总理
  • 五一假期上海两大机场客流量超193万人次,创历年同期最高
  • 100%关税!特朗普要让美国电影100%美国制造