分布式核心面试技术(持续更新)

Posted 2021-06-29 醉酒的小男人

分布式和集群的关系

分布式关注项目拆分,集群关注项目部署

分布式三态

如果某个节点向另一个节点发起RPC(Remote procedure call)调用,即某个节点A向另一个节点B发送一个消息,节点B 根据收到的消息内容完成某些操作,并将操作的结果通过另一个消息返回给节点A,那么这个RPC执行的结果有三种态：“成 功”、“失败”、“超时(未知)”,称之为分布式系统的三态。

互联网三高

高性能、高扩展、高可用

高性能

 

响应 ( 低延时 )

吞吐 ( 高吞吐量、高并发 )

如果有人要求你提升系统的性能 : 1 ：降低延时 2 ：提高吞吐

1. 降低延时

优化存钱系统 :

1: 存钱 10 秒 -> 存钱 5 秒 , 延时降低 , 吞吐量自然就提高

amdah 定律

要想显著加速整个系统 , 系统提升全系统中相当大的部分的速度 A-B-C-D-E

2. 提高吞吐量

amdah 定律告诉我们 , 提升系统的响应比较困难 , 所以现在很多系统的性能提升体现在提高吞吐量上 -> 各种各样的系统架构

举例

集群 - 吞吐、负载均衡 - 吞吐、缓存 - 响应、 JVM 优化 - 响应、分库分表 - 吞吐 / 响应、 tomcat 非堵塞协议 - 响应、 MQ- 响应、云

原生 -k8s- 动态扩缩容

个人对分布式集群微服务的理解

https://blog.csdn.net/xiaowanzi_zj/article/details/117604747

CAP理论

Consistency(一致性)

所有节点访问同一份最新的数据副本

Availability(可用性）

每次请求都能获取到非错的响应 , 但不保证获取的数据为最新数据

Partition tolerance(分区容错性)

不能在时限内达成数据一致性 , 就意味着发生了分区的情况 , 必须就当前操作在 C 和 A 之间做出选择）

白话理解 :

分区容错性是指系统能够容忍节点之间的网络通信的故障 , 假设我们有一台 Tomcat 服务器 , 部署在全国各地 , 像浙江节点、上

海节点、武汉节点 , 但是可能出现其中某个节点由于网络故障不能使用 , 无法进行通讯 ; 一般来说 , 现实中分区容错是无法避免

的 , 因此可以认为 CAP 的 P 总是成立。 CAP 定理告诉我们 , 剩下的 C 和 A 无法同时做到。

 CAP定律组合

在分布式、微服务系统中 ,CAP 定律三者无法同时兼顾 , 其中可以容忍网络之间出现的通讯故障 , 只能 CP 和 AP 二选一。

CP: 当网络出现故障之后 , 只能保证数据一致性 , 但是不能保证可用性 (Zookeeper), 意味着服务不能用；

AP: 当网络出现故障之后 , 不能保证数据一致性 , 但是能保证可用性 ( 比如 Eureka), 意味着可允许短暂的数据不一致性 , 但最

终需达到一致 , 其他节点可正常提供服务 ;

BASE理论

 

BASE 是 Basically Available( 基本可用 ) 、 Soft state( 软状态 ) 和 Eventually consistent( 最终一致性 ) 三个短

语的缩写。 BASE 理论是对 CAP 中 AP 的一个扩展 , 通过牺牲强一致性来获得可用性 , 当出现故障允许部分不可用但要保证核心功

能可用 , 允许数据在一段时间内是不一致的 , 但最终达到一致状态。满足 BASE 理论的事务 , 我们称之为柔性事务

基本可用

分布式系统在出现故障时 , 允许损失部分可用功能 , 保证核心功能可用。如电商网址交易付款出现问题来 , 商品依然可以正常浏览

软状态

由于不要求强一致性 , 所以 BASE 允许系统中存在中间状态 ( 也叫软状态 ) 这个状态不影响系统可用性 , 如订单中的 “ 支付 中” 、 “ 数据同步中 ” 等状态 , 待数据最终一致后状态改为 “ 成功 ” 状态

最终一致性

最终一致是指的经过一段时间后 , 所有节点数据都将会达到一致。如订单的 “ 支付中 ” 状态，最终会变为 “ 支付成功 ” 或者 “ 支付 失败”, 使订单状态与实际交易结果达成一致 m 但需要一定时间的延迟、等待