z****e
发帖数: 54598 | 1 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 | z****e
发帖数: 54598 | 2 现在hadoop主要问题就是hbase慢
hbase适合做historical data，不适合做real time instant data
所以放在secondary storage比较好，虽然慢，但是除此以外问题不大
要做的就是在前面加一层处理，storm之类的可以派上用场 |
|
