时序约束
即对物品或对象在用户的两个动作之间的状态必须满足某种约束。
举例
电商系统中，用户浏览某个商品，把它放入购物车并结算这些操作都需要一些时间。有人认为，考虑到绝对的最佳用户体验，无论这个物品是否存在，都要在整个过程中使它保持统一的状态，即从浏览到某个商品开始到放弃购物车或者放弃结算之间都该商品在数据库中标识为“扣押”状态。
弊端
要保持上面例子中的状态的统一在分布式系统中往往比较困难，这样的约束性要求需要增加许多额外写操作(上面例子中用户在添加购物车或购买前会进行大量的商品搜索和浏览)， 多个读副本之间同步写库的操作会有一定的延时(哪怕只有几毫秒)， 难以保持各节点之间数据的完全一致。
CAP定理
CAP定理是分布式环境中设计核心的三点要求，单这三点要求不可能同时满足。
-
一致性(Consistency)
对于所有客户端，具有唯一的、最新的、可读的版本的数据，即用户看到的所有数据节点的数据是相同、最新的。 -
可用性(Availability)
每次请求都能获取到非错的响应, 即只要收到用户的请求，服务器就必须给出响应。在副本数据之间，内部通信不应妨碍更新操作。 -
分区容错性(Partition Tolerance)
部分节点不可用，操作也能完成。分区节点之间存在通信故障，系统仍然保持响应客户端请求的能力。
以上要求只能同时满足2个，CP或者AP。
BASE
CAP的解决方案的缩写叫BASE.
-
基本可用(Basic Available)
允许系统暂时不一致，这样事务就容易管理。 -
软状态(Soft state)
为了降低消耗的资源，可以暂时允许一些不准确的地方和数据变换。 -
最终一致性(Eventually Consistent)
在最后，当所有的服务逻辑都执行完成后，系统最后将回到一致的状态。
BASE有以下几个特点:
- 永远不会阻塞写操作
- 关注吞吐量而不是一致性
- 乐观的：如果一个服务失败，它最终还是会补做
- 一段时间内，一些报表可能是不一致的，但是不用担心
- 让事情变得简单并且避免锁定
BASE的核心逻辑就是放松时序时序约束。
ACID
要满足时序约束，往往需要实现ACID(原子性、一致性、隔离性、持久性)，代价非常高，而且影响性能和吞吐量。它的特点有：
- 正确的获取事务细节
- 在你工作时阻塞报表
- 悲观的： 任何事都有可能出错
- 详细的测试和故障分析
- 很多锁定和释放
总结
在一些很严格的关键领域采取严格的ACID事务，满足一定的时序约束，在其他很多领域对数据一致性要求不是很高的情况下使用BASE。
网友评论