作为一个架构师，有些规则是必须要掌握的，这就想软件的公理，如果你学物理不知道牛顿定律，那就不要学了。在软件行业也有类似的东西，我称之为软件定律。例如：
ACID,CAP,BASE
ACID
传统数据库系统中，事务具有ACID 4个属性
(1)原子性（Atomicity）：事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。
(2)一致性（Consistent）：在事务开始和完成时，数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改，以保持数据的完整性；事务结束时，所有的内部数据结构（如B树索引或双向链表）也都必须是正确的。
(3)隔离性（Isolation）：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的，反之亦然。
(4)持久性（Durable）：事务完成之后，它对于数据的修改是永久性的，即使出现系统故障也能够保持。
可以说，数据库系统是伴随着金融业的需求而快速发展起来。对于金融业，可用性和性能都不是最重要的，而一致性是最重要的，用户可以容忍系统故障而停止服务，但绝不能容忍帐户上的钱无故减少,而强一致性的事务是这一切的根本保证。
CAP
在2000的PODC（Principles of Distributed Computing）会议上，Brewer提出了著名的CAP理论。CAP指的是：Consistency、Availability和Partition Tolerance。
（1）Consistency（一致性）：一致性是说数据的原子性，这种原子性在经典的数据库中是通过事务来保证的，当事务完成时，无论其是成功还是回滚，数据都会处于一致的状态。在分布式环境中，一致性是说多个节点的数据是否一致。
（2）Availability（可用性）：可用性是说服务能一直保证是可用的状态，当用户发出一个请求，服务能在有限时间内返回结果。
（3）Partition Tolerance（分区容错性）：Partition是指网络的分区。可以这样理解，一般来说，关键的数据和服务都会位于不同的IDC。
CAP理论告诉我们，一个分布式系统不可能同时满足一致性，可用性和分区容错性这三个需求，三个要素中最多只能同时满足两点。三者不可兼顾，此所谓鱼与熊掌不可兼得也！而对于分布式数据系统而言，分区容错性是基本要求，否则就不称其为分布式系统了。因此架构设计师不要把精力浪费在设计如何能同时满足三者的完美分布式系统上，而是应该进行权衡取舍。这也意味着分布式系统的设计过程，也就是根据业务特点在C（一致性）和A（可用性）之间寻求平衡的过程，要求架构师真正理解系统需求，把握业务特点。
后来：CAP理论的作者终于给了我长久以来想要的答案：CAP理论并非严格的三选二，大多数情况下，A和C是可以兼得的，因为大多数情况下，P都不存在。
P只有在结点之间通信延迟大于可接受的范围时才出现（结点之间开始近似隔离，状态开始不一致），即P一旦出现，我们选择继续提供服务那么状态就肯定不一致，也就等于放弃了C；我们选择不提供服务，那么就等于放弃了A。通俗一点，P并不是目标，也不是手段，它是伴随着“多结点，网络，数据，共享”的要求而必然出现的，出现的原因是因为网络的不可靠性及结点通信延迟（延迟的原因可能是由于硬件，网络，或者压力太大而无法及时响应)。
弄清楚了CAP的P，也就弄清楚了CAP理论的实质，戴在头顶的紧箍咒便永久摘掉了。
CAP理论并不是要求我们悲观地放弃A和C任何一方，相反，它可以乐观地指导我们将C和A最大化；ACID和BASE分别处于CAP理论的两个极端，ACID强调强一致性，BASE强调高可用性，两者把重点都放在A和C上，淡化了P也可变的事实；通过对P的出现检测，发现P之后的限制和约束，P结束之后的补偿和恢复，通过采用千差万别的策略，我们可以避免P带来的C和A的严重损失，实现A和C的最大化来提高整个系统的正确性和可用性。ACID和BASE并非水火不容，我们可以在同一个系统中，既使用ACID，又使用BASE。
BASE
BASE来自于互联网的电子商务领域的实践，它是基于CAP理论逐步演化而来，核心思想是即便不能达到强一致性(Strong consistency)，但可以根据应用特点采用适当的方式来达到最终一致性(Eventual consistency)的效果。BASE是Basically Available、Soft state、Eventually consistent三个词组的简写，是对CAP中C & A的延伸。BASE的含义：
（1）Basically Available：基本可用；
（2）Soft-state：软状态/柔性事务，即状态可以有一段时间的不同步；
（3）Eventual consistency：最终一致性；
BASE是反ACID的，它完全不同于ACID模型，牺牲强一致性，获得基本可用性和柔性可靠性并要求达到最终一致性。
后面我会不断充实这本软件定律。
作者：arrowcat
出处：http://www.cnblogs.com/hustcat/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
本文为Gleasy原创文章，转载请指明引自Gleasy团队博客