内容整理自
邴越
的分布式技术原理与实战45讲
,『一块钱上车传送门』。持续学习,遇见更好的自己!
一、 分布式系统
1. 集中式系统的性能问题
毕竟单台机器的性能有限,集中式架构的性能问题主要包含:
- 可用性不高,容易出现点单故障
- 可扩展性不高,水平扩展系统容量的难度较大
- 可维护性低,业务系统间的耦合程度大
- 成本高,高配置机器成本和低配置机器的成本并不是线性关系
2. 分布式系统的好处
分布式系统的核心是 可扩展性
,通过多台机器的合作来完成单台机器无法完成的任务。好处是:
- 成本低,可以由多台一般配置的机器协同合作,来完成需要高配置机器才能完成的工作。
- 可用性高,多台机器同时出故障的几率要小于单台机器出故障的几率。
- 可扩展性高,理想情况下,只需要水平增加机器就可以线性增加系统容量
3. 分布式系统常见问题
由于分布式系统由多台机器协同合作来提供服务,虽然避免了 单点故障
,提高了可用性,但也存在一些问题:
- 多台机器间的通信:
- 时序性
- 网络可用性
- 多台机器间的数据:
- 状态的一致性
- 同步的实时性
二、 CAP理论
1. 结论
CAP 理论指出,一个分布式系统只能同时满足以下两点:
-
Consistency
一致性:所有机器同时看到相同的数据 -
Availability
可用性:任何时候,读写都是成功的 -
Partition Tolerance
分区容忍性:部分机器通信延迟、失败或者故障时,系统还可以继续提供一致、可用的服务
2. 结论反证
假设能够同时保证 CAP,因为 P 的存在,则一定存在部分机器间无法通信的情况,那么则一定无法保证所有机器之间的一致性。
3. CP 和 AP
由于 P 是一定的,分布式系统可分为:
- CP:牺牲一些可用性,来保证更好的一致性。如:ZooKeeper,用来解决分布式系统中多台机器的协调和一致性问题。
- AP:牺牲一些一致性,来保证更好的可用性。如:Eureka,用来在微服务系统中提供服务的注册和查询功能。
三、 Base 理论
1. 一致性分类
一致性分类:
- 强一致性:多台机器的状态,一致且实时。
- 弱一致性:多台机器的状态,在用户能够接受的时间范围内,能达到
最终一致
。细分:- 因果一致性,如:会话一致性
- 单调读一致性
- 单调写一致性
2. 因果一致性举例
因果一致性是指,有因果关系的操作在顺序上能够得到保证
。即:机器 A 完成了对某数据的更新,然后告知了机器 B,机器 B 必须能够读取到机器 A 更新后的数据,如果机器 B 也要更新那个数据,必须在机器 A 的更新结果上进行更新。
比如微信:你发了一个朋友圈,你的朋友进行了评论,评论动作由 A 机器来完成。此后,你又对朋友的评论进行了回复,回复动作由 B 机器来完成。这时的 评论
和 回复
就有因果关系,执行顺序必须得到保证。
3. 会话一致性举例
会话一致性是指,在一个会话中,必须 能够读到刚才写入的数据
。比如:分布式系统中的 session 一致性问题。
4. Base 理论
Base 理论的核心思想是 最终一致性
,简单概述就是:放弃强一致性,追求分区容错性和可用性。具体是:
- Basically Available,基本可用。
基本可用是指,不追求 任何时候读写都是成功的
,而是 系统能够基本运行,一直提供服务
。例如:在一些秒杀系统中,当最大 QPS 超过系统容量时,返回的 稍后再试
,就是基本可用的一种表现。
- Soft State,软状态。
对比数据库中的 ACID 模型,要求操作的原子性,结果的一致性,就是一种 硬状态
。而 软状态
是指,允许系统中的数据存在中间状态,并且不影响系统的整体可用性。比如:数据库集群中的同步延迟问题,我们可以接受这个延迟,多个机器间的数据短时间内的不一致,就是一种 软状态
。
- Eventually Consistent,最终一致。
最终一致
是指,数据不能一直是 软状态
,需要在一个能接受的时间范围内,能够达到一致性。还以数据库集群为例,我们允许同步延迟,但还是要能够 在一定时间后,集群达到一致
,而这个 迟到的一致
就称为 最终一致
。
5. Base 和 CAP 的关系
Base 是在 CAP 的基础上演化而来的。CAP 指出了 一致性、可用性、分区容错性,这三者只能选择两者
,Base 是一种 AP 方案,即:在分区容错性一定存在的前提下,通过将强一致性退化为最终一致性的牺牲,来最求更好的可用性
。
很多分布式系统都在选择 Base 理论作为架构方式,比如:NoSQL 和 微服务,强调通过服务降级等方式保证基本可用,最求更高的可扩展性,从而保证更好的可用性。而某些对数据有强一致性要求的应用,如金融系统,则应该选择 CP 思路的架构方式。
网友评论