自己原文公众号： https://mp.weixin.qq.com/s/wsh1JwBv5uA3eDJzP4evBw
这几天深入学习一下。这个分布式系统的一个协议。分布式系统顾名思义就是要分。但是分布式又要保证在分的情况下还要一致。这个就难了，如果不考虑一致，随便。
保持数据同步的一种方法是在多个节点上同时更新数据。如果我有3台机器做一个分布式系统。我只写第一个（一只羊薅羊毛）。那么另外两个把这些数据一次镜像过去就结束了。这个难度相对较小。所以MySQL的MGR不少都是单主模式。
但是如果每个点写入就难度大了。需要有一个协调者，但是协调者就一个如果处理不过来或者坏了怎么办？所以要多个协调者。
有了多个协调者问题解决了吗？其实问题更大了。当有一块表我们知道时间，当有两块表我们不知道时间。有的人会说选出一个leader。可以。但是这是leader flower模式，就像主从。我们说的是并行写入。Oracle的RAC是集群，而ADG就不是。因为ADG的DG是不可以写的。当然Oracle19C开始可以写了。那是表面。其背后原理是从库接受写的请求，但是不马上直接，给主库送过去，主库执行了，再给从库。这才能保证一致性性。否则直接写从库就不一致了。所以目前RAC的这个架构还没有能打破。
那么当1 2 3号机器一起被写，如何处理。假如有个值它是10，在1号机上把它改成3 ，在2号机上改成5.那么最后看到的是几？3or5？这取决于执行的顺序。如果是先3，那么结果是5，如果是先5那么结果是3.因为一个机器处理完毕要送给其他机器。后面覆盖前面的。
要想一致只有一个办法，每个机器接收到指令然后进行全局的协调排序。这里注意一下当多个分发器以后我们不能保证顺序。消息队列的写入顺序一定是读取顺序吗？问题越来越难解决了。
解决方案是设定锁，然后排序。天啊，多少人单机的锁都没搞定，现在又是多协调锁。这就是我们听过的分布式锁。有了锁，那么就有死锁。（锁等待还好办一些）设定优先级（你看又多了一个环节），单机的死锁有人都跨不过去。这回锁又多了，又复杂了。
所以我一直说单机是最好的架构。（考虑高可用容灾的话，做集群或者主从）单机没有这些问题。
那有人说单机数量量大处理不了怎么办？答案见我上一篇公众号。
除了大厂的数据量以外，我们一般的系统如果说单机数据量大处理不了。那么放心、集群的也处理不了。多花一些精力在数据库设计和逻辑实现上吧。
