虽然要求有区别但是我们看结果，支付宝微信会经常出现错误赔付的情况吗，如果错误率很低并且没有太大影响的话我倒认为所谓的“弱一致性”更好？是不是规则需要更改？

这个纠纷不是钱包和用户之间的，而是钱包和银行业务之间的对帐，因为数据异步交换，帐务出现差错，要追帐，查帐，纠错，不算人力成本，“纠错”就是赔付，你的支付宝 App 里显示 1000 块钱，你的实际账户里只有 800，这个200快钱哪里去了还不知道，但是支付宝得给你先补上。所以用户一般是感觉不到的。

跟软件没关系。大规模数据流处理，任何一个环节出现了点小 spike 就可能引起错乱。

做不好，又要省钱，那就只能将就呗。。。反正还有人支持lol

不是技术和成本考量参考新电信和m1弃用华为5G

你要知道一个系统里有很多中间件，Queue 也好，Kafka 也好，Redis 也好，都有各自的 Cluster setup，光每个中间件自己的 Cluster 之间的数据同步都不同保证 100% 一致，更别说把这些东西都放在一起。

你要想明白这个道理：自己做， 第一，等于左手赔付给右手，没啥意义。 第二，强一致性，出错的机率其实很少，但是如果自己做支付，每个月都要有一大笔赔付。这笔帐算的过来的。 所以要让一个跟自己完全没有关系的公司做钱包，赔付什么的，都是人家的。比如 Grab。

别瞎扯了，钱包支付又不是什么高级货，做不到大陆那种并发量，做个架构坡自己用是绰绰有余。

这就搞笑了。阿里腾讯也用这些啊。只不过人家的应用场景不同而已。 问题的关键不是坡做不出钱包支付， 而是阿里腾讯也做不出弱一致性的银行系统。

实事求是。第一，这个技术门槛很低的。我估计自己用 Go， 1，2个月就能弄一个完整的从里到外的架构，AWS/GCP failover，有钱就能 scale up，最简单不过的事。 第二，别把阿里腾讯想得很高大上，你要是读得懂代码，看看他们的 API 就知道是什么玩意儿了。 上行用 JSON 下行用 XML endpoint 居然都是拼音命名。 当然了，各种不规范不代表性能差，能用就行是吧？ 可是这种 API 要给人接入使用，不是找骂吗？ 以前有个段子： 让中美老印码农优化性能， 中国码农：研究各种算法， 美国码农：外包给老印 老印：增加服务器。 我觉得中国现在的技术公司，采取的手段越来越像老印。