每一条事务的zxid是64位的，高32位是leader的epoch，就认为是leader的版本吧；低32位才是自增长的zxid
老leader发送出去的proposal，高32位是1，低32位是11358
如果一个leader自己刚把一个proposal写入本地磁盘日志，就宕机了，没来得及发送给全部的follower，此时新leader选举出来，他会的epoch会自增长一位
proposal，高32位是2，低32位是继续自增长的zxid
然后老leader恢复了连接到集群是follower了，此时发现自己比新leader多出来一条proposal，但是自己的epoch比新leader的epoch低了，所以就会丢弃掉这条数据
启动的时候，过半机器选举leader，数据同步
对外提供服务的时候，2PC + 过半写机制，顺序一致性（最终的一致性）
崩溃恢复，剩余机器过半，重新选举leader，有数据不一致的情况，针对两种情况自行进行处理，保证数据是一致的（磁盘日志文件、zxid的高32位）