分布式架构--数据一致性

分布式架构---数据一致性

　　分布式架构下的数据一致性存在很多问题：1.跨系统间分布式事务如何解决？2.系统内多个服务的分布式事务如何解决？3.一个服务内多个数据源/数据库的分布式事务如何解决？等等问题。

　　域是一个虚拟的分类，几个系统属于某一个域，例如网上银行和手机银行都属于电子渠道领域；

　　传统的单体应用，指的就是系统，在微服务架构下，单体应用采用前后端分离模式，前端一般使用 Nginx，Ngnix 进程间采用主备模式，系统的后端可以分为多个应用，每个应用有一组对等的应用进程（也称为应用实例）提供服务，每个应用对应一个数据库，实际上在分库的情况下，有可能一个应用对应多个数据库。复杂一点的是网关，网关由一组对等的网关实例组成，如果多个系统共享一个网关，网关和系统就是1对多的关系，也可以一个系统独享一个网关，就是一对一情况，

　　系统间的数据一致性、系统内应用间的数据一致性、应用内部对应多数据库的数据一致性，另外可以增加一个数据库对应多个应用的数据一致性，处理以上情况：需要我们总结归纳，往往希望首先确定原则，这里的原则是从业务的角度进行分析，而不是考虑技术的可能性，因为技术的可能性无穷无尽，是一个无限组合，理论上任何情况都能发生，考虑所有情况就是不现实了，必须根据业务的特征进行归纳。称为数据一致性而非分布式事务就是这个道理，从业务角度目标是解决分布式情况下的数据一致性，而不是技术角度看的分布式事务。

　　①系统间的数据一致性

　　　　需要服务实现 TCC或者业务补偿模式，由框架（业务协调器）自动调用，减少人工参与，或者实现幂等服务，反复投递。这两种方式都没法做到数据的 100% 一致，在失败的时候都需要有重试的机制，例如补偿失败要重试（这就是框架的好处），多次重试还是失败，记录失败历史，业务上人工处理。不要害怕人工处理，只要减少人工处理的机会。

　　②系统内应用间的数据一致性

　　　　建立一个共享的事务协调器模式，用共享的事务协调器模式，记录服务调用的事件，在合适的时机调用TCC和补偿服务。

　　③应用内部对应多数据库的数据一致性，是个反模式，不要做通用方案

　　　　一般来说，一个应用对应一个数据库，不允许一个应用对应多个数据库，多个数据库的情况应该分成多个应用，通过服务调用方式解决，这是一个基本原则，否则就是一个反模式设计。让设计者必须在架构解决，不是利用技术手段解决不合理的架构设计。

　　④一个数据库对应多个应用的数据一致性

　　　　共享一个数据库，可以把应用放在一起，一个模块部署过于频繁，单独拆出来做一个应用，那也应该和多应用多数据库一样处理。

　　　　参考文章：原文