paxos 使用票ticket来解决并发的问题；首先票有两个属性：

1. 可重新发布
   服务器可以重新发布票，即使前面发布的票还没有过期；
2. 可以过期
   当客户端使用一个票t 给服务器发送消息的时候，只有t是最新发布的票，服务器才接受。

具有这两个属性的票机制，可以很好的解决宕机的问题；如果一个客户端得到票之后宕机其他客户端不会受到影响，因为服务器可以发布新的票；

简单基于票的协议

1. 客户端向所有服务器请求一张票

2. 收到过半的票

if 收到过半服务器的回复 
      票和命令一起发给每个服务器
      服务器检查票，如果有效，存储命令并回复客户端成功 store_success
else
   客户端等待随机时间，然后重新请求票

3. 检查是否存储成功

  if  收到过半服务器的 store_success 
        客户端告诉所有的服务器执行存储命令
  else
        客户端等待随机事件，然后重新进入第一步，请求票

basic ticket.png

并发的场景:
如果有两个客户端C1和C2，C1很慢，C2快；C1先执行，如果C2在C1进行第三步时候拿到票（序列图中7-11），那么C1的票失效，所有的服务器将拒绝执行之前存储的命令；

paxos

与上面的算法不同的是，paxos将采用客户端自己保存票ticket，服务器只是保存已经发布的票。

1. 初始化的时候客户端 t =0; 服务器Tmax = 0 Command = 0 Tstore = 0
2. 向所有的服务器发送请求批准编号为t的票
3. 获得半数以上的票选择Tstore最大值的Command
4. 获得回复ok的服务器，发送propose
5. 过半服务器回复success，向每个服务器发送execute c 执行这个命令

Paxos.png

由此客户端发送提案如果该提案在过半服务器上存储，那就说明这个提案被选中，一旦选中在未执行前，其他的客户端都会使用这个提案，参照序列图11

如果拥有第一个成功提案的客户端在执行命令前宕机了，服务器会等到下次有客户端发送提案请求的时候，告诉客户端已经有一个待执行的命令；这样该客户端先发送执行上一条命令

这里的客户端在p2p场景下同样适用，每个节点即是服务器也是客户端