分布式系统遇到的挑战
1.说一下CAP理论：
CAP 理论告诉我们，一个分布式系统不可能同时满足一致性（C:Consistency)，可用性（A: Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中的2个。
C（Consistence）一致性 指数据在多个副本之间能够保持一致的特性（严格的一致性）
A（Availability）可用性 指系统提供的服务必须一直处于可用的状态，每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据
P（Network partitioning）分区容错性分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障
什么是分区？
在分布式系统中，不同的节点分布在不同的子网络中，由于一些特殊的原因，这些子节点之间出现了网络不通的状态，但他们的内部子网络是正常的。从而导致了整个系统的环境被切分成了若干个孤立的区域。这就是分区。
2.什么是BASE理论
BASE：全称：Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（最终一致性）三个短语的缩写，来自 ebay 的架构师提出。
Base 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于 CAP 定理逐步演化而来的。其核心思想是：
既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
1、Basically Available(基本可用)
什么是基本可用呢？假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言：
1、响应时间上的损失：正常情况下的搜索引擎 0.5 秒即返回给用户结果，而基本可用的搜索引擎可以在 1 秒作用返回结果。
2、功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单，但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
2、Soft state（软状态）
什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种 “硬状态”。
软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
3、Eventually consistent（最终一致性）
这个比较好理解了哈。
上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性。从而达到数据的最终一致性。这个时间期限取决于网络延时，系统负载，数据复制方案设计等等因素。
稍微官方一点的说法就是：
系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值。
而在实际工程实践中，最终一致性分为 5 种：
1、因果一致性（Causal consistency）
指的是：如果节点 A 在更新完某个数据后通知了节点 B，那么节点 B 之后对该数据的访问和修改都是基于 A 更新后的值。于此同时，和节点 A 无因果关系的节点 C 的数据访问则没有这样的限制。
2、读己之所写（Read your writes）
这种就很简单了，节点 A 更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。其实也算一种因果一致性。
3、会话一致性（Session consistency）
会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现 “读己之所写” 的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。
4、单调读一致性（Monotonic read consistency）
单调读一致性是指如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。
5、单调写一致性（Monotonic write consistency）
指一个系统要能够保证来自同一个节点的写操作被顺序的执行。
然而，在实际的实践中，这 5 种系统往往会结合使用，以构建一个具有最终一致性的分布式系统。实际上，不只是分布式系统使用最终一致性，关系型数据库在某个功能上，也是使用最终一致性的，比如备份，数据库的复制过程是需要时间的，这个复制过程中，业务读取到的值就是旧的。当然，最终还是达成了数据一致性。这也算是一个最终一致性的经典案例。
1.分布式Session：
1.Session粘滞：
即粘性Session，当用户访问集群中某台机器后，强制指定后续所有请求都落到此台机器上。
使用场景：机器数适中，对稳定性要求不是非常苛刻。
优点：实现简单，配置方便，没有额外网络开销。
缺点：网络中有机器Down掉时，用户Session会丢失，容易造成单点故障。
方案：Nginx的ip_hash负载均衡方案
2.Session复制
将一台机器上的Session数据广播复制到集群中其余机器上。
使用场景：机器较少，网络流量较小
优点：实现简单，配置较少，当网络中有机器Down掉时不影响用户访问。
缺点：广播复制到其余机器有一定延迟，带来一定网络开销
方案：开源方案Tomcat-Redis-Session-manager，暂不支持Tomcat8
3.缓存集中式管理
将Session存入分布式缓存集群中的某台机器上，当用户访问不同节点时，先从缓存中拿Session信息
使用场景：集群中机器数较多，网络环境复杂
优点：可靠性好
缺点：实现复杂，稳定性依赖于缓存的稳定性，Session信息方入缓存时要有合理的策略写入
方案：开源方案Spring-Session，也可以自己实现，主要重写HttpServletRequestWrapper中的getSession方法。
4.分布式配置中心
在分布式系统中，一次构建，发布，上线是非常重要的一个过程，它不像单机时代那样重启一台机器，一个进程就可以了，在分布式系统中，它涉及到将软件包（例如war包）分发到可能几百台机器上，然后将几百台机器上的应用一一重启，这么一个过程需要很长的时间。那么如何在不停集群的情况下，调整整个集群的运行时的行为特征，是一个分布式系统必须回答的一个问题，从这个角度讲，我们认为，每一个大型分布式系统都应该有一个配置中心。
5.分布式事务
分布式事务解决的用户最本质的诉求是什么？---》数据一致。
解决数据一致性的几个典型方案：
1.XA事务方案
2.柔性事务
3.基于消息的最终一致性
4.业务补偿与人工订正
常见的分布式锁的实现方案：
1.MySQL
2.内存数据库（Redis，memchached）
3.zookeeper
6.分布式定时任务
什么是分布式定时任务？把分散的，可靠性差的计划任务纳入统一的平台，并实现集群管理调度和分布式部署的一种定时任务的管理方式，叫做分布式定时任务。
7.分布式定时任务框架
1.Quartz：Quartz是Java领域最著名的开源任务调度工具，Quartz提供了极为广泛的特性，如持久化任务，集群和分布式任务
2.Elastic-Job：Elastic-Job是ddFrame中的dd-job的作业模块中分离出来的分布式弹性作业框架，该项目基于成熟的开源产品Quartz和Zookeeper及其客户端Curator进行二次开发。
8.Zookeeper集群中的角色：
1.领导者（leader）：负责进行投票的发起和决议，最终更新状态
2.跟随者（follower）：用于接收客户请求并返回客户结果，参与leader发起的投票
3.观察者（observer）：可以接收客户端连接，将写请求转发给leader节点，但是observer不参与投票过程，只是同步leader状态，observer为系统扩展提供了一种方法。
4.学习者（learner）：和leader进行状态同步的server统称为learner，上述的follower和observer都是learner。
9.为什么要有Observer？
Zookeeper服务中的每个Server可服务于多个Client，并且Client可连接到ZK服务中的任何一台Server来提交请求，若是读请求，则由每台Server本地副本数据直接响应，若是改变Server状态的写请求，需要通过一致性协议来处理，这个协议就是Zab协议。
简单来说，Zab协议规定：来自Client的所有写请求，都要转发给ZK服务中唯一的Server-Leader，由Leader根据该请求发起一个Proposal，然后，其他的Server对该Proposal进行投票，之后，leader对投票进行收集，当投票数量过半时Leader会向所有的Server发送一个通知消息。最后，当Client所连接的Server收到该消息时，会把该操作更新到内存中并对Client的写请求作出回应。
Zookeeper服务器在上述协议中实际扮演了两个职能，他们一方面从客户端接受连接与操作请求，另一方面对操作结果进行投票，这两个职能在Zookeeper集群扩展的时候彼此制约。例如：当我们希望增加Zk服务中Client数量的时候，那么我们就需要增加Server的数量，来支持这么多的客户端，然而，从Zab协议对写请求的处理过程中我们可以发现，增加服务器的数量，则增加了对协议中投票过程的压力，因为Leader节点必须等待集群中过半Server响应投票，于是节点的增加使得部分计算机运行较慢，从而拖慢了整个投票过程，写操作也会随之下降，这正是我们在实际操作中遇到的问题--》随着Zookeeper集群变大，写操作的吞吐量会下降。所以，我们不得不在增加Client数量的期望和我们希望保持较好的吞吐量的期望之间做个权衡。所以我们引入了不参与投票的服务器，称之为Observer，Observer可以接收客户端的连接，并将写请求转发给Leader节点，但是，Leader节点不会要求Observer参加投票。Observer不参与投票过程，仅仅和其他服务节点一起得到投票结果。
这个简单的扩展，给Zookeeper的可伸缩性带来了全新的景象，我们可以加入很多的Observer节点，而无需担心降低吞吐量。但是这样也会有一些小问题，就是在协议中的通知阶段，仍然与服务器的数量成线性关系，但是这里的串行开销非常低，不会成为主要瓶颈。
10.Zookeeper中的CAP现象
Zookeeper至少满足的CP，牺牲了可用性，比如现在集群中有Leader和Follower两种角色，那么当其中任意一台服务器挂掉了，都要重新进行选举，在选举过程中集群是不可用的，这就是牺牲了可用性，保证了一致性。
但是如果集群中有Leader，Follower，Observer三种角色，那么如果挂掉的是Observer，那么对于集群来说是没有影响的，集群还可以用，只是Observer节点的数据不同了，从这个角度来说，Zookeeper又是牺牲了一致性，保证了可用性。
11.Zookeeper能做什么？
1.统一命名服务：在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息，其中比较常见的就是一些分布式服务框架中的服务地址列表，通过调用ZK提供的创建节点的API，能够很容易的创建一个全局唯一的path，这个path就可以作为一个名称。
2.配置中心：在分布式系统中的配置信息都是一样的，这样的配置信息可以完全交给Zookeeper来管理，将配置信息保存在zookeeper的某个目录节点中，然后将所有需要修改的应用机器监控配置信息的状态，一旦配置信息发生变化，每台应用机器就会收到Zookeeper的通知，然后从Zookeeper获取最新的配置信息到应用系统中。
3.集群管理与Master管理
4.分布式锁：这个主要得益于Zookeeper为我们保证了数据的强一致性，锁服务可以分为两类：一个是保持独占，一个是控制时序。
