CAP和手表
说个多年前的事情，我经历过一个场景。说一个公司下属N个公司，希望在母公司网站注册的用户，可以直接登录子公司所有网站。同样子公司网站注册的可以登录其他子公司网站及其母公司网站。说白了就是任何一个注册上下左右的都要同步过去。事情是好事情，用户体验好啊。实际运行起来完全不是按照剧本来了。
今天说怎么这里注册的没同步过去，明天说怎么同步有延迟，后天说为什么这里注销了其他还可以，再后面说怎么推过来重复的数据？结果用户体验反而不好。问我有没有办法解决。我了解了一下这个系统。
一个地方注册以后，通过接口推送。 （接口写的好坏这想都想得到）然后中间再有解耦、消息队列什么的。 本 来 一件简单的事情，一定要高大上。 就好比现代战争是陆海空一体化的，哪怕是打一个小村庄，不用巡航飞弹、战略轰炸机以及钢铁洪流和外太空的制导，这就打不下来一样。 好在发现了一个值得庆幸的事情，也是解决问题的基础。 即母公司和及其子公司都是在一个数据库实例下的不同schema。 这就为解决问题创造了无可比拟的前提条件。 但是 却 忽略了一个最大的问题，就是一致性。 在分的前提下（P） 一致性和可用性，只能满足一个。
解决方案就是说服各个开发团队，放弃自己的用户注册。只用一个共有的用户表。所有注册、审核和注销全部在这个上面完成。涉及到会员的增删改查全部通过schema授权的方式解决。接口（说白了不就是去DML一下数据库嘛）。大家按照我说 的改了以后。结果就是，再也没有人反馈过之前的所有问题。而且还发现各个系统之间的效率提升了100倍。（没有接口、没有网络、没有消息队列实际上不必要的环节能不快吗？）
我本人不是说反对使用接口和MQ，只是觉得必要再用。非必要不使用。都是成本啊。在当下大家都在说分布式的环境下，我依然觉得至少国内绝大多数系统集中式就能解决。如果非要硬拆开，那么代价是非常大的。谁维护谁知道。当集中式处理不了的时候再拆（这里说的处理不了是真的处理不了，不是SQL写的烂的处理不了）
CAP模型就是分了以后，要考虑的就要更多了。当你有一块手表的时候，哪怕时间不准，你也知道时间，但是当你有两块的时候，如果两块手表的时间不一样，你是不知道时间的，因为你不知道该看哪一块，准确来说，你不知道哪一块的时间才是准确的，哪怕里面有准确的。当一个系统有上下游关系的时候，一致性是最重要的没有之一。分库一时爽，不一致让你一 直“爽”。
当自己的系统和外部（这里的外部是真的不可能触摸到数据库的才叫外部），那是必须用接口了。接口本来就是保护数据库不被直接访问的。如果在一起的烟囱数据库，那么合则生，分则死（累死）。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/637517/viewspace-2899311/ ，如需转载，请注明出处，否则将追究法律责任。
