paxos 使用票ticket来解决并发的问题；首先票有两个属性：
- 可重新发布
服务器可以重新发布票，即使前面发布的票还没有过期； - 可以过期
当客户端使用一个票t 给服务器发送消息的时候，只有t是最新发布的票，服务器才接受。
具有这两个属性的票机制，可以很好的解决宕机的问题；如果一个客户端得到票之后宕机其他客户端不会受到影响，因为服务器可以发布新的票；
简单基于票的协议
客户端向所有服务器请求一张票
收到过半的票
if 收到过半服务器的回复
票和命令一起发给每个服务器
服务器检查票，如果有效，存储命令并回复客户端成功 store_success
else
客户端等待随机时间，然后重新请求票
- 检查是否存储成功
if 收到过半服务器的 store_success
客户端告诉所有的服务器执行存储命令
else
客户端等待随机事件，然后重新进入第一步，请求票
basic ticket.png
并发的场景:
如果有两个客户端C1和C2，C1很慢，C2快；C1先执行，如果C2在C1进行第三步时候拿到票（序列图中7-11），那么C1的票失效，所有的服务器将拒绝执行之前存储的命令；
paxos
与上面的算法不同的是，paxos将采用客户端自己保存票ticket，服务器只是保存已经发布的票。
- 初始化的时候客户端 t =0; 服务器Tmax = 0 Command = 0 Tstore = 0
- 向所有的服务器发送请求批准编号为t的票
- 获得半数以上的票选择Tstore最大值的Command
- 获得回复ok的服务器，发送propose
- 过半服务器回复success，向每个服务器发送execute c 执行这个命令
Paxos.png
由此客户端发送提案如果该提案在过半服务器上存储，那就说明这个提案被选中，一旦选中在未执行前，其他的客户端都会使用这个提案，参照序列图11
如果拥有第一个成功提案的客户端在执行命令前宕机了，服务器会等到下次有客户端发送提案请求的时候，告诉客户端已经有一个待执行的命令；这样该客户端先发送执行上一条命令
这里的客户端在p2p场景下同样适用，每个节点即是服务器也是客户端
