这里是参考B站上的大佬做的面试题笔记。大家也可以去看视频讲解!!!
文章目录
- 1、分布式架构下,Session共享有什么方案
- 2、简述你对RPC、RMI的理解
- 3、分布式id生成方案
- 4、分布式锁解决方案
- 5、分布式事务解决方案
1、分布式架构下,Session共享有什么方案
1、采用无服务状态,抛弃session
2、存入cookie(有安全风险)
3、服务器之间进行session同步,这样可以保证每个服务器上都有全部的session信息,不过当服务器数量比较多的时候,同步是会有延迟甚至同步失败;
4、IP绑定策略
使用Nginx(或其他复杂负载均衡硬件)中的IP绑定策略,同一个IP只能在指定的同一个机器访问,但是这样做失去了负载均衡的意义,当挂掉一台服务器的时候,会影响一批用户的使用,风险很大;
5、使用Redis存储
把Session放到Redis中存储,虽然架构上变得复杂,并且访问需要多访问一次Redis,但是这种方案带来的好处也是很大的:
- 实现了session共享
- 可以水平扩展(增加Redis服务器)
- 服务器重启Session不丢失(不过也要注意Session在Redis中的刷新/失效机制);
- 不仅可以跨服务器Session共享,甚至可以跨平台(例如网页端和APP端)
2、简述你对RPC、RMI的理解
RPC:在本地调用远程的函数,远程过程调用,可以跨语言实现, httpClient
RMI:远程方法调用,java中用于实现RPC的一种机制,RPC的java版本,是J2EE的网路调用机制,跨JVM调用对象的方法,面向对象的思维方式
直接或间接实现接口 java.rmi.Remove 成为存在于服务端的远程对象,供客户端访问并提供一顶的服务
远程对象必须实现java.rmi.server.UniCastRemoteObject类,这样才能保证客户端访问获得远程对象时,该远程对象将会把自身的一个拷贝以Socket的形式传输给客户端。此时客户端所获得的这个拷贝称为”存根“,而服务器端本身已存在的远程对象则称之为”骨架“,其实此时的存根是客户端的一个代理,用于服务器端的通信,而骨架也可以认位是服务器端的一个代理,用于接收客户端的请求之后调用远程方法来响应客户端的请求。
3、分布式id生成方案
uuid
- 1、当前日期和时间 时间戳
- 时钟序列。 计数器
- 全局唯一的IEEE机器识别号,如果有网卡,从网卡MAC地址获得,没有网卡以其他方式获得。
优点:代码简单,性能好(本地生成,没有网络消耗),保证唯一(相对而言,重复概率极低可以忽略)
缺点:
- 每次生成的ID都是无序的,而且不是全数字,且无法保证趋势递增
- UUID生成的是字符串,字符串存储性能差,查询效率慢,写的时候由于不能产生顺序的append操作,需要进行insert操作,导致频繁的页分裂,这种操作在记录占用空间比较大的情况下,性能下降比较大,还会增加读取磁盘次数
- UUID长度过长,不适用于存储,耗费数据库性能。
- ID无一定业务含义,可读性差。
- 有信息安全问题,有可能泄漏mac地址
数据库自增序列
单机模式:
优点:
- 实现简单,依靠数据库即可,成本小。
- ID数字化,单调自增,满足数据库存储和查询性能。
- 具有一定的业务可读性。(结合业务code)
缺点:
- 强依赖DB,存在单点问题,如果数据库宕机,则业务不可用。
- DB生成ID性能有限,单点数据库压力大,无法抗高并发场景。
- 信息安全问题,比如暴露订单量,url查询改一下id查到别人的订单
数据库高可用:多主模式做负载,基于序列的起始值和步长设置,不同的初始值,相同的步长,步长大于节点数。
优点:解决了ID生成的单点问题,同时平衡了负载。
缺点:
- 系统扩容困难:系统定义好步长之后,增加机器之后调整步长困难。
- 数据库压力大:每次获取一个ID都必须读写一次数据库。
- 主从同步的时候,电商下单---->支付insert master db select 数据,因为数据同步延迟导致查不到这个数据。加cache(不是最好的解决方式)数据要求比较严谨的话查master主库
leaf-sagmnet
-采用每次获取一个ID区间段的方式来解决,区间段用完之后再去数据库获取新的号段,这样一来就可以大大减轻数据库的压力
核心字段:biz_tag, max_id ,step
biz_tag用来区分业务,max_id表示该biz_tag目前所被分配的ID号段的最大值,step表示每次分配的号段长度,原来每次获取ID都需要访问数据库,现在只需要把Step设置的足够合理如1000,那么现在可以在1000个ID用完之后再去访问数据库
优点:
- 扩展灵活,性能强能撑起大部分业务场景。
- ID号码是趋势递增的,满足数据库存储和查询性能要求
- 可用性高,即使ID生成服务器不可用,也能够使得业务在短时间内可用,为排查问题争取时间。
缺点:
- 可能存在多个节点同时请求ID区间的情况,依赖DB
对buffer:将获取一个号段的方式优化成获取两个号段,在一个号段用完之后不用立马去更新号段,还有一个缓存号段备用,这样能够有效解决这种冲突问题,而且采用双buffer的方式,在当前号段消耗了10%的时候就去检查下一个号段有没有准备好,如果没有准备好就去更新下一个号段,当前号段用完了就切换到下一个已经缓存好的号段去使用,同时在下一个号段消耗到10%的时候,又去检测下一个号段有没有准备好,如此往复。
优点:
- 基于JVM存储双buffer的号段,减少了数据库查询,减少了网络依赖,效率更高。
缺点
segment号段长度是固定的,业务量大时可能会频繁更新号段,因为原本分配的号段会一下用完,如果号段长度设置的过长,但凡缓存中有号段没有消耗完,其他节点重新获取的号段与之前相比可能跨度会很大,动态调整Step
基于redis、mongodb、zk等中间件生成
雪花算法:
生成一个64bit的整性数字
第一位符号位固定为0,41位时间戳,10位workid,12位序列号
位数可以有不同实现
优点
- 每个毫秒值包含的ID值很大,不够可以变动位数来增加,性能佳(依赖workId的实现)。
- 时间戳值在高位,中间是固定的机器码,自增的序列在低位,整个ID是趋势递增的。
- 能够根据业务场景数据库节点布置灵活挑战bit位划分,灵活度高。
缺点
- 强依赖于机器时钟,如果时钟回拨,会导致重复的ID生成,所以一般基于此的算法发现时钟回拨,都会抛异常处理,阻止ID生成,这可能导致服务不可用。
4、分布式锁解决方案
需要这个锁独立于每一个服务之外,而不是在服务里面。
数据库:利用主键冲突控制一次只有一个线程能获取锁,非阻塞、不可重入、单点、失效时间
Zookeeper分布式锁:
zk通过临时节点,解决了死锁的问题,一旦客户端获取到锁之后突然挂掉(Session连接断开),那么这个临时节点就会自动删除,其他客户端自动获取锁。临时顺序节点解决惊群效应。
Redis分布式锁:setNX,单线程处理网络请求,不需要考虑并发安全性
所有服务节点设置相同的key,返回为0,则锁获取失败
setnx问题:
- 1、早期版本没有超时参数,需要单独设置,存在死锁问题(中途宕机)
- 2、后期版本提供加锁与设置原子性操作,但是存在任务超时,锁自动释放,导致并发问题,加锁与释放锁不是同一线程问题。
删除锁:判断线程唯一标志,再删除
可重入性及锁续期没有 实现,通过redisson解决(类似AQS的实现,看门狗机制)
redlock:意思的机制都只操作单节点、即使Redis通过sentinel保证高可用,如果这个master节点由于某些原因发生了主从切换,那么就会出现锁丢失的情况(redis同步设置可能数据丢失)。redlock从多个节点申请锁,当一半以上节点获取成功,锁才算获取成功,redission有相应的实现。
5、分布式事务解决方案
XA规范:分布式事务规范,定义了分布式事务模型
四个角色:事务管理器(协调者TM)、资源管理器(参与者RM)、应用程序AP、通信资源管理器CRM
全局事务:一个横跨多个数据库的事务,要么全部提交、要么全部回滚
JTA事务时java对XA规范的实现,对应JDBC的单库事务。
两阶段协议:
第一阶段(prepare):每个参与者执行本地事务但不提交,进入ready状态,并通知协调者已经准备就绪。
第二阶段(commit)当协调者确认每个参与者都read后,通知参与者进行commit操作,如果有参与者fail,则发送rollback指令,各参与者做回滚。
问题:
- 单点故障:一旦事务管理器出现故障,整个系统不可用(参与者都会阻塞住)
- 数据不一致:在阶段二,如果事务管理器只发送了部分commit消息,此时网络发生异常,那么只有部分参与者接收到commit信息,也就是说只有部分参与者提交了事务,使得系统数据不一致。
- 响应时间较长:参与者和协调者资源都被锁住,提交或者回滚之后才能释放
- 不确定性:当协调者管理器发送commit之后,并且此时只有一个参与者收到了commit,那么当该参与者与事务管理器同时宕机之后,重新选举的事务管理器无法确定该条消息是否提交成功。
三阶段协议:主要是针对两阶段的优化,解决了2PC单点故障的问题,但是性能问题和不一致问题仍然没有根本解决
引入了超时机制解决参与者阻塞的问题,超时后本地提交,2pc只有协调者有超时机制
第一阶段:CanCommit阶段,协调者询问事务参与者,是否有能力完成此次事务。
如果都返回yes,则进入第二阶段
有一个返回no或等待响应超时,则中断事务,并向所有参与者发送abort请求第二阶段:precommit阶段,此时协调者会向所有的参与者发送precommit请求,参与者收到后开始执行事务操作。参与者执行完事务操作后(此时属于未提交事务的状态),就会向协调者反馈”Ack“表示我已经准备好提交了,并等待协调者的下一步指令。
第三阶段:DoCommit阶段,在阶段二中如果所有的参与者节点都返回Ack,那么协调者就会从”预提交状态“转变为”提交状态“。然后向所有的参与者节点发送”doCommit"请求,参与者节点在收到提交请求后就会各自执行事务提交操作,并向协调者节点反馈“Ack”消息,协调者收到所有参与者的Ack消息后完成事务。相反,如果有一个参与者节点未完成PreCommit的反馈或者反馈超时,那么协调者都会向所有的参与者节点发送abort请求,从而中断事务。
TCC(补偿事务):Try、Confirm、Cancel
- 针对每个操作,都要注册一个与其对应的确认和补偿(撤销)操作
Try操作做业务检查及资源预留,Confirm做业务确认,Cancel实现一个与Try相反的操作既回滚操作。TM首先发起所有的分支事务的try操作,任何一个分支事务的try操作执行失败,TM将会发起所有分支事务的Cancel操作,若try操作全部成功,TM将会发起所有分支事务的Confirm操作,其中Confirm/Cancel操作若执行失败,TM会进行重试。
TCC模型对业务的侵入性较强,改造的难度较大,每个操作都需要try、confirm、cancel三个接口实现confirm和cancel接口还必须实现幂等性。
消息队列的事务信息:
- 发送prepare消息到消息中间件
- 发送成功后,执行本地事务
如果事务执行成功,则commit,消息中间件将消息下发至消费端(commit前,消息不会被消费)
如果事务执行失败,则回滚,消息中间件将这条prepare消息删除 - 消费端接收到消息进行消费,如果消费失败,则不断重试