终于理解了CAP定理

Brewer最早的ppt讲得太泛了,看了还是不明白。后来看了很多相关的文章,才明白了这个东西。

为了不走弯路,首先你要明白Partition是
指什么。它不是“分区容忍性”,而是对“系统内部结点间通信失败的容忍性”。

其次,CAP所针对的分布式系统是跟数据相关的,要么这个系统直接存储了数据,要么它会把数据存储到另外的系统中,这样才有必要谈C(数据一致性)。无状态的分布式应用是没有资格谈CAP的。

再次,3″取”2 这种说法是很含混的,不要过分纠结。以mysql服务为例,

1. 如果说舍弃P,那仅仅意味着你的mysql是单机版的;单库可以利用事务直接保证C,而且你可以通过scale up来获得A. 这种情况下,你的应用并不是一个分布式应用。

2. 如果要保留P,也仅仅是指mysql使用了读写分库或者其他分拆方案。什么叫耐受,什么叫不耐受,并没有明确的定义。它只是给你提供一个将讨论持续下去的基础,也就是说,在分拆之后,你才可以开始谈“在A和C之间取舍”。

以读写分库为例,当主备库之间网络断裂时,

a.如果你仍然允许主库写、备库读,则主备库都是高可用的,但主备库数据却由于无法同步而出现了不一致,也就是说,有A无C.

b.如果你不允许主库写,则在用户眼里写操作就不是可用的了,但是主备库的数据却保证了一致性,也就是说,有C无A.

总结一下:在分布式应用中,P是天然存在的,而所谓的Trade-Off是指A和C之间的取舍。

最后要说明一下,“有A无C”、”有C无A”以及“无法同步”都是比较极端的情况,在实践中,尤其是高并发的应用中,你面临的更多是“A强C弱“、”C强A弱“(A的强弱即系统响应的快慢)、“同步时延很高”这些灰色的东西。

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.