一文轻松了解分布式开发中的一致性问题

随着业务复杂性逐渐增强，项目的主体架构也从原本的ALL IN ONA 的单体结构，转化为现在流行的微服务架构，随着业务的拆分，随之而来的便是数据一致性问题，当数据库拆分后，便很难通过事务机制对数据做统一管理，那么在分布式开发中，数据一致性问题都有那些那，今天我们一起来看一下吧！

CAP理论

在分布式数据系统开发过程中，有一个绕不开的话题，那便是著名的CAP理论，在 CAP原理中，有三个要素，

• 一致性(Consistency)
• 可用性(Availability)
• 分区容忍性(Partition tolerance)

在CAP理论中，这三个要素最多只能同时实现两点，不可能三者兼顾，今天我们要聊是便是数据一致性问题。

一致性就是数据保持一直，可以理解为多个节点中数据的值是一致的，一致性又可以分为强一致性与弱一致性。对于一致性，可以分为从客户端和服务端两个不同的视角。

从客户端来看：一致性主要指的是多并发访问时更新过的数据如何获取的问题。多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。

从服务端来看：则是更新如何复制分布到整个系统，以保证数据最终一致。一致性是因为有并发读写才有的问题，因此在理解一致性的问题时，一定要注意结合考虑并发读写的场景。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。

强一致性

也称为原子一致性、线性一致性。强一致性可以理解为在任意时刻，所有节点中的数据是一样的。同一时间点，你在节点A中获取到key1的值与在节点B中获取到key1的值应该都是一样的。任何一次读都能读到某个数据的最近一次写的数据，系统中的所有进程，看到的操作顺序，都和全局时钟下的顺序一致。

顺序一致性

任何一次读都能读到某个数据的最近一次写的数据，系统的所有进程的顺序一致，而且是合理的。即不需要和全局时钟下的顺序一致，错的话一起错，对的话一起对。

弱一致性

弱一致性包含很多种不同的实现，目前分布式系统中广泛实现的是最终一致性。

最终一致性

最终一致性是弱一致性的一种特例，保证用户最终能够读取到某操作对系统特定数据的更新。但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。也可以简单的理解为在一段时间后，节点间的数据会最终达到一致状态。