分布式领域

分布式领域

1、什么是分布式ID

在分布式系统中，经常需要一些全局唯一的ID对数据、消息、http请求等进行唯一标识。那么这个全局唯一ID就叫分布式ID
​
哪些解决方案：UUID，数据库主键自增，Redis，Zookeeper，数据库分段+服务缓存ID，雪花算法Snowflake

2、为什么需要分布式ID

1.如果id我们使用的是数据库的自增长类型，在分布式系统中需要分库和分表时，会有两个相同的表，有可能产生主键冲突。
​
2.电商订单号，采用自增方式，是最简单的生成规则。但是!这种与流水号相同的订单号很容易就被竞争对手看出你公司真实的运营信息。

3、分布式ID需要满足哪些条件

全局唯一：必须保证ID是全局性唯一的
​
高性能：高可用低延时，ID生成响应要快，否则会成为业务瓶颈
​
高可用：100%的可用性是骗人的，但是也要无限接近于100%的可用性
​
好接入：要秉着拿来即用的设计原则，在系统设计和实现上要尽可能的简单
​
趋势递增：最好趋势递增，这个要求就得看具体业务场景了，一般不严格要求
​
安全性：如果ID连续生成，势必会泄露业务信息，甚至可能被猜出，所以需要无规则不规则。
​
易读性：不要太长，想象一下用户在售后的时候本身就处在一个焦躁的心情中，再让他报/输一个很长的订单号，很容易造成错误率高，这个时候只能烦上加烦。如果订单号实在太长，还有一种办法：断句。
​
可扩展性：淘宝的订单号在最初的时候也还是12位、14位，现在已经变成16位了，随着一个网站的交易量逐年上升，订单号不可避免的会变长。

4、为什么要使用分布式锁

为了保证一个方法或属性在高并发情况下的同一时间只能被同一个线程执行，在传统单体应用单机部署的情况下，可以使用Java并发处理相关的API(如ReentrantLock或Synchronized)进行互斥控制。在单机环境中，Java中提供了很多并发处理相关的API。但是，随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的Java API并不能提供分布式锁的能力。
​
为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！

5、分布式锁应该具备哪些条件

1、在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行； 
2、高可用的获取锁与释放锁； 
3、高性能的获取锁与释放锁； 
4、具备可重入特性； 
5、具备锁失效机制，防止死锁； 
6、具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败。

6、分布式锁的三种实现方式

基于数据库实现分布式锁； 
基于缓存（Redis等）实现分布式锁； 
基于Zookeeper实现分布式锁；
​
​
上面几种方式，哪种方式都无法做到完美。就像CAP一样，在复杂性、可靠性、性能等方面无法同时满足，所以，根据不同的应用场景选择最适合自己的才是王道。
​
从理解的难易程度角度（从低到高）
​
数据库 > 缓存 > Zookeeper
​
从实现的复杂性角度（从低到高）
​
Zookeeper >= 缓存 > 数据库
​
从性能角度（从高到低）
​
缓存 > Zookeeper >= 数据库
​
从可靠性角度（从高到低）
​
Zookeeper > 缓存 > 数据库

7、分布式事务原理及解决方案

1.分布式事务产生的背景
根据业务需求需要对业务进行拆分,例如将一个大应用拆分成用户模块,订单模块,商品模块,每个模块都有自己的数据库,在用户购买商品的时候需要扣减商品模块库存,在订单模块添加订单数据,这时候需要保证这两个数据库 *** 作在同一个事务中完成,因此就出现了分布式事务
​
2.什么是分布式事务
分布式事务用于在分布式系统中保证不同节点之间的数据一致性。分布式事务的实现有很多种，最具有代表性的是由Oracle Tuxedo系统提出的XA分布式事务协议。
XA协议包含两阶段提交（2PC）和三阶段提交（3PC）两种实现
​
​
一般来说，分布式事务的实现主要有以下 5 种方案：
​
XA 方案
TCC 方案
本地消息表
可靠消息最终一致性方案
最大努力通知方案
​
1.XA三阶段提交
XA三阶段提交在两阶段提交的基础上增加了CanCommit阶段，并且引入了超时机制。一旦事物参与者迟迟没有接到协调者的commit请求，会自动进行本地commit。这样有效解决了协调者单点故障的问题。但是性能问题和不一致的问题仍然没有根本解决。
​
2.MQ事务
利用消息中间件来异步完成事务的后一半更新，实现系统的最终一致性。这个方式避免了像XA协议那样的性能问题。
​
3.TCC事务
TCC事务是Try、Commit、Cancel三种指令的缩写，其逻辑模式类似于XA两阶段提交，但是实现方式是在代码层面来人为实现。

