分布式与微服务基础知识(面试)

1.网关SpringCloud gateway

负责鉴权和转发服务

2.Eureka

负责服务注册和发现

Eureka是什么
Eureka是Netflix开发的服务发现和服务注册框架，本身是一个基于REST的中间层服务，以达到负载均衡和中间层服务故障转移的目的。

服务发现和服务注册：
Eureka是通过c/s模式开发的，提供了server端和client 端，client 端，需要向Eureka注册自己信息。之后要通过发送心跳来进行服务续约。

服务续约（心跳机制）:
当服务启动并成功注册到Eureka服务器后，Eureka客户端会默认以每隔30秒的频率向Eureka服务器发送一次心跳，避免自己的注册信息被Eureka服务器剔除。

服务下线：
当服务进行正常关闭操作时，它会触发一个服务下线的REST请求给Eureka Server，服务中心接受到请求之后，将该服务置为下线状态。

服务失效剔除：
有时我们的服务可能由于内存溢出或网络故障等原因使得服务不能正常的工作，而服务注册中心并未收到“服务下线”的请求。相对于服务提供者的“服务续约”操作，服务注册中心在启动时会创建一个定时任务，默认每隔一段时间 (默认为60秒)将当前清单中超时(默认为90秒)没有续约的服务剔除，这个操作被称为失效剔除。

自我保护机制：
Eureka服务端会检查最近15分钟内所有Eureka 实例正常心跳占比，如果低于85%就会触发自我保护机制。触发了保护机制，Eureka将暂时把这些失效的服务保护起来，不让其过期，但这些服务也并不是永远不会过期。Eureka在自我保护机制启动完成后，每隔60秒会检查一次服务健康状态，如果这些被保护起来失效的服务过一段时间后（默认90秒）还是没有恢复，就会把这些服务剔除。如果在此期间服务恢复了并且实例心跳占比高于85%时，就会自动关闭自我保护机制。

Eureka 遵守 AP原则（服务可用性和分区容错性）
Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作。只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查的信息可能不最新的不保证强一致性.同时eureka使用自我保护机制保证分区容错性。

3.Zookeeper

满足分区容错性和一致性
当发生双leader情况下，会产生脑裂现象
一致性是要求只有一组最高版本的服务提供服务，否则只能读，无法写

4.cap算法

一个分布式系统最多只能同时满足 一致性（Consistency），可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

(1)一致性（Consistency）
一致性（Consistency），说的是每一个更新成功后，分布式系统中的所有节点，都能读到最新的信息。即所有节点相当于访问同一份内容，这样的系统就被认为是强一致性的。
(2)可用性（Availability）
可用性（Availability），是每一个请求，都能得到响应。请求只需要在一定时间内返回即可，结果可以是成功或者失败，也不需要确保返回的是最新版本的信息。
(3)分区容错性（Partition tolerance）
分区容错性（Partition tolerance），是说在网络中断，消息丢失的情况下，系统照样能够工作。这里的网络分区是指由于某种原因，网络被分成若干个孤立的区域，而区域之间互不相通

分布式一致性算法
(1)Raxos 算法（少数服从多数）
解决的问题：在一个可能发生异常的分布式系统中如何就某个值达成一致，让整个集群的节点对某个值的变更达成一致
任何一个节点都可以提出要修改某个数据的提案,是否通过这个提案取决于这个集群中是否有超过半数的节点同意（所以节点数总是单数）—— 版本标记。如果不超过半数的节点同意是无法选举出新的节点的，保证版本高，同时是强一致性。也就是说收到超过一半的最大版本的提案才算成功。
(2)Raft 算法（少数服从多数）
Raft 算法也是一种少数服从多数的算法，在任何时候一个服务器可以扮演以下角色之一：
Leader：负责 Client 交互 和 log 复制，同一时刻系统中最多存在一个
Follower：被动响应请求 RPC，从不主动发起请求 RPC
Candidate : 由Follower 向Leader转换的中间状态

5.分布式锁

(1)什么是分布式锁
分布式锁其实就是，控制分布式系统不同进程共同访问共享资源的一种锁的实现。如果不同的系统或同一个系统的不同主机之间共享了某个临界资源，往往需要互斥来防止彼此干扰，以保证一致性。

(2)分布式锁的应用
在分布式锁方面, Redis有广泛应用， 日常开发中分布式锁的一些常见常见有秒杀下单、抢红包等等。

(3)分布式锁的特点
互斥性：和我们本地锁一样互斥性是最基本，但是分布式锁需要保证在不同节点的不同线程的互斥。
可重入性：同一个节点上的同一个线程如果获取了锁之后那么也可以再次获取这个锁。
锁超时：和本地锁一样支持锁超时，防止死锁。
高效，高可用：加锁和解锁需要高效，同时也需要保证高可用防止分布式锁失效，可以增加降级。
支持阻塞和非阻塞：和 ReentrantLock 一样支持 lock 和 trylock 以及 tryLock(long timeOut)。
支持公平锁和非公平锁(可选)：公平锁的意思是按照请求加锁的顺序获得锁，非公平锁就相反是无序的。这个一般来说实现的比较少。

(4)分布式锁的方案
一些比较常见的分布式锁方案
使用redis实现分布式锁：
SETNX:设置锁
EXPIRE:设置过期时间
常用：
SETNX + EXPIRE：加锁的同时，加上过期时间

SET EX PX NX + 校验唯一随机值,再释放锁
多机实现的分布式锁Redlock

使用数据库实现分布式锁：
悲观锁和乐观锁

ZooKeeper实现分布式锁:
ZooKeeper是一个为分布式应用提供一致性服务的开源组件，它内部是一个分层的文件系统目录树结构，规定同一个目录下只能有一个唯一文件名。基于ZooKeeper实现分布式锁的步骤如下：
（1）创建一个目录mylock；
（2）线程A想获取锁就在mylock目录下创建临时顺序节点；
（3）获取mylock目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在，则说明当前线程顺序号最小，获得锁；
（4）线程B获取所有节点，判断自己不是最小节点，设置监听比自己次小的节点；
（5）线程A处理完，删除自己的节点，线程B监听到变更事件，判断自己是不是最小的节点，如果是则获得锁。

6.服务之间的异步业务

场景：一个服务调用两个服务去做事情，一个服务要去发邮件，一个是服务要去拿数据
方案：可以使用消息总线的方式，异步处理两个的结果，如果邮件失败了，就重新重传，不影响另一个服务拿数据

7.如何保证数据库和redis数据一致性

大前提：

• 如果要求强一致性，就不要使用redis，使用redis代表可以接受最终一致性
• 使用redis作为缓存，必须设置过期时间，原因: 即使程序有问题，不能保证redis的最终一致性，key也会自己失效
  最优方案延迟双删：
  当A服务需要写入数据时，先删除redis，然后去更新数据，然后再延迟写入redis的时间大概3～5秒，延迟时间应该大于一次写入redis 的时间，为了避免服务B在写入时被删除的问题，在A时间片结束后，删除，服务B在读取的时候就是新的数据了

要求强一致性的话：需要加同步锁来操作，在写更新时阻塞读操作