关系型数据库:强一致性;
NoSQL: CAP原理与 最终一致性。
5.1 更新一致性
在单服务器数据库中,用序列化的方式保证一致性。
在集群环境中,数据有多分拷贝,必须要用“顺序一致性”保证所有节点以相同的顺序执行。
5.2 读取一致性
关系数据库用“事务”来解决读取一致性的问题。(不让一个读取操作读取到另外一个操作的中间结果。)
部分NoSQL数据库不支持事务。
面向聚合的数据库通常支持“原子操作”,但仅限于单一聚合内部。如果把订单、运费、商品全部放入一个订单聚合中,则可以避免“逻辑不一致”
我们不能把数据都放在一个聚合中,所以在执行影响多个聚合的操作时,会有一段“不一致窗口”,数据最终会一致,叫做“最终一致性”。在数据存在冗余的集群中,这个不一致窗口可能比较长。
“黏性会话”:保证情况都发到一个节点。
5.3 放宽“一致性”约束
事务影响性能,很多数据库弃用事务,放宽一致性需求。
CAP定理:一致性,可用性,分区耐受性(发生通信故障,导致整个集群被分割成多个无法互相通信的分区时,也就是脑裂,集群任然可用。)
不一致的问题,一般是可以容忍的,不能完全以来开发,更需要业务领域专家。
5.4 放宽“持久性”约束
把一些信息存储到内存中(比如用户会话)以提高相应速度 ,带来的问题是,内存数据可能丢失。