paxos整合mysql_从数据复制到paxos一致性算法

从数据复制到paxos一致性算法

(2011-05-14 16:17:05)

标签：

数据复制

数据同步

it

分类：

技术

从数据复制到paxos一致性算法

一、数据复制的用途

数据复制(replication)一般用于下面三个方面：

1、容错

一个节点出错，不致于让整个系统停止工作，别的节点可以接管它的工作

2、提高系统的扩展能力

把负载分布到多个节点上，或者增加节点来提高系统的负载能力

3、提高性能

让客户端本地访问就近的节点，能提高用户访问速度

二、数据复制集群系统的分类

从客户端读写访问的透明度来看，数据复制集群系统分下面两种：

. 写主(Write Master)

对数据的修改提交给指定的节点。读无此限制，可以读取任何一个节点。这种情况下客户端需要对读与写进行区别，俗称读写分离；

. 写任意(Write Any)

对数据的修改可提交给任意的节点，跟读一样。这种情况下，客户端对集群节点的角色与变化透明；

从客户端访问的响应速度来看，数据复制集群系统又可分下面两种：

. 延迟复制(Lazy Replication)

节点完成修改操作后，直接给用户返回成功的消息。修改的数据延迟复制到别的节点上，客户端不需要为数据复制过程付出等待时间。当节点分布在不同的地域上的时候，客户端就近提交，很快就能返回，响应速度是最快的；

. 立即复制(Eager Replication)

节点完成修改后，还要等别的节点都完成修改才给用户返回成功的消息。客户端需要为数据的复制过程

付出等待时间。当节点分布在不同的地域上的时候，客户端虽能就近提交，但仍享受不同就近提交的快速响应的好处了；

这样，从客户端的角度，可以对数据库复制集群系统分成下面四种：

1、延迟复制，写主

2、立即复制，写主

3、延迟复制，写任意

4、立即复制，写任意

下面我把常见的数据复制集群系统，按下图进行区分：

这里面包括mysql、redis、google chumby、keyspace、yahoo pnuts、paxos、yahoo

zookeeper以及erlang mnesia。

三、数据复制集群系统性能指标

对数据复制集群系统来说，有下面两类性能指标：

1、吞吐能力(throughput)

指单位时间执行读写请求的数量

2、响应时间(response time)

对单个请求来说，从提交请求到完成的时间

从系统吞吐能力指标来看：

. 读(Read) 扩展性好，增加节点就能读的请求数，但根椐系统的实现的不同，有可能读到旧的或不一致的数据

. 写(Write) 扩展性不好，整个集群的写能力不会超过单个节点的写能力

所以整个数据复制系统综合的吞吐扩展能力，取决于读写的分例。

从响应时间指标来看：

. 读(Read) 好，通过增加节点资源或者在客户附近就近增加节点来综短响应时间

. 写(Write) 综合起来没有读好，同时依赖实现方式

四、Paxos数据一致性算法

为什么单独还要提到Paxos数据一致性算法呢？对互联网应用来说，数据复制系统一般先不管或弱化数据一致性需求，讲的比较多的是最终一致性，这方面的算法和论文就比较多了。我觉得有些关键的基础服务还需要考虑一致性，需要有一个类似chumby或zookeeper一样的基础服务系统，我个人又比较偏爱paxos算法。

用paxos算法，只要有多数机器(一半以上)活着，就能提交写请求，而且在因网络方面集群分成几个，而相互之间不通的情况下，只要有一个多数机器子集群存在，仍然能保证这一点。当然paxos算法不保证写的可用性，很明显不是什么时候都能提交而形成决议的。

五、参考资料

DataBase Replication (Morgan & Claypool

Publishers)

Paxos Made Practical.pdf

Paxos for System Builders.pdf

Paxos made live, An engineering Perspective.pdf

Paxos made simple.pdf

分享：

喜欢

0

赠金笔

加载中，请稍候......

评论加载中，请稍候...

发评论

登录名： 密码： 找回密码 注册记住登录状态

昵   称：

评论并转载此博文

发评论

以上网友发言只代表其个人观点，不代表新浪网的观点或立场。