对Primary-backup分布式数据库分布式一致性的猜想

对Primary-backup分布式数据库分布式一致性的猜想

昨天读了paxos算法，心里对分布式一致性有一些想法：如果是我，应该怎么实现数据库集群的一致性呢?

paxos算法本身并没有提到其应用，所以实际使用情况应该较复杂。而我平时接触到使用分布式一致性算法的就是mongodb replicaset。它和zookeeper相似，只是它的data model不只包括集群配置，还有其庞大复杂的数据库。

paxos为何需要两阶段?也许是在learn的时候方便直接使用?也许是

印象中mongodb选master只需要一次请求就行(貌似slideshare上的mongo讲义上看的)，只要提出请求等待被accept就行，如果它得到多数回应接受，它就成为新的master(如果多数都回应了acceptance,但是它不知道，那么它就不是master,是master的条件是它已经知道,如果它不知道它就一直询问直到得到多数回应),它向所有node发出通知自己是master。对于每个数据写请求，通过master发送给所有node之后，收到大多数的acceptance后master才认为写入成功,它发出通知最新版本是oplogid，没有更新到最新的node就从server拿数据。如果发现master挂了（或者连接超时)而能连上多数节点,就发出一个选举自己当master的提议，收到多数acceptance(acceptor只有在连不上原来master的情况下才同意)才认为自己已经是master,它发出通知它已经是master了，得到多数节点"知道了"的回应(这些节点就停止接收旧master的数据)，然后它向集群中的节点查询最新版本,根据多数回应决定它需要同步多少数据，选择一个它认为的包含最新版本的节点，同步好这些数据之后它就开始处理新的写请求了。

需要特别说明的是，对于数据写,master可能不知道大多数是否已经写成功，如果无法确知它会一直询问，直到得到多数回应。只有样它才进行后面的写操作。注意还有一个majority的问题，要等待数据写成功的majority应该要设置得比集群一半大一些，比如21个节点的集群，11个就已经超过一半，但写成功的等待比如超过15台才觉得合适。因为如果只是设成11，这11台当时写成功了，但过了一会有一台挂了等于没构成多数，还是没写成功。因此等majority写成功不意味着一定写成功了，但是这个majority设得高一些，成功率可以接近100%。而查询状态的majority只要超过1半就行。

上述系统由于需要很多通信完成同步，要求节点之间延迟较低，在master选择之后，写操作全由master发起，写性能比较差，节点越多写得越慢(扩展性不好),读操作象zookeeper那样从本地读取。zookeeper中切换server节点，不允许切到更低版本的server,这点在web上很有用。你总是要看更新的状态，不能刷新一下回到过去的状态。mongodb的java driver似乎没有做这个工作。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。