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 的数量，但对写入没有帮助，反而会加大写入的延时，适合于像配置中心这类多监视变化，少修改的类型

程序架构图： 红框的部分，是我们需要做的

您可能感兴趣的文章: