分布式系统中的命令执行的一致性（paxos算法）

在服务器以及客户端之间加入一层串行器，使客户端的命令串行化发给服务器，但有个问题是，无法避免客户端的单点故障。
或者在客户端加一个互斥锁，每次只能一个客户端发送命令，但是这个算法问题挺大的，用脚趾头想想都能知道，参与者越多的话，越不靠谱
用购票的方式获得向服务器发送消息的许可，票有一定的保质期，这样整个系统就不会因为一个节点的崩溃而gg，同时也带来了一定的竞争性，但是，你使用票之后，还是需要去竞争，服务器并不会给你留位置，但是，无法解决延迟问题，如果一个运行缓慢的客户端通过了票的验证，当它告诉超过半数的服务器要执行验证时储存的命令，有可能另一个运行快的已经把这个命令改了。（注：如果u2在u1储存之前就已经拿到它的票，那u1的储存失效，票过期。）（需要运行某个命令，先需要让这个命令得到超过半数的服务器的认可）
购票问题的解决方法，u2若要更改u1储存的命令，那么它的票一定是比u1的新，如果u1在储存命令阶段服务器还公布它储存的命令，这样u2就可以判断是否更改，从而避免u2使u1储存的命令在不同的服务器上执行不同。（服务器要么支持最新的命令，要么支持过半数服务器已经支持的命令）
总结下就是，用购票的方式，服务器下一次发票的时候，会把上一次储存的票公布，提醒后面的是否选择更改，u1购票，并把自己的命令储存在服务器上，当超过半数的服务器回复ok，那么命令被认可，向服务器发送命令请求，运行票号对应的命令，这个命令不可被后来者修改。
证明：假设至少存在一个提案propose(t’,c’),满足t’>t且c’ != c。（t为命令编号，c为命令内容），这里我们只考虑那个拥有最小提案票号的提案，即t’>t。不存在t~,使t’>t~>t，因为propose(t’,c’)和propose(t,c)都被送到了超过半数的服务器之中，那么一定存在两台服务器收到了这两个提案。（提案是用来告诉服务器执行命令的）
服务器自动执行已经储存且编号最高的命令，则若要执行c’，服务器需要从别的服务器得知有新的c~，c~ != c已经被执行，这样才会使c失效,这就需要之前有一个proposal(t~,c~)已经被执行，但这与我们的假设不存在t’>t~>t相违背。
因此，当某个包含命令c的提案被执行后，后来的每个提案都将执行提案c。这样的话，可以完美避免单节点故障问题，如果客户端发送提案前就gg了，那么，只有下一个客户端成功提案后命令才会被执行。