来,周末福利,cap理论里面的三种策略 (转载)# JobHunting - 待字闺中
z*e
1 楼
【 以下文字转载自 Programming 讨论区 】
发信人: zhaoce (米高蜥蜴), 信区: Programming
标 题: 来,周末福利,cap理论里面的三种策略
发信站: BBS 未名空间站 (Sun Oct 27 03:57:15 2013, 美东)
c+a = mvcc, multiple version concurrency control
简单说就是,每一次修改的时候,不加lock,在另外一个地方写新版本,等更新完成之
后,再把index定位到新版本上去,这样可以在大并发时候及时返回,现在主要db都这
个策略,但是这个麻烦是很难partition
a+p = 2pc, two phase commitment
简单说就是,每一次需要修改的时候,第一步,先向所有的nodes发送stop point,然
后反馈,收集到所有的nodes的反馈之后,再发送修改指令,commit,但是这种策略不
能保证所有的nodes上的数据都是一致的,只能认为他们都是一致的,因为无论多少次
commit,总存在一种可能,某一些nodes在commit之后,它fail to commit了,所以不
能保证consistency,目前比较常见的选择是cassandra
c+p = paxos, paxos algorithm
简单说就是,paxos算法,就是一种类似民主投票选举的策略,当需要修改的时候,
master node广播出去,最后只要收集到一定程度的反馈,比如100个nodes,要求超过
51个nodes,就返回,就认为这个修改成功了,但是问题在于,有些nodes可能会fail
to respond,所以availability不能保证,会被牺牲掉,但是无论你尝试多少次,因为
已经收集到一定数量的成功的nodes,所以最终结果都是一致的,以这种方式来保证
consistency,目前常见的选择是hbase,但是这个还有一个问题就是,在等待足够数量
的nodes反馈的过程中,等待需要时间,简单说就是慢
三种策略都有自身局限,所以现实中需要凑在一起搞,怎么搞?
参考内森的文章
http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html
发信人: zhaoce (米高蜥蜴), 信区: Programming
标 题: 来,周末福利,cap理论里面的三种策略
发信站: BBS 未名空间站 (Sun Oct 27 03:57:15 2013, 美东)
c+a = mvcc, multiple version concurrency control
简单说就是,每一次修改的时候,不加lock,在另外一个地方写新版本,等更新完成之
后,再把index定位到新版本上去,这样可以在大并发时候及时返回,现在主要db都这
个策略,但是这个麻烦是很难partition
a+p = 2pc, two phase commitment
简单说就是,每一次需要修改的时候,第一步,先向所有的nodes发送stop point,然
后反馈,收集到所有的nodes的反馈之后,再发送修改指令,commit,但是这种策略不
能保证所有的nodes上的数据都是一致的,只能认为他们都是一致的,因为无论多少次
commit,总存在一种可能,某一些nodes在commit之后,它fail to commit了,所以不
能保证consistency,目前比较常见的选择是cassandra
c+p = paxos, paxos algorithm
简单说就是,paxos算法,就是一种类似民主投票选举的策略,当需要修改的时候,
master node广播出去,最后只要收集到一定程度的反馈,比如100个nodes,要求超过
51个nodes,就返回,就认为这个修改成功了,但是问题在于,有些nodes可能会fail
to respond,所以availability不能保证,会被牺牲掉,但是无论你尝试多少次,因为
已经收集到一定数量的成功的nodes,所以最终结果都是一致的,以这种方式来保证
consistency,目前常见的选择是hbase,但是这个还有一个问题就是,在等待足够数量
的nodes反馈的过程中,等待需要时间,简单说就是慢
三种策略都有自身局限,所以现实中需要凑在一起搞,怎么搞?
参考内森的文章
http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html