We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
InfoQ 微服务数据一致性的演进:SAGA,CQRS,Event Sourcing 的由来和局限: https://www.infoq.cn/article/vpngea7ftks1tkdjpsyp
白小白: 讲微服务数据一致性的文章,网上比较多。此前 EAWorld 与发过几篇,包括《微服务架构下的数据一致性保证(一)》、《微服务架构下的数据一致性保证(二)》、《微服务架构下的数据一致性保证(三):补偿模式》,以及《使用消息系统进行微服务间通讯时,如何保证数据一致性》。本篇文章在我看来,是从一个纵向的维度把相关的一致性概念的演进过程,讲的比较清晰,简单的逻辑是这样的: 1、分布式带来一致性挑战; 2、2PC 效率太低,选择 SAGA 保证最终一致; 3、SAGA 的补偿环节可能失败,需要进行对账; 4、对账需要日志,需要记录日志; 5、用更改优先的方式记日志,更适合跨域操作,域内推荐事件优先; 6、用事件优先的方式记日志,即属于 CQRS 的一种模式; 7、CQRS 或者事件优先,也有并发和乱序的挑战,很难实现; 8、退而求其次,可以采用“设计一致性”; 9、实在无法一致,那就接受不一致。
白小白:
讲微服务数据一致性的文章,网上比较多。此前 EAWorld 与发过几篇,包括《微服务架构下的数据一致性保证(一)》、《微服务架构下的数据一致性保证(二)》、《微服务架构下的数据一致性保证(三):补偿模式》,以及《使用消息系统进行微服务间通讯时,如何保证数据一致性》。本篇文章在我看来,是从一个纵向的维度把相关的一致性概念的演进过程,讲的比较清晰,简单的逻辑是这样的:
1、分布式带来一致性挑战;
2、2PC 效率太低,选择 SAGA 保证最终一致;
3、SAGA 的补偿环节可能失败,需要进行对账;
4、对账需要日志,需要记录日志;
5、用更改优先的方式记日志,更适合跨域操作,域内推荐事件优先;
6、用事件优先的方式记日志,即属于 CQRS 的一种模式;
7、CQRS 或者事件优先,也有并发和乱序的挑战,很难实现;
8、退而求其次,可以采用“设计一致性”;
9、实在无法一致,那就接受不一致。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
The text was updated successfully, but these errors were encountered: