找回密码
立即注册
搜索
热搜: Java Python Linux Go
发回帖 发新帖

3672

积分

0

好友

503

主题
发表于 昨天 18:56 | 查看: 2| 回复: 0

主要介绍分布式经典理论相关面试题。涉及领域广泛,包括CAP基础理论、分布式事务、分布式ID、负载均衡、系统并发能力、微服务划分、限流算法等。掌握这些核心问题,能帮助你在技术面试中建立起对分布式架构的清晰认知。

1、什么是CAP、Base理论?

CAP定理,指的是在一个分布式系统中,最多只能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)这三项中的两项。(三选二)

C:一致性(Consistency),数据在多个副本中保持一致,可以理解成两个用户访问两个系统A和B,当A系统数据有变化时,及时同步给B系统,让两个用户看到的数据是一致的。

A:可用性(Availabiity),系统对外提供服务必须一直处于可用状态,在任何故障下,客户端都能在合理时间内获得服务端非错误的响应。

P:分区容错性(Partition tolerance),在分布式系统中遇到任何网络分区故障,系统仍然能对外提供服务网络分区。可以这样理解,在分布式系统中,不同的节点分布在不同的子网络中,有可能子网络中只有一个节点。在所有网络正常的情况下,由于某些原因导致这些子节点之间的网络出现故障,导致整个节点环境被切分成了不同的独立区域,这就是网络分区。

如下图所示,A、B两地的数据需要保持同步,这正是CAP中一致性和分区容错性矛盾的体现。

数据同步示意图

注意点

  1. 网络分区是必然存在的,因此P(分区容错性)是分布式系统必须保证的。
  2. CP(一致性+分区容错性)和AP(可用性+分区容错性)只能满足其一。
  3. 实际应用案例:注册中心Eureka选择的是AP,Zookeeper选择的是CP。

2、谈谈你对分布式事务的理解?

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单说,就是一次大的操作由不同的小操作组成,这些小的操作分布在不同的服务器上,且属于不同的应用,分布式事务需要保证这些小操作要么全部成功,要么全部失败。

常见的解决方案和延伸问题包括:

  • 什么是两阶段提交(2PC)、三阶段提交(3PC)?
  • 什么是补偿性事务(TCC)?
  • 如何使用消息队列和事件表实现分布式事务?
  • RocketMQ在分布式事务中的应用?

3、分布式幂等性如何设计?

幂等性是指用户对于同一操作发起的一次请求或者多次请求的结果是一致的,不会因为多次点击而产生副作用。在分布式环境下,网络超时、重试机制等都可能导致请求被重复执行,因此幂等设计至关重要。

常见的解决方案包括:Token机制、唯一索引、数据库乐观锁/悲观锁、状态机、防重表等。

4、分布式ID生成有哪些方案?

在分布式系统中,生成全局唯一的ID是一个基础需求。常用的方案有以下几种:

分布式ID生成方案思维导图

核心方案包括:

  1. 数据库唯一ID:基于数据库自增ID或序列。
  2. UUID:通用唯一识别码,本地生成,但无序且较长。
  3. Snowflake雪花算法:Twitter开源的分布式ID生成算法,生成的是趋势递增的64位长整型。
  4. 百度UIDGenerator:基于Snowflake的优化实现。
  5. Redis生成ID:利用Redis的原子操作INCR或INCRBY来生成序列号。

每种方案都有其适用场景和优缺点,需要根据业务的数据量、并发要求、是否有序等维度进行选择。

5、如何处理数据库中大数据量?

处理海量数据,常见的思路是对数据库进行:分区、分库分表,以及主从架构(读写分离)。

1. 分区:数据隔离
分区是将一个表的数据按照某种规则(如范围、列表、哈希)划分到多个物理存储单元中,但对应用来说仍然是一张表。主要目的是便于数据管理和维护。

数据库表分区存储策略

2. 分库分表
当单库单表数据量或并发达到瓶颈时,就需要进行分库分表。

  • 水平分库/分表:将同一个表的数据按某种规则拆分到不同的库或表中,各个库和表的结构一模一样
  • 垂直分库/分表:按照业务模块将不同的表拆分到不同的数据库中,或者将一个宽表拆分成多个小表,各个库和表的结构不一样

下图展示了一个典型的水平分表场景:

数据库分片架构图

3. 读写分离
主从架构是提升数据库读能力的经典方案。主机(Master)负责处理写操作(Insert, Update, Delete),从机(Slave)负责处理读操作(Select),主从之间通过数据同步保持一致性。

数据库主从架构读写分离示意图

6、常见的负载均衡算法有哪些?

负载均衡将请求合理地分发到集群中的服务器上,是保障系统高可用的关键。

1. 轮询负载均衡算法
Round Robin (RR),顺序循环地将请求依次分配给每台服务器。

2. 加权轮询算法
Weighted Round Robin (WRR),在轮询的基础上,给性能好的服务器分配更高的权重,使其处理更多的请求。

