从前有座山，山里有座庙，庙里有三个和尚。一个和尚挑水吃，两个和尚抬水吃，三个和尚没水吃！后来，故事有了延续。
总寺庙的方丈得知山上穷的连水都吃不上之后，就派来了一名主持和一名书记，共同负责解决这一问题。（这里像不像我们现在的系统？说什么一台机器处理不了大数据，一台机器支持不了业务。我总觉得我们一天人就86400秒。出去了吃喝拉撒以及必要的睡觉以外，那些时间并不多，留给百度、京东、淘宝还有抖音、游戏、头条等等剩下没多少时间。我们有多少业务每天上亿订单？估计全国99%的系统都一天不过1万笔核心业务。毕竟下图是来自于一台机器，这种还是极少数。）
所以单机处理不了的场景，不是没有，很少。继续。主持就任后，发现问题的关键是管理不到位，于是新招聘了两个和尚，成立寺庙管理部来制定分工流程。为了解决收入问题，寺庙管理部和人力资源部召开两天一夜头脑风暴会，最后决定：成立专门的挑水部负责后勤和专门的烧香部负责市场前台。（像不像我们现在系统前台、中台、后台？）同时，为了更好地开展工作，寺庙提拔了两名和尚分别担任副主持、主持助理，并在每个部门任命了部门小主持、副小主持、小主持助理。（像不像我们现在主节点、从节点？）
老问题得到缓解，新问题接踵而至。前台负责念经的和尚总抱怨口渴水不够喝，后台挑水的和尚也抱怨人手不足、水的需求量太大而且没个准儿、不好伺候。（像不像一致性没有了？）为了更好地解决这一矛盾，经开会研究决定，成立一个新的部门：喝水响应部，专门负责协调前后台矛盾。（来了个协调机制，像不像控制一下两阶段提交？）为了便于沟通、协调，每个部门都设立了对口的联系和尚。协调虽然有了，但效果却不理想，仔细一研究，原来是由于水的需求量不准、水井数量不足等原因造成的。（像不像需求不明确前后%，或者SQL与需求不等价，没要全表查询但是实际上全表查询了）
由于部门太多、办公场地不足，寺院专门成立了综合监察部来解决这一问题，最后决定把寺院整个变成办公区，香客烧香只许在山门外烧。（必须增加资源了，上云，而且还要控制需求）部门多，领导多，文件和开会自然就多，为了减少文山会海，综合办牵头召开了N次关于减少开会的会，并下达了“关于减少文件的文件”（上云以后发现成本还高了，毕竟云是吞金的。自己采购是一次性问题，云是年年收割）。有人做过统计超过50台机器，用云比不用云贵。这是从市面上各家成本分析的。
此外业务还是有痛点。问题在哪呢？有和尚提出每月应该开一次分析会，于是经营分析部就应运而生了。（这里需要一个大数据）。大数据来源是哪里？是业务系统。怎么来？八仙过海各显神通了。有用ETL的有用CDC的。分析需要很多数据和报表，可系统总是做不到，于是每个部门指派了一些和尚手工统计、填写报表、给系统打工。
寺院空前地热闹起来，有的和尚在拼命挑水、有的和尚在拼命念经、有的和尚在拼命协调、有的和尚在拼命分析……忙来忙去，水还是不够喝、香火钱还是不够用。到底什么原因呢？好像数据还是对不上。接口还是慢。队列异步，数据不一致了。数据同步卡主了。只有三个人最清楚问题关键所在，那三个人就是最早的那三个和尚。早知今日，后悔当初咱们仨自觉自律一点算了。（SQL写的好点，一台机器搞得不就好了吗？）
本文虽然原创，但是引用实在过多。只有括号是原创。下面就整段引用了：以上如果还不理解，那么给没接触过计算机的人看看这样行不行？来源于https://mp.weixin.qq.com/s/u1zF-AfJMofkgE8HiIxj_g
分布式 DB 愚人节笑话一则
如果是单体数据库你直接敲门，人家问一句谁，你回答我，然后开门。
如果是分布式数据库，那么结果是这样的
1 你敲门
2 门岗看了看你，问你谁呀？
3 你说我呀，我要找李主任
4 门岗说，哪个李主任，哪个部门的
5 你说，内勤的李主任
6 门岗说，等着我看看，李主任是男的女的
7 你说，男的，男的，男的
8 门岗说，等着，我打几个电话确认一下，打了几个电话，然后告诉你，等会，李主任在开会，你坐那等会
9 你说多长时间，门岗说，那我哪里知道，木桶原理，你知道李主任的36条腿哪个最慢，哪个最慢的就是你要等的时间。
10 最终，李主任带着36条腿，砰砰跳跳的到你面前说，久等了
此时你终于见到了李主任，太不容易了。
说道这里已经4：18AM了。
如果我们是那个全国的1%，体量实在太大，每天上千万订单。应该考虑分布式数据库。Oracle、MySQL、PostgreSQL、TiDB都有解决方案。如果我们单体能妥妥解决，最小的代价是提高程序质量，不仅能稳定，而且还能降本。这种场景下就一套高可用架构，配上合适的硬件就行了。
