paxos是什么？
一致性算法，google称其为唯一的一致性算法，其他的算法都是paxos的简化。
我们知道一般数据库的主从同步，实际上在极端情况下，依然会产生不一致的现象，这就造成了master的损坏，需要手动的切换备机，而在paxos中，由于一致性算法，我们可
以做到自动的进行master的切换，而不会产生不一致的现象，当然这个要在一个大前提下，就是n台机器，仅有小于 n/2的机器损坏，但这样依然提供了我们一种更高的容灾标准。
jbpaxos是什么？
jbpaxos = java basic paxos , java语言实现的paxos编程框架，提供高可用，强一致，基于paxos构建分布式程序的框架。
适用的场景？
对于一般的应用而言，没有数据的保存，仅仅是提供服务，那么我们可以说这些server对于数据而言是无状态的，比如说，我们多数的java web应用，这些应用所需要的数据，
要么在缓存里，要么在 db里，那这些server仅仅需要提供一个更稳定的负载器来进行故障转移即可了，实际上整套系统的一致性和容灾全部交由另外的系统来解决（db,缓存，
稳定的负载均衡），这些server 是不适用paxos算法的。
对于另外一些应用，我们需要自己维护数据副本，不依赖于第3方服务的，比较适合paxos，自动选主，主故障时，15s恢复期，可提供强一致性，诱人的特性，但这些特性，也
不是没有代价，更高的网络负载，更高的写入延时,如果你能忍受这些，那么请选择paxos吧。
构建高可用的分布式程序，不是有zookeeper吗?
zookeeper提供了类似chubby的功能，可以说zookeeper提供的是一种服务，jbpaxos提供的是更底层的算法实现，基于接口的编程，就可以实现类似与zookeeper的功能
通过jbpaxos，可以自由的实现副本间的同步，zookeeper提供服务的形式，是无法提供副本间同步的功能，副本间同步的功能，请参见下面的demo,实际上，每个config server 就是一份副本
jbpaxos 0.0.1beta提供了什么？
一个classic paxos的实现，应对磁盘损坏，主机宕机，可以做到15s恢复，提供了paxos的底层实现，提供了网络层的接口，二次开发不需要考虑网络层上的开发，基于此项目的二次开发，可以实现高可用的配置中心，分布式锁，基于paxos的副本同步机制等等。
根据网络情况，和设定的最大 rt 容忍时间，自动运行时调整封包大小，最大化网络利用率。
0.0.1beta暂时没有提供fellower的实现，仅仅有senator的实现
senators,用于写入时投票的节点，fellowers（下个版本实现，对于配置中心类似的多读少写的应用比较有用）,仅仅学习的节点，不参与投票过程
master , 从senators中选举出的法官，它来发起一项法案的投票
3个节点时，写入大小128bytes, 单线程单tcp连接非阻塞同步写入3w+ tps , 1000线程单tcp连接阻塞同步写入2.5w+ , 3线程3个 tcp连接非阻塞同步写入4w+ ，单线程同步写入200tps
写入大小512bytes ,3线程3个 tcp连接非阻塞同步写入3w+
写入大小1024bytes,3线程3个 tcp连接非阻塞同步写入1.6w+
512及1024bytes的时候，基本上将千兆网卡顶满了
如果说节点上升到5个的时候，吞吐会下降，写入的大小影响系统性能非常多，所以建议在开发的时候写入数据需要经过压缩，建议使用snappy或lzo这种高吞吐的压缩算法
读取性能，要看二次开发的实现如何，及服务端口，是否和内部系统端口，走同一块网卡
当前的总体架构图
\
架构解说： 5个config server 为互备节点，当2个节点（包含2个）以下损坏，不会影响服务，client连接上任一节点即可，对于跨机房部署，要优先连接最近的节点
后续架构： jbpaxos下个版本，预计支持fellower,当下个版本发布后，config server不做代码修改，即可将架构变为下图：
后续架构解说： 相比两种架构区别,后一种，在扩展更高连接量时，有非常大的优势，fellower的数量决定了可以支撑的client 的数量，但对写入没有帮助，反而会加大写入的延时，适合于像配置中心这类多监视变化，少修改的类型
程序架构图： 红框的部分，是我们需要做的
