Spring Cloud那一套，是怎么处理数据一致性问题的？

问题:

Spring Cloud那一套，是怎么处理数据一致性问题的？
如果用zookeeper那一套，就不用担心这个问题，因为zookeeper就是解决一致性问题的，
但是如果不用zookeeper这个分布式协调组件呢？？？
Spring Cloud全家桶里，有没有什么组件是完成这一点的？？？

回答1:

orz，我错了~~又TM想太多了~~
原来我举的例子所表征的是一种极限情况，其实像这样的情况还可以无限延伸下去，没完没了了！！！
就算是上升到理论层面：2PC、3PC、Paxos、ZAB这些算法中的任何一种，都不能保证——绝对的——一致性；
只要是在分布式环境中（多个节点通过网络通信的环境中），你总能找到某一种情况，造成数据的不一致！！
所以，答案俩字————无解！！
那么网上那么多人在那里喊得那么大声的各种数据一致性解决方案，又是什么情况噜？？？
其实那只是默认网络情况不出现较极端异常的情况下，提出的——尽可能保证一致性——的方案。（这样说才对！）
那么，如果强行回到我举的例子中，该怎么办捏？
其实现实环境中是这样的：
根本不是遇到这样的问题时，才去解决！而是尽量通过合理设计，使这样的情况不发生！
也只是“尽量”！！！
但是如果真的发生了呢？！
那时候就该查日志查日志，该赔钱赔钱了尽量把事情嘎平呗~~
不过！
万幸的是，在现代分布式软硬件架构已经有了很多较为成熟的方案的今天！这种情况本身出现的概率也很低了！！
so，很多人都默认不鸟这个问题了....................
so，Spring Cloud那套，其实从根本上讲也是不管这个问题的，
它只是鼓励我们通过合理设计“绕开（使之不发生）”这个问题！
不只是所谓的“重试”这一机制，还有各种方案，反正总之就是通过人为的方案设计去“尽量”解决（绕开）问题而已！
用我举的例子来说，就是——比如不要只搞Y1、Y2两个实例，
可以搞到Y1000甚至更多，1000个实例都挂的概率够低了吧？
（这里我又忍不住想发散一下——那zookeeper那套还搞什么通知回滚，其实也只是另一种的“尽量解决方案”，
因为你回滚也未必不会出现某几个节点通知到了，某几个没通知到的情况，这里不再赘述了）；

回答2:

https://www.cnblogs.com/sam-uncle/p/8954401.html