当前位置:   article > 正文

Java面试题-分布式_java分布式面试题

java分布式面试题

分布式

1. 谈谈业务中使用分布式的场景

为什么需要使用分布式:单体项目的性能瓶颈问题,需要分布式提升性能。

  • 场景1:服务拆分。

​ 单体项目将不同服务进行拆分,拆分后的服务可以支持横向扩容,避免因为单台服务器问题影响整体项目。

  • 场景2:数据库拆分。

数据库读写分离,分库分表等提升性能。

2. Session分布式方案

项目场景:

  • 传统项目:

    服务器的session保存在本地,每次请求都会在同一个地方, 只要session没有过期则一定能够获取到session对象。

  • 分布式项目:

    有多个服务器,不同的请求发送到不同的服务器,不同服务器Session如何确保能够获取到?

解决方案:

  1. session复制

    Tomcat原生支持seesion同步,通过广播的方式进行异步同步,通过网络进行数据传输。在服务器集群较多时,session同步会占用大量带宽,同时session的增多导致单台服务器的内存会被大量占用。

    session复制适用于集群数量不多的情况下。

  2. 客户端存储

    直接将session数据存储到cookie中,每次请求解析cookie中的session数据。

    cookie是不安全的,且每次请求携带会增加网络传输开销。

  3. Hash一致性

    通过nginx的负载均衡配置,设置ip-hash策略,将客户端与服务器绑定,使同一ip的请求都转发到同一台服务器。

    一旦某台服务器宕机,session丢失,用户需要重新登录。

  4. 基于Redis的分布式session

    通过中间件Redis存储session信息,需要session数据只需通过查询Redis即可。

    确保Redis的可用性,还需要主从集群架构,确保Redis高可用。

3. 分布式锁的场景

  1. 系统是一个分布式系统,集群集群,java的锁已经锁不住了。
  2. 操作共享资源,比如库里唯一的用户数据。
  3. 同步访问,即多个进程同时操作共享资源。

4. 分布式锁的实现方案

  • Redis分布式锁
  • 数据库分布式锁
  • Zookeeper分布式锁
4.1 Redis分布式锁

setnx(key,value):如果当前key不存在,设值成功,返回1;如果当前key存在,设值失败,返回0。

expire(key):设置过期时间。

锁流程:

1、 setnx(key,value)加锁。

2、 expire(key)对key设置超时时间,避免死锁问题。

3、 执行流程。

4、del释放锁。

4.2 数据库分布式锁

基于数据库分布式锁有2种实现方案:数据库表的增删、数据库的排他锁

  • 数据库表的增删

    在数据库中维护一张表,每一个方法为唯一标识,进行增删操作,增加成功则为获取锁,执行完成后删除锁;其他线程继续。

  • 数据库的排他锁

    通过for update,对数据加上排他锁,其他线程无法获取锁并被阻塞。

4.3 Zookeeper分布式锁

基于zookeeper临时有序节点实现分布式锁。

https://blog.csdn.net/qq_41432730/article/details/123389670

5. 分布式事务

5.1 概念

相对于本地事务而言,本地事务通过数据库的事务机制就可以保证ACID(原子性、一致性、隔离性、持久性)特性,分布式环境下,涉及多个数据库,分布式事务就是为了保证多个数据库的数据一致性。

分布式事务处理的关键是:1、记录事务在任何节点所做的所有动作 2、事务所有操作要么全部提交、要么全部回滚

5.2 常见实现方案
5.2.1 2PC(两阶段提交)

先说说分布式事务中的XA协议:

XA协议中有三个角色:

  • AP(Applicatoin):应用程序
  • TM(Transaction Manager):事务管理器
  • RM(Resource Manager):资源管理器

XA接口提供资源管理器和事务管理器之间通信的标准接口。

两阶段提交

  • 阶段一:协调者向所有参与者发送预请求,等待参与者在本地执行操作并返回是否可以提交
  • 阶段二:协调者根据参与者的结果,判断是统一提交还是统一回滚。

优点:

​ 实现成本较低,尽量保证了数据强一致性。

缺点:

​ 协调者的地位很重要,需要考虑宕机的风险。

​ 资源管理器不是直接提交,而是同步阻塞。

​ 协调者发送了提交的通知,所有参与者受网络问题可能有数据不一致性的存在。

5.2.2 3PC(三阶段提交)

三阶段提交

  • 阶段一:canCommit;协调者确认所有参与者是否可以执行
  • 阶段二:preCommit;协调者确认参与者可以执行后,发送预请求,参与者在本地执行操作并返回是否可以提交
  • 阶段三:doCommit;协调者根据参与者的结果,判断是统一提交还是统一回滚。

优点:

​ 解决两阶段提交的单体故障和同步阻塞问题。

缺点:

​ 无法保证数据不一致问题。

5.2.3 TCC

TCC:Try Confirm Cancel;是两阶段提交的变种。是业务层面的分布式事务,保证最终一致性

  • Try阶段:尝试执行业务,根据执行结果,决定进入Confirm阶段或是Cancel阶段。
  • Confirm阶段:执行成功,将数据的状态进行更新为成功。
  • Cancel阶段:执行失败,将数据的状态进行更新为失败。

优点:

​ 数据库层的二阶段提交交给应用层实现,规避了数据库二阶段提交的阻塞问题。

缺点:

​ 需要开发成本,对代码的侵入性较大。

5.2.4 本地消息表

核心思想:分布式事务拆分为本地事务进行处理。

添加一张消息表,将新增数据和新增消息放到一个事务内;另外一个线程不断轮训消息表,将消息推送到MQ,另一个服务去消费消息。

实现了数据的最终一致性,需要在业务系统增加一张消息表,多一次消息表的操作,有一定损耗。

5.2.5 MQ消息事务

消息事务的原理是将两个事务通过MQ进行异步解耦。

消息事务依赖于消息中间件的事务消息,只有接收到确认才会正常投递消息。

对比本地消息表减少了消息表的存在,降低数据库操作。

5.2.6 最大努力通知

最大努力通知相比实现会简单一些,适用于一些对最终一致性实时性要求没那么高的业务,比如支付通知,短信通知。

6. 集群与负载均衡的算法与实现

6.1 轮询

将客户端发送到负载均衡器的请求,依次轮流的转发给服务器集群的节点。不需要考虑每个节点的连接数、负载、性能等情况。

优点:

​ 简单,公平

缺点:

​ 无法根据服务器性能分配;无法合理利用服务器资源

6.2 随机

随机把请求分发到可用的服务器上,由概率论的知识可知,随着请求量的变大,随机算法会逐渐演变为轮询算法,即集群各个节点会处理差不多数量的请求。所以优缺点也是与轮询算法类似。

6.3 加权轮询

每个服务器分配好权重,轮询根据分配的权重进行请求的分配。

6.4 加权随机

每个服务器分配好权重,随机根据分配的权重进行请求的分配。

6.5 IP-Hash

通过散列算法将请求分配到不同的服务器上。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/爱喝兽奶帝天荒/article/detail/902475
推荐阅读
相关标签
  

闽ICP备14008679号