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