1 什么叫做分布式系统，soa架构，微服务架构
最开始的单机系统：一台服务器部署一个单机应用加上一个数据库（数据库和应用可能不在同一个服务器上）就能完成简单的功能需求伴随着业务量增加，单机系统承载不了这么大的压力，开始引入集群的概念，应用采用多个服务器集群部署，数据库独立到单独的服务器上业务开始变得复杂，任何修改都需要对整个集群进行升级改造成本太高，开始引入分布式架构，==应用可以按逻辑处理对象进行类型拆分（文件服务器，应用服务器等），数据库按业务类型拆分，必要时采用主从架构，分库分表，加入各种中间件，逐步降低变动的影响范围，分布式是以缩短单个任务的执行时间来提升效率的，集群是通过提高单位时间内执行的任务数来提升效率的。伴随着系统的复杂性进一步提升，业务越来越复杂，面向服务的架构soa提出，通过业务拆分，把工程拆分成服务层、表现层两个工程，服务层中包含业务逻辑，只需要对外提供服务即可。表现层只需处理和页面的交互，业务逻辑都是调用服务层的服务来实现。 服务层可以按照业务需求进行封装处理，例如在商城系统中，订单服务，记录服务，发布服务等。微服务相比于SOA更加精细，微服务更多的以独立的进程的方式存在，互相之间并无影响； 微服务提供的接口方式更加通用化，例如HTTPRESTful方式，各种终端都可以调用，无关语言、平台限制； 微服务更倾向于分布式去中心化的部署方式，在互联网业务场景下更适合；2 分布式场景下的节点通信方式
httpclient通信（Spring Cloud），mq消息队列
3 分布式缓存（Redis）
4 分布式消息队列（MQ）
5 分布式服务（Dubbo，SpringCloud）
分布式架构衍生技术细节 1 分布式全局唯一ID怎样来实现？
数据库自增；[长度短，自增包含时间先后信息&大小等同于业务量，高并发存在锁竞争的问题，表合并复杂 ] UUID（时间，时钟序列，机器识别号）；[string类型，应用层生成，不涉及数据库&无序，主键顺序存放uuid会产生随机io] Snowflake算法（毫秒内序列squence提升毫秒并发量）;[应用层，有顺序&机器号不好生成 分布式锁：唯一安全&锁竞争问题 ] 通过分布式锁实现全局唯一的ID。
2 分布式session如何实现的
Session Replication 方式管理 (即session复制广播) 简介：将一台机器上的Session数据广播复制到集群中其余机器上 使用场景：机器较少，网络流量较小 优点：实现简单、配置较少、当网络中有机器Down掉时不影响用户访问 缺点：广播式复制到其余机器有一定廷时，带来一定网络开销Session Sticky 方式管理（粘性session，修改session路由规则，session只会在单机处理） 简介：即粘性Session、当用户访问集群中某台机器后，强制指定后续所有请求均落到此机器上 使用场景：机器数适中、对稳定性要求不是非常苛刻 优点：实现简单、配置方便、没有额外网络开销 缺点：网络中有机器Down掉时、用户Session会丢失、容易造成单点故障缓存集中式管理（缓存管理） 简介：将Session存入分布式缓存集群中的某台机器上，当用户访问不同节点时先从缓存中拿Session信息 使用场景：集群中机器数多、网络环境复杂 优点：可靠性好 缺点：实现复杂、稳定性依赖于缓存的稳定性、Session信息放入缓存时要有合理的策略写入3 分布式锁的实现方式你知道有哪些？主流的解决方案是什么？
基于数据库实现（版本号的乐观锁，行级锁的悲观锁，表唯一互斥索引的增删）基于Redis实现（非分布式：基本的key-value增删操作，分布式-Redlock，setnx和watch方法实现）基于ZooKeeper实现（节点目录创建序号临时节点，exist()阻塞等待）zookeeper分布式锁的实现:就在zookeeper上的某个指定节点的目录下，去生成一个唯一的临时有序节点， 然后判断自己是否是这些有序节点中序号最小的一个，如果是，则算是获取了锁。如果不是，则说明没有获取到锁，那么就需要在序列中找到比自己小的那个节 点，并对其调用exist()方法，对其注册事件监听，当监听到这个节点被删除了，那就再去判断一次自己当初创建的节点是否变成了序列中最小的。如果是，则获取锁，如果不是，则重复上述步骤。当释放锁的时候，只需将这个临时节点删除即可。
数据库分布式锁实现原理 最简单的方式可能就是直接创建一张锁表，然后通过操作该表中的数据来实现了。 当我们要锁住某个方法或资源时，我们就在该表中增加一条记录，想要释放锁的时候就删除这条记录。 例如： insert into methodLock(method_name,desc) values (‘method_name’,‘desc’) 【获得锁】 delete from methodLock where method_name =‘method_name’【释放锁】 method_name字段需要加唯一性约束，确保存在多个请求时只有一个操作可以成功
3 PAXOS协议和ZAB协议
4 分布式事务一致性解决方案 两阶段提交(减少不一致产生的时间)
事务工作的时候分为两个阶段，一个是curd执行阶段[prepare阶段]，另一个则是commit阶段【commit阶段】，通常执行阶段的时长会远远大于commit阶段，两阶段提交就是把一致性冲突的产生范围压缩到commit阶段，要求所有事务在curd完成时候才能分别进行事务的提交。 缺点：
同步阻塞问题，curd阶段会锁定数据库资源，事务未提交前资源都是被锁住的，导致并发量低，性能差。单点故障，协调者故障会导致资源无法释放问题。数据不一致，二阶段协调者向参与者分发commit命令不完全导致参与者部分完成提交。同理参与者故障也会导致数据的不一致。三阶段提交(解决二阶段资源被锁死的问题)
分为三个阶段，canCommit[判断是否可以提交事务]，preCommit[执行事务], do Commit[执行提交] 若参与者接收协调者命令超时的时候会直接执行commit命令。 保证第三阶段各个参与者状态的一致性，第一个阶段相当于投票阶段，投票结果直接影响到第三阶段执行提交还是取消的命令选择，当第三阶段产生协调者失忆的时候，再重新选举后仍能得到最终需要执行的命令，该决议已经在第一阶段产生。
缺点：
最后一步依然存在一致性问题_TCC编程模式
通过代码人为实现了两阶段提交，不同的业务场景所写的代码都不一样，复杂度也不一样，因此，这种模式并不能很好地被复用。将整个业务逻辑分为三块：Try、Confirm和Cancel三个操作。
扩展问题 1 分布式系统怎么做服务治理 Dubbo/Spring Cloud
2 有哪些负载均衡算法 ◎ 依序Round Robin 轮询 ◎ 比重Weighted Round Robin ◎ 流量比例Traffic ◎ 使用者端User ◎ 应用类别Application ◎ 联机数量Session ◎ 服务类别Service ◎ 自动分配Auto Mode
