尽可能减少系统中的时序约束。当你想添加一个约東，使某个物品或对象在用户的两个动作之间维持某个状态时，放松业务原则中的约束。由于大多数RDBMS的ACID属性，扩展具有时序约束的系统非常因难。

在需要添加约東时，例例如让物品从用户看到它们直到用户购买它们都存在，要认真考虑。虽然某些特殊情况可能会令客户失望，但是弥补客户比起不能扩展来说容易得多。

在数学和机器学习(人工智能)领域，有一套约東满足问题(CSP)，其中的对象必须满足某些约束。CSP通常复杂度很高，需要启发式搜索和组合式搜索方法结合才能解决的。两个经典的CSP难题是数独游戏和地图着色问题。数独游戏的目标是填写一个大九宫格，每行每列都有9个单元格，大九宫格可以分为小九宫格，要在每个小九宫格中填入1到9的数字，使得大九宫格每一行和每一列的数字都不重复。地图着色问题是对地图进行着色，使相邻的地区具有不同的颜色。



CSP问题还会衍生出时序约束满足问题(TCSP)，其中变量表示的是事件，约束表示两个事件之间可能的时序关系。这类问题的目标是确保变量间的约束，决定满足约束的各种场景。对变量强制实行本地一致性，可以确保问题中的所有节点、弧和路径都满足约東。机器学习领域和计算机科学中的很多问题都可以建模为TCSP，如机器视觉、调度、平面布局设计、SaS系统中的用例等，都可以看作是TCSP。

常见的SaS应用中的时序约束的例子是用户购买一个物品。用户浏览该物品，把它放入购物车并结算，这些操作都需要一些时间。有人认为，考虑到绝对的最佳用户体验，无论这个物品是否存在，都要在整个过程中使它保持统一的状态。要实现这一点，就需要在用户关掉该页面，或者放弃了购物车，或者结算之前，把该物品在数据库中标识为“扣押”的状态。如果我们站点的用户数不多，这种方法简单实用。对用户来说，在把物品加入购物车之前，浏览了100个或更多的物品是很常见的。我们的一个客户声称，他们的用户在把一个物品加入购物车之前，要浏览500多个检索结果。对于这种情况，我们的应用可能需要几个数据库的读副本，使得更多的人能够检索和浏览物品，而不是购买物品。这样就产生了问题，大多数 RDBMS难以保持节点间的所有数据完全一致。即使数据库的读副本或者从数据库在数据一致性上只有几秒钟的差别，还是会产生特殊情况，例如两个用户都想查看某个物品，而它只剩下最后一个。后面我们会来解决这个问题，但是首先让我们看看为什么数据库会造成这个问题。

造成RDBMS难以进行分布式扩展的属性是一致性。CAP定理，又称为布鲁尔定理，是以计算机科学家 Eric Brewer的名字命名的，它描述了在分布式环境中设计应用的三点核心要求，但这三点要求不可能同时满足。这三点要求用缩写CAP表示。

一致性(Consistency)--客户端发现一组操作同时发生了

可用性(Avalability)一一在收到计划中的响应后，任何操作都要终止。

分区容忍性(Partition Tolerance)-即使个别组件不可用，操作也会完成。
 
这个问题的解决方案叫做BASE，是解决CAP的架构的缩写，代表基本可用(Basic Available)、软状态( Soft State)和最终一致性(Eventually Consisten)通过放松、一致性的ACID属性，在扩展性方面可以得到更大的灵活性。采用BASE架构可以使数据库最终达到一致。这可能只需要几分钟，甚至几秒钟，但在前面的例子中我们看到了，如果应用程序希望能够“锁定”数据，那么即使几毫秒的不一致也会造成问题。

放松时序约束可以重新设计我们的系统、从而使它能够达到最终致性。用户刚浏览过一个物品，不能确保该物品还存在。只有把该物品放入购物车，应用才会锁定数据，锁定操作会在主写入副本或主数据库中执行。由于我们具有ACID属性、所以可以确保如果交易完成了，就可以把该物品的记录标志为“锁定的”、然后用户就可以继续放心购买了因为该物品已经为他们保留了。而对其他浏览该物品的用户来说，它则可能还有，也可能没有了。

另一个常常发现时序约束的应用领域是转移物品(钱)或在用户间通信。在单一数据库中，很容易确保用户A把钱、消息或物品转移到了用户B的账户。把数据分布到多个数据副本上，使得保持这种一致性变得很困难。解决这种问题的方法是不要希望对即时转移操作有时序约東。让用户A在看到用户B转给他的钱之前等待几分钟，是完全可以接受的原因很简单，转移物晶的双方通通常不会在系统中同步转移物品。显然与同步通信不同，如聊天。你很容易在网站设计系统中加人时序约束，因为看来，这能提供最好的客户体验。但是，在添加时序约東前，最好考虑一下这样做产生的长期问题，因为这种约東有可能使得系统扩展变得很困难。