Neo's Blog

不抽象就无法深入思考
不还原就看不到本来面目!

0%

分布式系统介绍

为什么会有分布式

两点:算得慢(算力不足),存不下(数据分散)。

无论是线程、进程,还是协程,本质上,目的都是为了计算的并行化,解决的是算的慢的问题。

因为一个CPU算不过来,而单机扩容CPU数量成本极高(有空间这个刚性限制),所以需要水平扩容,多搞几台机器。

计算的分布式化:基于分治思想,出现了分布式框架。

MapReduce: 分布式计算的总体思想。

分布式计算框架更多尝试对资源的调度做优化。ResourceManager, yarn, k8s;
(多租户,隔离,软隔离,租借,抢占等)

高并发系统的三个目标与挑战

高并发是一个系统的挑战

如何衡量一个系统的并发有多高呢? 同时在线人数

高性能、高可用、可扩展是一个牛B系统目标

三者的关系

为了保证高可用,需要冗余更多的相同功能机器(replication),要求系统可扩展;

为了保证高性能,必须需要更多的相同功能的机器(存储的replication、应用的无状态)或者服务于不同对象的机器(shard),也要求可扩展;

一份完整的数据,分为多个shard的过程需要可扩展;

一份数据冗余了多份,前端对下游访问时用到的负载均衡策略需要可扩展。

如何衡量一个吞吐量有多大呢?

系统的QPS,吞吐量 = 并发进程数 / 响应时间

如何衡量一个系统的性能有多高呢?

一旦系统的负载被描述好,就可以研究当负载增加会发生什么。我们可以从两种角度来看:

  • 增加负载参数并保持系统资源(CPU、内存、网络带宽等)不变时,系统性能将受到什么影响?(接口响应时间,分位耗时)
  • 增加负载参数并希望保持性能不变时,需要增加多少系统资源?

如何衡量一个系统的可用性有多高呢?

平均故障间隔,平均故障恢复时间

不同可用性标准下允许的故障时间

如何衡量一个系统的可扩展能力?

考察一个问题:能够通过增加进程来应对更高的并发? 如果一直加机器,我一直能线性的提高系统的处理能力吗?

如何应对系统的挑战

架构通用原则:“4 要 1 不要”

(1) 数据要尽量少

  • 用户请求的数据能少就少
  • 系统依赖的数据能少就少

(2) 请求数要尽量少

例如,静态文件合并

(3)路径要尽量短

将强依赖的服务进行单机部署

(4)依赖要尽量少

系统服务分级,高等级服务尽量少依赖低等级服务

(5)不要有单点

服务无状态,可扩展;存储层做副本备份

主流系统架构

你的支持是我坚持的最大动力!