分布式系统的由来与特点
集中式部署 ------（阿里的去IOE化）------> 分布式部署
集中式部署：
分布式部署：
分布性、对等性、并发性、缺乏全局时钟(各个分布式系统上的时间需要相同)、故障随时会发生
分布式系统：
一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。
大型网站架构图：
H5.APP.PC.------->Lvs+keepalived------>Nginx集群------>应用层（web服务器、分布式session）------->服务层------>基础设施（缓存、消息中间件、搜索引擎、配置中心）------>数据库层
分布式系统带来的问题：
通信异常、网络分区、三态（成功，失败，超时）、节点故障
脑裂问题
nginx服务端。。。zk客户端
分布式系统协调“方法论”：
* CAP理论：
C，一致性：数据在分布式环境下的多个副本之间能否保持一致性，这里的一致性更多是指强一致性。
A，可用性：分布式系统一直处于可用状态，对于请求总能在有限的时间内返回结果性
P，分区容错性：除非整个网络故障，分布式系统在任何网络或单点故障时，仍能对外满足一致性和可靠性的服务。
一个分布式系统不可能同时满足一致性、可用性和分区容错性这三个基本需求，最多只能同时满足其中的两项；
放弃P（满足AC）：将数据和服务都放在一个节点上，避免因网络引起的负面影响，充分保证系统的可用性和一致性。但放弃P意味着放弃了系统的可扩展性。
放弃A(满足PC)：当节点故障或者网络故障时，受到影响的服务需要等待一定的时间，因此在等待时间里，系统无法对外提供正常服务，因此是不可用的
放弃C(满足AP)：系统无法保证数据的实时一致性，但是承诺数据最终会保证一致性。因此存在数据不一致的窗口期，至于窗口期的长短取决于系统的设计
* BASE理论：即使无法做到强一致性，但分布式系统可以根据自己的业务特点，采用适当的方式来使系统达到最终的一致性；
Basically Avaliable 基本可用：当分布式系统出现不可预见的故障时，允许损失部分可用性，保障系统的“基本可用”；体现在“时间上的损失”和“功能上的损失”；e.g：部分用户双十一高峰期淘宝页面卡顿或降级处理；
Soft state 软状态：允许系统中的数据存在中间状态，既系统的不同节点的数据副本之间的数据同步过程存在延时，并认为这种延时不会影响系统可用性；e.g：12306网站卖火车票，请求会进入排队队列；
Eventually consistent 最终一致性：所有的数据在经过一段时间的数据同步后，最终能够达到一个一致的状态；e.g：理财产品首页充值总金额短时不一致；
分布式一致性算法（解决拜占庭将军问题）
2p/3p：2p两阶段提交，数据库分布式事务经常使用的一种分布式算法，算法简单，但有出现阻塞，数据再某情况不一致的问题，3p对2p进行了完善，完善了阻塞以及可用性
paxos算法：分布式一致性算法，也分两个阶段，遵循少数服从多数的原则，并不需要所有参与者都同意某一协议
zab：借鉴paxos思路，是zookeeper解决分布式一致性所使用的算法
分布式环境协调和通信到底有什么场景？
数据发布订阅:
负载均衡:
命名服务:
Master选举:
集群管理:
配置管理:
分布式队列:
分布式锁: