大白话解释为啥分布式事务 CAP 不能同时实现？

解释之前，我们先举一个简单的但能说明问题的例子，后面的解释都是围绕该例子说的。

假设有一个新用户注册获取新人积分的功能，最开始 用户表 和 积分表 在同一个数据库，事务实现起来没任何问题。现在拆分成了 用户服务 和 积分服务 2个微服务，以上注册功能在业务层是先调用用户服务新增一个用户，再调用积分服务为该用户设置积分，因为是分布式服务调用，所以本地事务失效。

CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

一致性在上述例子中的体现就是“如果用户注册成功，则一定要看到自己的注册积分；如果看不到自己的积分，就不要注册成功，直接提示注册失败”。

分区容错性就是说在分布式环境下，要考虑任何一个微服务都可能出现“死掉”的情况( 当然也不一定是该服务真的死掉了，而是由于网络原因，无法被其他服务调通，等等其他原因。所以这里的死掉加了引号 )，所以考虑到网络情况复杂多变的不可控因素，一个分布式系统是必须能够容忍分区错误的，也就是支持分区容错性。如果某几个服务死掉了，不要对用户呈现出整个系统都死掉的感觉，因为网络环境复杂多变，比如积分服务死掉了，则上例中注册后设置积分肯定一直失败，如果该系统又必须支持一致性，所以注册也必须提示注册失败，因为设置积分一直设置不上，所以一直注册也会一直提示注册失败，也就是用户感觉到你的系统死掉了，也就是你的系统不支持可用性了，这就解释了为什么一个分布式系统如果支持分区容错性、一致性，就不支持可用性了。同理如果要求你的系统支持可用性，就算积分服务死掉了，也要绝大多数情况下让用户感觉你的系统没死掉，也就是可以注册成功，所以可以推理出，在业务代码中，只要调用用户服务新增用户成功，就要提示用户注册成功，而不管后面调用积分服务是否成功。有人会问为什么必须支持分区容错性，因为如果你的系统不支持分区容错性，也就是表示你的系统是单机系统，就不是本文考虑的范围了。如果一个很牛逼的人物，像钢铁侠、蝙蝠侠、马斯克那种高智商富豪，声称自己的分布式系统不支持分区容错性，也就是各个分区根本不会发生错误，可以设想一下，物理上位于纽约市的用户服务和洛杉矶市的积分服务之间肯定不能是无线的，肯定得是有线传输介质，并且就算有人知道哪里埋了一根这种介质，挖出来之后也砍不断，用黄石火山的熔岩也无法摧毁，。。。。先别说有没有这样的传输介质，就算有的话，这个所谓的分布式系统其实就是更加宏观的单机系统，就像把一个电脑的机箱拆开，把 cpu 扯到纽约，把磁盘扯到洛杉矶，然后总线变得特别坚固。