8、Zookeeper的Leader（领导者）选举流程

一、 服务器启动时期的Leader选举
假设想在的有三台机器搭建集群，在集群初始化阶段，当只有一个服务器（Server1）启动时，无法完成Leader的选举；当第二台服务器（Server2）启动后，两台机器开始互相通信，每台机器都会尝试去选举Leader，于是进入了Leader选举过程，这个过程大概如下：
​
1.每个Server发出一个投票投给自己。在初始情况下，Server1和Server2都会将自己作为Leader，将票投给自己。每次投票会包含所推举的服务器的myid和ZXID，使用（myid，ZXID）来表示，此时Server1的投票为(1, 0)，Server2的投票为(2, 0)，然后各自将这个投票发给集群中的其他机器；
2.接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票是否有效，如检查是否是本轮投票、是否来自LOOKING状态的服务器；
3.处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK，PK的规则如下：
对于Server1而言，它的投票是(1, 0)，接收Server2的投票为(2, 0)，首先会比较两者的ZXID，均为0，再比较myid，此时Server2的myid最大，于是更新自己的投票为(2, 0)，然后重新投票，对于Server2而言，其无须更新自己的投票，只是再次向集群中所有机器发出上一次投票信息即可。
    1.优先检查ZXID。ZXID比较大的服务器优先作为Leader；
    2.如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器。
4.统计投票。每次投票后，服务器都会统计投票信息，判断是否已经过半机器接收到相同的投票信息，对于Server1、Server2而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出了Leader。
5.改变服务器状态。一旦确定了Leader，每个服务器都会更新自己的状态，如果是Follower，那么就变更为FOLLOWING，如果是Leader，就变更为LEADING。
​
二、 服务器运行期间的 Leader 选举
在Zookeeper运行期间，即便有新服务器加入，也不会影响到Leader，新加入的服务器会将原有的Leader服务器视为Leader，进行同步。但是一旦Leader宕机了，那么整个集群就将暂停对外服务，进行新一轮Leader的选举，其过程和启动时期的Leader选举过程基本一致。假设正在运行的有Server1、Server2、Server3三台服务器，当前Leader是Server2，若某一时刻Leader挂了，此时便开始Leader选举。选举过程如下：
​
1.变更状态。Leader宕机后，余下的非Observer服务器都会将自己的服务器状态变更为LOOKING，然后开始进行Leader选举流程；
2.每个Server会发出一个投票。在这个过程中，需要生成投票信息(myid,ZXID)每个服务器上的ZXID可能不同，我们假定Server1的ZXID为123，而Server3的ZXID为   122；在第一轮投票中，Server1和Server3都会投自己，产生投票(1, 123)，(3, 122)，然后各自将投票发送给集群中所有机器；
接收来自各个服务器的投票。与启动时过程相同；
3.处理投票；
4.统计投票；
5.改变服务器的状态。

9、Dubbo 的架构设计

各层说明：
​
Config配置层：对外配置接口，以ServiceConfig、ReferenceConfig为中心，可以直接初始化配置类，也可以通过Spring解析配置生成配置类。
​
Proxy服务代理层：服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory。
​
Registry注册中心层：封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory、Registry、RegistryService。
​
Cluster路由层：封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为Cluster、Directory、Router、LoadBalance。
​
Monitor监控层：RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory、Monitor、MonitorService。
​
Protocol远程调用层：封将RPC调用，以Invocation、Result为中心，扩展接口为Protocol、Invoker、Exporter。
​
Exchange信息交换层：封装请求响应模式，同步转异步，以Request、Response为中心，扩展接口为Exchanger、ExchangeChannel、ExchangeClient、ExchangeServer。
​
Transport网络传输层：抽象MINA和Netty为统一接口，以Message为中心，扩展接口为Channel、Transporter、Client、Server、Codec。
​
Serialize数据序列化层：可复用的一些工具，扩展接口为Serialization、ObjectInput、ObjectOutput、ThreadPool。
​
​