概念
由很多自主的计算机组成。很容易地把运行在不同计算机上的不同应用程序集成到单个系统中。
清晰的记录接口。轻松的扩展。
分布式类型：分布式计算系统、分布式信息系统（数据处理）
互斥
集中式算法
每个程序在需要访问临界资源时，先给协调者发送一个请求。
如果当前没有程序使用这个资源，协调者直接授权请求程序访问；否则，按照先来后到的顺序为请求程序“排一个号”。
如果有程序使用完资源，则通知协调者，协调者从“排号”的队列里取出排在最前面的请求，并给它发送授权消息。
拿到授权消息的程序，可以直接去访问临界资源。
分布式算法
当一个程序要访问临界资源时，先向系统中的其他程序发送一条请求消息，在接收到所有程序返回的同意消息后，才可以访问临界资源。其中，请求消息需要包含所请求的资源、请求者的 ID，以及发起请求的时间。这就是民主协商法。在分布式领域中称之为分布式算法，或者使用组播和逻辑时钟的算法。
令牌环算法
所有程序构成一个环结构，令牌按照顺时针（或逆时针）方向在程序之间传递，收到令牌的程序有权访问临界资源，访问完成后将令牌传送到下一个程序；若该程序不需要访问临界资源，则直接把令牌传送给下一个程序。
选举算法
Bully算法
1、集群节点角色类型
主节点、普通节点，主节点负责对其他节点的协调和管理
2、选举策略
在所有活着的节点中，选取 ID 最大的节点作为主节点，当选主成功后，有且仅有一个节点成为主节点，其他所有节点都是普通节点，当且仅当主节点故障或与其他节点失去联系后，才会重新选主。
3、选举过程
a、选举使用到的消息
Election消息: 用于发起选举; Alive消息: 对Election 消息的应答; Victory消息: 竞选成功的主节点向其他节点发送的宣誓主权的消息
b、选举流程
前提条件：集群中每个节点均知道其 他节点的 ID，流程如下：
1、集群中每个节点判断自己的ID是否为当前活着的节点中 ID 最大的，如果是，则直接向其他节点发送 Victory 消息，宣誓自己的主权;
2、如果自己不是当前活着的节点中 ID 最大的，则向比自己 ID 大的所有节点发送 Election 消息，并等待其他节点的回复;
3、若在给定的时间范围内，本节点没有收到其他节点回复的 Alive 消息，则认为自己成为 主节点，并向其他节点发送 Victory 消息，宣誓自己成为主节点;若接收到来自比自己 ID 大的节点的 Alive 消息，则等待其他节点发送 Victory 消息;
4、若本节点收到比自己 ID 小的节点发送的 Election 消息，则回复一个 Alive 消息，告知 其他节点，我比你大，重新选举。
4、选举条件
-集群初始化
-主节点故障或与其他节点失去联系
-任意一个比当前主节点 ID 大的新节点加入集群
-某个节点从故障中恢复
实例：MongoDB、Elasticsearch
Raft算法
三个角色
• Leader（领导者） ：负责日志的同步管理，处理来自客户端的请求，与Follower保持heartBeat的联系；
• Follower（追随者） ：响应 Leader 的日志同步请求，响应Candidate的邀票请求，以及把客户端请求到Follower的事务转发（重定向）给Leader；
• Candidate（候选者） ：负责选举投票，集群刚启动或者Leader宕机时，状态为Follower的节点将转为Candidate并发起选举，选举胜出（获得超过半数节点的投票）后，从Candidate转为Leader状态。
通过leader节点，Raft算法将一致性问题简化为3个子问题：
• 领导选举：当前leader节点崩溃下线或集群刚启动时，需要选举一个新的leader。
• 日志复制：leader节点将自己接收的请求记录到日志中，并将日志广播给其他节点，从而保证集群数据达到一致。
• 数据安全：如果某个日志已经被集群提交，那么该日志不能再被覆盖或者修改。
Heartbeats and Timeouts
1. 所有的Server均以Follower角色启动，并启动选举定时器
2. Follower期望从Leader或者Candidate接收RPC
3. Leader必须广播Heartbeat重置Follower的选举定时器
4. 如果Follower选举定时器超时，则假定Leader已经crash，发起选举
Leader election
自增currentTerm，由Follower转换为Candidate，设置votedFor为自身，并行发起RequestVote RPC，不断重试，直至满足以下任一条件：
1. 获得超过半数Server的投票，转换为Leader，广播Heartbeat
2. 接收到合法Leader的AppendEntries RPC，转换为Follower
3. 选举超时，没有Server选举成功，自增currentTerm，重新选举
实例：Redis
ZAB算法
ZAB(ZooKeeper Atomic Broadcast)选举算法： ZooKeeper 为实现分布式协调功能而设计的。相较于 Raft 算法的投票机制，ZAB算法增加了通过节点 ID 和数据 ID 作为参考 进行选主，节点 ID 和数据 ID 越大，表示数据越新，优先成为主。相比较于 Raft 算法， ZAB 算法尽可能保证数据的最新性。所以，ZAB 算法可以说是对 Raft 算法的改进。
1、集群节点角色类型与状态
角色：Leader（主节点）、Follower（跟随者节点）、Observer（观察者，无投票权）
选举过程中的状态
Looking（选举状态）当节点处于该状态时，认为集群中没有 Leader， 节点会进入选举状态
Leading（领导者状态）已经选出主，且当前节点为 Leader
Following（跟随者状态）集群中已经选出主后，其他非主节点状态更新为Following，表示对 Leader 的追随
Observing（观察者状态）当前节点为 Observer，持观望态度，没有投票 权和选举权
ZAB 算法性能高，对系统无特殊要求，采用广播方式发送信息，若节点中有 n 个节点，每个节点同时广播，则集群中信息量为 n*(n-1) 个消息，容易出现广播风暴;除了投票，还增加了对比节点 ID 和数据 ID，这就意味着还需要知道所有节点的 ID 和数据 ID，所以选举时间相对较长。但该算法选举稳定性比较好，当有新节点加入或节点故障恢复后，会触发选主，但不一定会真正切主，除非新节点或故障后恢复的节点数据 ID 和节点 ID 最大，且获得投票数过半，才会导致切主
实例：Zookeeper