JAVA面试备战--服务架构篇

一、熔断限流算法

1. 计数器算法

计数器算法，是指在指定的时间周期内累加访问次数，达到设定的阈值，触发限流策略。下一个时间周期进行访问时，访问次数清零。此算法无论在单机还是分布式环境下实现都非常简单，使用redis的incr原则自增性，再结合key的过期时间，即可轻松实现。
优点
简单。。代码实现简单方便。。。
缺点
存在临界值问题，比如在0:00到1:00内，只在0:50有60个请求，而在1:00到2:00之间，只在1:10有60个请求，虽然在两个一分钟的时间内，都没有超过100个请求，但是在0:50到1:10这20秒内，确有120个请求，虽然在每个周期内，都没有超过阈值，但是在这20秒内，已经远远超过了我们原来设置的1分钟内100个请求的阈值。

2. 滑动时间窗口算法

为了解决计数器算法临界值的问题发明的。
滑动时间窗口是将计数器算法中的实际周期切分成多个小的时间窗口，分别在每个小的时间窗口中记录访问次数，然后根据时间将窗口往前华东并删除过期的小时间窗口。最终只需要统计滑动窗口范围内的小时间窗口的总请求数即可。
在滑动时间窗口算法中，我们的小窗口划分的越多，滑动窗口的滚动越平滑，限流的统计就会越精确。
优点
解决了计数器算法的临界值问题。。。
缺点
时间区间精度越高，算法所需的空间容量就越大

3. 漏桶限流算法

漏桶算法的原理就想它的名字一样，它有恒定的流出速度，不管水流流入的速度有多快，漏斗出水的速度始终保持不变，类似于消息中间件，不管消息的生产者请求量有多大，消息的处理能力取决于消费者。
将每个请求视作水滴放入漏桶中进行存储，漏桶以固定的速率向外漏出请求来执行，如果漏桶空了则停止漏水，如果漏桶满了则多余的请求会被直接丢弃。

优点
漏桶算法多使用队列实现，服务的请求会存到队列中，服务的提供方则按照固定的速率从过往队列中取出请求并执行，过多的请求则放在队列中排队或者直接拒绝
缺点
当短时间内有大量的突发请求时，即便此时服务器没有任何负载，每个请求也都得在队列中等待一段时间才被响应。

4. 令牌桶算法

令牌以固定速率生成，生成的令牌放入令牌桶中，如果令牌满了则多余的令牌会直接丢弃，当请求到达时，会尝试从令牌桶中取令牌，取到了令牌的请求可以执行，如果桶空了，那么尝试取令牌的请求会被直接丢弃。

优点
既能够将所有的请求平均分不到时间区间内，又能接受服务器能够承受范围内的突发请求，因此是目前使用较为广泛的一种限流算法
缺点
会牺牲小部分流量

二、微服务设计有哪些准则

1. 单一职责原则：让每个服务能独立，有界限的工作，每个服务只关注自己的业务。做到高内聚
2. 服务自治原则：每个服务要能做到独立开发、独立测试、独立构建、独立部署、独立运行。与其他服务解耦
3. 轻量级通信原则：让每个服务之间的调用是轻量级，并且能够跨平台、跨语言。
4. 粒度进化原则：对每个服务的粒度把控，其实没有统一的标准，这个得结合我们解决的具体业务问题，不要过度设计。服务的粒度随着业务和用户的发展而发展。

软件系统是为了业务服务的，好的系统不是设计出来的，是进化出来的。

三、CAP与BASE理论

1. CAP

• C：一致性（Consistency），数据在多个副本节点中保持一致，可以理解成两个用户访问两个系统A和B，当A系统数据有变化时，及时同步给B系统，让两个用户看到的数据是一致的。
• A：可用性（Availableility），系统对外提供服务必须一致处于可用状态，在任何故障下，客户端都能在合理时间内获得服务端非错误的响应。
• P：分区容错性（Partition tolerance），在分布式系统中遇到任何网络分区故障，系统仍然能对外提供服务。网络分区，可以这样理解，在分布式系统中，不同的节点分布在不同的子网络中，有可能子网络中只有一个节点，在所有网络正常的情况下，由于某些原因导致这些子节点之间的网络出现故障，造成整个节点环境被切分成了不同的独立区域，这就是网络分区。
  CAP定理：指的是在一个分布式系统中最多只能同时满足CAP三项中的两项，一般是CP或者AP。
  为什么只能满足两个？
  存在网络调用的情况下，网络总是不可靠的

1. 当网络发生故障时，系统A和系统B没法进行数据同步，也就是我们不满足P，同时两个系统依然可以访问，那么此时其实相当于是单机系统，就不是分布式系统了，所以只要是分布式系统，P必须满足
2. 当P满足时，如果用户1通过系统A对数据进行了修改，也要让用户2通过系统B能正确拿到修改后的数据，那么此时是满足C，就必须等待网络将系统A和系统B的数据同步好，兵器在同步期间，任何人不能访问系统B，否则数据就是不一致的。此时满足的是CP
3. 当P满足时，如果用户1通过系统A对数据进行了修改，也要让系统B能继续提供服务，那么此时，只能接受系统A没有及时将数据同步给系统B。此时满足的就是AP。
   简单来说，保证数据一致性，那么服务就存在短时间中断的情况，保持系统高可用，那么数据就做不到系统之间及时同步。

2. BASE理论

BASE理论并没有要求数据的强一致性，而是允许数据在一定的时间段内是不一致的，但在最终某个状态会达到一直，也就是最终一致性。

• Basically Available（基本可用）：分布式系统在出现不可预知的故障时，允许损失部分可用性，保证核心功能的可用。
• Soft state（软状态）：软状态也称为弱状态，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时
• Eventually consistent（最终一致性）：最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态，因此，最终一致性的本质是需要系统保证最终数据能够达到一直，而不需要实时保证系统数据的强一致性

四、2PC与3PC

1. 2PC二阶段提交

分为准备阶段（投票）和提交阶段（执行阶段）：参与者将操作成败通知给协调者，再由协调者根据所有参与者的反馈情况决定各参与者是否要提交操作还是中止操作。

• 准备阶段-prepare阶段

1. 协调者向所有参与者节点询问是否可以执行提交操作，并开始等待各个参与者节点的响应
2. 参与者各节点执行事务操作，并将undo信息和redo信息写入日志
3. 各个参与者节点响应协调者发起的询问，如果所有参与者节点的事务操作实际执行成功，则它返回一个同意信息，如果参与者节点的事务执行失败，返回一个中止信息

• 提交/回滚阶段

协调者收到参与者的失败消息或者超时，直接给每个参与者发送回滚消息，否则发送提交消息。
参与者根据协调者的信息，执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。

缺点

1. 同步阻塞问题，执行过程中，所有参与者节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。（准备阶段，只执行sql，而不提交，并且占用数据库连接资源）
2. 单点故障，由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者都处于锁定事务资源的状态中，而无法继续完成事务操作。
3. 数据不一致，在二阶段提交的第二阶段中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这会导致只有一部分参与者接收到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。会出现数据不一致的现象。
4. 协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者也宕机了，那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否已经提交。

2. 3PC三阶段提交

can commit===>pre commit==>do commit

1. 3pc比2pc多可了一个can commit阶段，减少了不必要的资源浪费。2pc第一阶段会占用资源，而3pc在这个阶段不占用资源，只是校验一下sql。减少资源占用
2. 引入超时机制，同时在协调者和参与者中都引入超时机制
   2pc：只有协调者有超时机制，超时后，发送回滚指令
   3pc：协调者和参与者都有超时机制：协调者超时：can commit；pre commit。如果收不到参与者的反馈，则协调者向参与者发送中断指令；参与者超时：pre commit阶段，参与者进行中断；do commit阶段，参与者进行提交。