【转】运维的CAP原则

运维的CAP原则

上的 文章大多以实际操作为主，这次就介绍点理论吧。

曾经跟几个同行聊起了数据库这边的容错方案，有朋友发过类似的牢骚：“网站（或者数据库）做了负载均衡，可用性提高了，单点故障也不怕了，但数据的同步总是慢半拍，无法适用某些应用。如果要求完全解决一一致性的麻烦，就只能到回去。”

程序开发上始终念念不忘的有个“摩尔定律”，归根结底的就是说不要放太多精力去隄防运算速度达不到的问题。在运维以及底层架构涉及上有着同样重要的 定律“CAP”，最早由加州大学伯克利分校（又是他）的Eric A. Brewer教授提出的。所有的分布式系统的好坏主要有3个重要的指标来衡量：

• 一致性（Consistency）
• 可用性（Availibility）
• 容错性、鲁棒性原文翻译是“分区容错”（Partition tolerance）

任何一个分布式系统只能同时满足3个条件中的两个，无法同时达到3者兼备。

就拿磁盘RAID来说：

RAID0的情况是数据分散在多块硬盘之上，只存一份。由于只有一份数据，不存在数据不同步的情况，一致性得到保障。多磁盘分散IO，性能提升，可用性提升。多块磁盘拼凑一份数据，磁盘损坏的概率正比上升，同时增加磁盘的难度提升，容错性下降。即为了C和A，放弃了P。

RAID1的情况是数据在每个磁盘上做一个备份。由于有多个备份，可能出现多个磁盘上数据不统一的情况，一致性下降。多磁盘分散IO，性能提升，可用性上升。很容易增加备份磁盘，多个备份，磁盘损坏概率反比下降，鲁棒性上升。即为了A和P，放弃了C。

RAID5的情况是一份数据分散在多块硬盘上，另外保存一份校验数据以方便恢复。数据只有一份，不存在一致性的问题。数据读写的同时可能会需要生成 校验数据，影响速度，可用性下降。任何一块磁盘的损坏都可以通过剩余的磁盘中的数据和校验数据恢复，鲁棒性上升。即为了C和P，放弃了A。

对于传统的关系数据库的要求又不得不提ACID：

• 原子性 （Atomicity）数据和操作不可再次分隔
• 一致性（Consistency）操作结束后，仍可进行同样的操作
• 隔离性／无关性（Isolation）操作和操作不得影响
• 不可撤销（Durability）

“不可撤销”，“隔离性”，“原子性”都是限制鲁棒性和容错性的P，一致性本身就是C。剩余的A只能作为牺牲的指标。说得明显点就是目前尚没有什么 有效的方法让一条SQL同时在多台主机上同时执行正常。跨表SQL很正常，跨数据库操作已经够变态的了，跨系统进行SQL操作而且保证数据的实时和一致几 乎是不可能的。

对于传统的关系型数据库来说难度就是CAP三个之中在你需要任何一个的情况下，即便你愿意花钱去升级硬件，也必须以其他的下降作为代价。要么高可用（负载均衡），要么高安全（热备份），要么高容错（事务回滚），想要正比的升级来获取A是不可能的。

这些年大负载架构的出现带动了型数据库。类似memcache，bigtable和Hbase这类的key-value也是一大亮点。相比关系型的数据库而言，新的数据模型仍然无法摆脱这个魔咒，唯一的优势在于这些架构相对灵活，可以根据需要进行CAP取舍，找出真正适合的C 、A、 P比例。

本文摘自： %E8%BF%90%E7%BB%B4%E7%9A%84cap%E5%8E%9F%E5%88%99/#more-1480