Redian新闻
>
来,周末福利,cap理论里面的三种策略 (转载)
avatar
来,周末福利,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
avatar
e*a
2
what academic and technical backgrounds are required to solve this problem?
avatar
A*g
3
感谢蜥蜴哥,蜥蜴哥最近的文章都很有信息量

【在 z****e 的大作中提到】
: 【 以下文字转载自 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,然

avatar
p*3
4
a + p用dynamoDB做例子比较好的感觉。
另外2pc不就是保证strong consistency而设计的吗,虽然会有commite失败的情况。感
觉paxos就是2pc的一个基于quorum的松散的实现,所以是partition tolerant.
DynamocDB为了保证任何时候可写,没有采用像paxos这样的大多数投票决策是否写的机
制,所以是high available和partition tolerant,但是不consistent
avatar
z*e
5
dynamodb能在aws以外的地方用吗?

【在 p*****3 的大作中提到】
: a + p用dynamoDB做例子比较好的感觉。
: 另外2pc不就是保证strong consistency而设计的吗,虽然会有commite失败的情况。感
: 觉paxos就是2pc的一个基于quorum的松散的实现,所以是partition tolerant.
: DynamocDB为了保证任何时候可写,没有采用像paxos这样的大多数投票决策是否写的机
: 制,所以是high available和partition tolerant,但是不consistent

avatar
d*n
6
我上次看dynamoDB文档
说是eventual consistency和strong consistency都支持
avatar
s*n
7
赞zhaoce !
avatar
A*g
8
riak吧

【在 z****e 的大作中提到】
: dynamodb能在aws以外的地方用吗?
avatar
z*e
9
这种版权产品,有vendor lockin的风险
用apache的优先用apache的

【在 A******g 的大作中提到】
: riak吧
avatar
f*t
10
hbase不是paxos
avatar
z*e
11
2pc理论上在分布式是不完美的解
在一定程度上强化了consistency,但那是对于一次commitment而言
实际上jdbc时代的2pc都做得很一般,基本上这种transaction都是失败的
说是可以回滚,但是一旦commit指令发出,ack阶段一旦有node失败
那就挂了,其中一个node挂了,又不能让其它nodes rollback
因为commit指令已经发出,这就是分布式的死结所在
所以一些特别大的系统,基本上还是ibm的主机在做,比如全球机票
就是那么几个公司那么几个系统那么几台主机,而不是分布式
当初火车票铁道部招标的时候,也只有ibm有成熟的解决方案,就是主机
铁道部很华丽滴弃用了ibm的建议,然后自己搞了一套山寨式的分布式系统
一堆的低级bug,结果就很华丽滴挂了
实际上nosql只是用来弥补db的不足而出现的
真正核心业务,尤其是涉及到金钱的地方,我们还是建议回到db上去
db无论transaction还是index,都比较完善,而且也发展了这么多年
成熟的例子比比皆是,这就是为什么,nosql的大多数例子
其实都拿的是log来举例,因为log本身精度偏低,无论你牺牲的是a还是c
其实都无所谓,一般还是牺牲c,换取low latency,一旦c拉高,latency就会上去
还有就是,ap系统,比如cassandra,都会有选择,让你选择是否trade off latency
以换取c,我相信dynamo db也有类似选择,不过如果单纯是cp,hbase显然是王道
不考虑latency的话,eventually consistent完全可以实现
ebay的架构跟内森的其实差不多,大多数分布式系统都差不多,无非各种trade off

【在 p*****3 的大作中提到】
: a + p用dynamoDB做例子比较好的感觉。
: 另外2pc不就是保证strong consistency而设计的吗,虽然会有commite失败的情况。感
: 觉paxos就是2pc的一个基于quorum的松散的实现,所以是partition tolerant.
: DynamocDB为了保证任何时候可写,没有采用像paxos这样的大多数投票决策是否写的机
: 制,所以是high available和partition tolerant,但是不consistent

avatar
p*3
12

膜拜~~ 很全面很赞的回答

【在 z****e 的大作中提到】
: 2pc理论上在分布式是不完美的解
: 在一定程度上强化了consistency,但那是对于一次commitment而言
: 实际上jdbc时代的2pc都做得很一般,基本上这种transaction都是失败的
: 说是可以回滚,但是一旦commit指令发出,ack阶段一旦有node失败
: 那就挂了,其中一个node挂了,又不能让其它nodes rollback
: 因为commit指令已经发出,这就是分布式的死结所在
: 所以一些特别大的系统,基本上还是ibm的主机在做,比如全球机票
: 就是那么几个公司那么几个系统那么几台主机,而不是分布式
: 当初火车票铁道部招标的时候,也只有ibm有成熟的解决方案,就是主机
: 铁道部很华丽滴弃用了ibm的建议,然后自己搞了一套山寨式的分布式系统

avatar
t*e
13
理论都对,但和CAP不完全匹配啊。
Nathan还在卖他的lambda architecture.
相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。