3. 随机算法
完全随机地选择一台服务器,在请求量足够大时,也能近似实现均匀分布。

4. 最少连接算法
Least Connections,将新的请求分发到当前连接数(或请求数)最少的服务器上。这能动态地将负载导向压力最小的节点,是最符合负载均衡目标的算法之一。实现时可以利用Redis的incr命令来统计和比较各服务的连接数。

7、熔断和降级的区别?

熔断和降级都是保障系统高可用性的重要手段,目的是在系统出现异常或压力过大时,防止故障蔓延导致雪崩效应。

1. 相同点

  • 目标一致:都是为了防止系统的整体响应缓慢甚至崩溃。
  • 体验相似:最终用户都可能体验到某些功能暂时不可用。
  • 服务级别:通常都是针对某个或某些服务进行的操作。
  • 自治性高:在现代微服务架构下,两者都倾向于通过配置和策略自动触发。

2. 区别

  • 触发原因:服务熔断一般是下游服务(被调用方)出现故障(如响应超时、错误率升高)时触发,以快速失败避免资源耗尽。服务降级一般是从整体系统负荷考虑,主动关闭一些非核心服务或功能,以保证核心业务的可用性。
    服务熔断机制示意图
  • 作用层次:熔断通常是框架级的通用处理(如Hystrix, Sentinel),每个服务间的调用都可能需要。降级则更多在业务调用链的上层进行处理,比如在网关或聚合服务层,对非关键路径进行降级。
    服务降级逻辑示意图

8、如何进行服务划分?(微服务拆分)

微服务划分的核心原则是依据系统业务的边界,即“高内聚,低耦合”。通常按照功能域业务能力进行拆分。

例如,一个电商系统可以拆分为:用户服务、商品服务、订单服务、支付服务、库存服务等。每个服务负责一个独立的业务领域,拥有自己的数据库,并通过API进行通信。

下图展示了一个从硬件到业务服务的分层架构示例,其中“核心组件”和“业务服务”层都可以按照功能域进行服务化拆分:

系统分层与微服务架构示意图

9、如何提高系统并发能力?

提高系统并发能力是一个系统工程,需要从多个层面进行优化:

  1. 应用层面:优化代码性能,使用缓存(如Redis),采用异步处理(如消息队列)。
  2. 架构层面:引入负载均衡,进行服务化拆分,实现读写分离和分库分表。
  3. 基础设施层面:使用高性能的Web服务器和网络组件,进行硬件升级或采用云服务的弹性伸缩能力。

核心思路是:纵向提升单点能力(优化),横向扩展系统规模(扩容),并引入缓冲和异步机制来削峰填谷。

10、了解那些常用的限流算法,说说原理?

限流是保护系统不被突发流量冲垮的关键技术。以下是三种经典算法:

1. 滑动时间窗口算法(计数器算法)
在指定的时间周期内(时间窗口),累加访问次数,达到设定阈值即触发限流。下一个周期开始时,计数器清零。

滑动时间窗口限流算法图示

如图所示,设置一分钟的阈值是100。此算法实现简单,但存在临界问题。例如在0:50到1:10这20秒内,请求数可能达到120,已经超过了1分钟100的阈值,但系统却不会限流,因为这两个请求峰值落在了相邻的两个时间窗口内。

2. 漏桶算法
漏桶以恒定的速率流出请求(处理请求),而不论请求流入的速度有多快。当流入速度超过流出速度导致桶满时,新的请求就会被丢弃(触发限流)。

漏桶算法原理示意图

漏桶算法能平滑流量,但无法应对短时间的突发流量,因为流出速率是固定的。

3. 令牌桶算法
系统以恒定的速率向一个桶里放入令牌。请求到达时,需要先从桶中获取一个令牌,拿到令牌才能被处理。当桶里没有令牌时,则触发限流。

令牌桶算法流程图

令牌桶算法允许一定程度的突发流量(只要桶中有足够的令牌),同时又能以平均速率进行限流,是目前最常用的限流算法之一。


以上10个问题覆盖了分布式系统设计的核心领域,是技术面试中的高频考点。深入理解其原理和适用场景,不仅能助你顺利通过面试,更能为设计和构建高可用、可扩展的系统打下坚实基础。如果你想获取更多面试真题解析和求职辅导,可以来云栈社区与更多开发者交流学习。




上一篇:亿级用户实时排行榜系统设计:从Redis ZSet到分片架构的完整指南
下一篇:深入解析分布式锁四大方案:数据库、Redis、Redission与ZooKeeper源码及高并发场景选型
您需要登录后才可以回帖 登录 | 立即注册

手机版|小黑屋|网站地图|云栈社区 ( 苏ICP备2022046150号-2 )

GMT+8, 2026-3-4 03:16 , Processed in 0.384288 second(s), 42 queries , Gzip On.

Powered by Discuz! X3.5

© 2025-2026 云栈社区.

快速回复 返回顶部 返回列表