小白学分布式程序开发4-数据一致性模型

数据一致性模型

1、强一致性

■强一致性可以理解为在任意时刻，所有节点中的数据是一样的。同一时间点，你在节点A中获取到key1的值与在节点B中获取到key1的值应该都是一样的。

当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。但是这种实现对性能影响较大。

举例>>zookeeper服务、MySQL集群中主备机数据的一致性。金融领域中资金账务的强一致性要求。

2、弱一致性

■系统并不保证续进程或者线程的访问都会返回最新更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。但会尽可能保证在某个时间级别（比如秒级别）之后，可以让数据达到一致性状态。

使用场景：适用于某些一致性要求较低的场景。

比如：支付宝中有个蚂蚁森林的应用，很多小伙伴都在上面收能量种树，其中最大的乐趣就在于可以偷好友的能量。小明同学也是其中一员。当小明看到自己的能量球的显示为250g时，感叹，哇！能量好多啊（偷笑），成就感十足。但此时是个只读操作，一致性要求不需要那么高，显示给小明看到的是250g能量，那么延迟几秒也没有关系，如果小明去点击收取的话，在点击小球的瞬间，后台系统会要求进行一致性检查，一查只剩下125g了，此时小明同学真是欲哭无泪啊~~T_T，几欲仰天长啸，哪个贪心的小偷，偷了那么多啊~~（有时更甚，只剩几克）看来我们的小明同学要及时收取他的能量啊。

上述例子中，可以采用NoSQL来实现缓存处理，目前用的比较多的是memcached，redis，MongoDB等。

3、最终一致性

■就是不保证在任意时刻任意节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。也可以简单的理解为在一段时间后，节点间的数据会最终达到一致状态。

举个例子： 对于最终一致性最好的例子就是DNS系统，由于DNS多级缓存的实现，所以修改DNS记录后不会在全球所有DNS服务节点生效，需要等待DNS服务器缓存过期后向源服务器更新新的记录才能实现。

目前的分布式系统大量采用最终一致性的方案来解决分布式事务问题，我们将在以后的文章中详细学习分布式事务的实现方案。

在以后的文章中我们将详细学习分布式事务的实现方案，敬请期待哦。

最后别忘了关注我们的微信公众号！谢谢*o*！