直接举例：
以我们常用的火车票订购系统为例，每当过年的时候，全国有多少人抢票这里不做统计，但是一个购票系统服务器是绝对无法满足需求的，大量的访问和请求会直接导致服务器宕机。
所以为了满足这种需求，铁路局决定采用分布式集群的方式解决大量用户同时访问的问题。这样购票系统被同时部署在多个服务器上，通过负载均衡的方式来响应客户端的购票请求。我们这里假定有5个分布式服务器，流程如下：
这样的话就不用担心服务器不够用了，如果用户量持续增加，我们也可以随时扩充服务器数量，通过负载均衡，保证多个服务器之间工作量均衡。负载均衡虽然解决了大量访问的问题，但同时引发了一个更加亟待解决的问题，那就是分布式下的数据一致性。
如果只有一台服务器，所有对数据操作都是在同一台服务器上，数据肯定是一致的。
现在没一台服务器都有相同的数据拷贝，怎么保证数据的一致性？
Paxos算法解决了这一问题，举例如下：
继续上面的流程图，A、B、C、D、E服务器分别存储着当前车票信息，包括车票车票买入情况等，假定这时候每台服务器记录着从北京到郑州的火车票数量为1，无论哪个客户从哪太服务器购买了从北京到郑州的车票，其他的服务器必须能同时更新车票信息，确保不会出现多个人买同一个座位票的情况。
我们假定客户1、客户2同时购买从北京到郑州的车票，但是由于计算机性能或者网络原因，客户1的请求率先通过负载均衡器的分配到达服务器A，服务器A接收到请求，得知客户1想购买一张从北京到郑州的车票，然后检查自己的车票信息，数量为1，确认自己可以满足购买要求，但是这时候还不能确定服务器B、C、D、E的情况，万一有人捷足先登从B、C、D、E购买了票，自己这边再卖出去岂不是出问题，所以需要确认一下其他服务器的情况。服务器A向B、C、D、E发出确认请求，B、C、D、E只要有2个答复说可以购买，就算超过半数达成了一致，服务器A接收到确认，然后会再发一条指令告诉B、C、D、E，“我从我库里减少一张票，当前为0”，B、C、D、E接到指令，只要有2个给出答复“我已经减少了一张票，当前为0”，到此，就达成了一致。服务器A告诉客户A，你买票成功了，这张票已经到了你的账号里。
如果在服务器A处理客户1请求的时候，这时候服务器E接到了客户2的请求，这时候服务器E的状态存在以下几种可能：
1、服务器E由于网络原因没有收到任何确认消息，包括服务器A的消息。这时候服务器E会重新发送确认消息给A、C、D、E，第一轮先确认购票前的数据一致性，第二轮确认购票后的数据一致性。如果任何一个环节不能确认数据一致，服务器E就不能处理客户B的请求。比如在确认过程中有超过半数的服务器告诉E，“我们的余票是0”，服务器E将告诉客户2没票了，同时将自己的余票改为0。
2、服务器E已经接收服务器A的第一轮咨询，服务器E也已经告诉服务器A，自己余票是1,可以购买。但是这时候服务器E还不能确认服务区A有没有卖票成功，所以服务器E同样可以卖票，这时候同样需要两轮的确认。
3、服务器E已经接收服务器A的第二轮确认，并且同意且余票状态已经修改为0，这时候会反馈给客户2已经没票了。
有了以上的业务需求场景，我们再回过头理解一下Paxos算法中的角色和概念：
1、Proposal Value： 提议的值
2、Proposal Number： 提议编号，要求提议编号不能冲突
3、Proposal： 提议 = 提议的值 + 提议编号
4、Proposer： 提议发起者
5、Acceptor： 提议接受者
6、Learner： 提议学习者
这里面服务器充当Paxos算法中的所有角色，服务器A根据客户端请求发起提议，服务器A为提议发起者。BCDE接收提议，为接收者。