自己原文公众号： https://mp.weixin.qq.com/s/2uMMrT5RO0vabXWtkDsxGw
1870年9月6日，英国皇家海军铁甲舰“船长”号，在第一次航行中就遇到风暴而沉没，船上473人丧命。
这艘军舰为什么这么弱不禁风呢？
事故调查发现：首先，“船长”号以蒸汽机作为动力，又画蛇添足地安装了风帆桅杆;其次，工人们在造舰时唯恐用料不足，大多数零件的重量超出设计标准，导致完工的军舰整体重量比设计重量多出了747吨;最后，两门旋转炮塔导致军舰上部过重，重心上移，稳定性欠佳。遇到风暴，这艘号称当时最先进的铁甲舰就这么沉没了。
从此以后，炮塔铁甲舰都取消了风帆设备，只保留一根军用桅杆用来发信号、打旗语。每一个零件的重量都必须符合设计要求，安装的每一步都必须符合图纸的规定。因为血的教训告诉我们：复杂和多并不意味着完美，反而是隐患。
有一句话说得好：“如无必要，勿增实体。”意思是说：“切勿浪费较多东西去做，用较少的东西，同样可以做好的事情。”
我见过一个厂家设计了一套系统有三台机器ABC。
A上安装clickhouse、B上安装clickhouse、C上安装clickhouse其实就是clickhouse的集群。
同时A上安装kafka、B上安装kafka、C上安装kafka，其实也就是kafka的集群。
同时A上安装mongodb、B上安装mongodb、C上安装mongodb。其实也就是mongodb的集群。
以上操作看明白了吗？就是3套数据库和中间件都是分布式的安装在3台机器上。每个上面都有3样，我当时看不明白了。就问为什么要这样设计？答案是说写入数据要写入mongodb，然后要写入分析的列式数据库clickhouse。那为什么要加个消息队列呢？说是怕写入来不及。其实我对此是大跌眼镜的。一般来说数据库的写入瓶颈在IO。我们先不说有没有那么大的量。一般来说99.99%的系统写入都不是问题。问题主要是读。那么假设他真的出现来不及写（恭喜你业务已经是全国第一梯队的了），那么这个时候每台机器上都是mongodb、kafka和clickhouse在竞争，这好的了吗？
而且还要考虑一下，写入消息队列一次消耗，在读取一次，有一次消耗，最后还是要写到数据库（clickhouse），比起直接写还多了两次操作，和多了一个环节。（很多消息队列是一次写多次读也就算了，还算是用在正道上）。每个都是好东西，放在一起，怎么就觉得那么别扭呢？
以上如果是我的话直接写入clickhouse就行了。我见过太多的都是为了用而用，浪费不说，还增加了复杂度。花架子太多，华而不实。据我所知，财付通2005年单机MySQL4.1 每天10万笔交易。现如今有多少公司用的是MySQL8、Oracle19C、PostgreSQL13，还是集群。还远没有到这个业务量。
