这是我参与8月更文挑战的第7天，活动详情查看:8月更文挑战
前言
数据一致性,一般都是多个系统之间或者多个数据库之间存在的数据一致性问题
在分布式系统中,一致性是在讨论的是系统内的一份逻辑数据存在多个物理的数据副本时,对其执行读写操作产生的结果。
在数据库中,一致性和事务是紧密相关。在分布式数据库中一致性，实质上是在谈论数据一致性和事务一致性。
数据一致性
强一致性（线性一致性）
- 分析：更新操作完成后，任何多个后续进程的访问都会返回最新的更新过的值。即，用户上一次写什么，下一次保证能读到什么
- 场景：支付功能，支付钱后，账上的余额需要实时更新，重新读取账上余额时，读取到的是已更新后的金额。
弱一致性
- 分析：系统在数据写入成功后，不承诺实时，立即读取到最新更新的值，也不保证何时可以读取到更新到值
- 场景：用户读到某一操作对系统数据的更新需要一段时间。比如，完成某项测验之后，需要过段时间才能读取到测验报告
最终一致性（弱一致性的特例）
- 系统更新数据之后，所有的数据副本，在经过一段时间的同步之后，最后能够达到一致的状态。最终一致性的本质是需要系统保证最终一致性，而无需即时一致性。
- 最终结果达到一致性，而过程中，在没有故障前提下，主要受到的影响可能是网络延迟、系统负载或同步多个副本影响
最终一致性根据其提供的不同保证划分为更多的模型
因果一致性
- 分析：有因果关系的操作顺序，前置进程处理后再由后置进程处理。
- 场景：进程A更新某数据之后通知进程B，那么进程B获取到进程A更新后的数据，如果进程B对该数据进行操作都是基于进程A更新后的最新值
会话一致性
- 分析：对系统数据的访问过程框定在一个会话当中，约定了系统能保证在同一个有效的会话中实现“读自己所写”的 一致性。
- 场景：有分布式的session一致性的问题
总之，在实际业务场景中，不同业务对数据的不一致性的要求是不一样的，往往我们可以依据ACID和Base理论使用。
