
2026,1月1日元旦当天诚利和 ,中国银行APP故障:

故障原因,先有消息说因为连接池满、无法与建立新的连接导致。
但进一步暴漏的信息,这里的“连接池”是数据库内的线程池BUG,导致上层应用无法和数据库建立连接,问题直指GaussDB。
现场曾重启数据库、的相关人员也介入解决问题,但故障依久,最终故障持续了超过1个小时,才恢复正常。
我对故障具体细节并不关心,去年(2025年)金融行业IT基础设施问题频发,四大行有两家都未能幸免(工行与中行),支付宝更是在2024双11后,又于2025双12出问题。细看每一次故障原因各不相同,每一次故障也都有独自的特点。
托尔斯泰在《安娜.卡烈林娜》中有一句流传很广的名言:“幸福的家庭千篇一律,不幸的家庭各有各的不幸”。
对应技术层面:“不宕的系统一直运行,宕机的系统各有宕机的原因”。
分析每家故障的原因,试途寻找“中行APP故障原因”、“工行APP故障原因“,“支付宝双11/双12故障原因”,就像分析“这个家庭为什么不幸福”、“那个家庭为什么不幸福”一样没有意义,因为“不幸的家庭各有各的不幸”。
不如提高视角,问一个共性的问题:“为什么现在会有这么多故障”?“我们走错了方向吗”?
这个问题太宏大,我还要聚焦焦,只讨论现代商业管理系统吧。我在这篇中,用最直白的话解释过了,这么多故障的根因,就是数据库不强。
因为数据库不强,不得不把更多的压力转移到上层(应用层),导致应用层架构复杂,出现问题的概率,大大增加。
而且复杂的架构,导致高可用切换行同虚设,事到临头时,无法确保数据一致的切换,导致每次故障时间都是以“小时”为单位。
从底层硬件、操作系统,到数据库,再到中间件、上层应用系统,这一整套现代商业管理系统,是美帝摸索了几十年探索出来的技术路线。
单说数据库,从上世纪七零年代做为一门独立的软件门类开始,到现在发展已逾50多年,美帝在这方面有着深厚的积累,华为又不是上帝,数据库又只是华为的支线业务,比不上美帝本不足为奇。只要我们的技术方向不错,追平美西方就不是问题。
但关键就是,我们的技术方向错了。
这么频繁的故障频率诚利和 ,四大中两家不足三个月内,接连出问题;
中小银行我都懒的说,故障时间都以“天”为单位了;
支付宝在敏感时间点接连出问题,要是还觉得一切OK,就当我啥也不懂吧。
我们在用开发应用层软件的方法,开发基础软件。先不要急着反驳我,下面我证明给你看,中行与工行的数据库、华为高斯,到底基不基础、强不强。
先说一个问题:“谁最有资格评价一个数据库强与弱”。
不是你也不是我,而是处理器 --- CPU。
数据库也是程序,数据库并不是跑在空气中,而是运行在CPU之上。对CPU而言,任何程序不过是一段段代码,数据库也是,它并不例外、并不特殊。
CPU有丰富的手段衡量一段代码的好坏,我们先用一个最简单的例子,牛刀小试一把。我以一条极简单的SQL为例,统计它所用的指令数量。
先以PG为例,先介绍一下基本环境:目标表vage2,大小206MB,共有4列,ID列为主键。当前后台进程为24636。
(1 row)
上面是显示一些基本信息。
按如下步骤,可以得到执行某SQL时所使用的CPU指令数:
步1:使用perf,打开CPU ”指令数“计数器,针对进程24636,统计它执行的指令数:
是不是没想到,CPU内计数器,说起来很玄乎的概念,打开它竟十分的简单,一条perf命令就可以了。
\"instructions:u\"中的“:u”,是只统计用户态执行的指令数。我们排除于内核态的指令,去除一些干扰,统计结果更精准。
步2:到后台进程24636对应的Session中,执行目标SQL:

步3:回到“步1”的perf命令窗口诚利和 ,Ctrl+C,就能看到结果了:

105,649,就是“步2”的SQL所用指令数。一条极简SQL,使用了10万多条CPU指令。CPU只需不足一秒,就能跑出结果。现代处理器,还是很强悍的。
我不是要说高斯基不基础、强不强吗?跑题了吗?
并没有。
单看一个指令数,确实没啥意义,但横向对比多个数据库,就有意思了。
下面看看同样的表、同样的SQL,在华为高斯数据库中,使用了多少条CPU指令。
在高斯中,目标表大小为196MB:

和在PG中基本相同(PG中是206MB)。
列数量(4列)、行数(300万行)完全相同,连插入的数据都完全一样。
高斯是线程模式,先要得到后台线程号,步骤如下:
步1:得到线程标识:47503107229440

步2:在gdb中调试高斯的进程:

步3:把线程标识47503107229440,转为16进制:0x2b342dd50700

再使用\"i thr\",列出所有线程
步4:搜索0x2b342dd50700,就能得到线程号:25416

继续步5。
步5:使用perf,打开CPU ”指令数“计数器,这次针对线程25416,统计它执行的指令数:
步6:在线程25416对应的gsql Session中执行目标SQL:

步7:回到perf,Ctrl+C:

在高斯中,执行和PG同样的SQL,使用了989,183条指令。
还记得PG使用了多少条指令吗,105,649条。高斯是PG的9.36倍。
数据量相同、列相同、连数据都一模一样,执行相同的SQL,高斯使用的指令数是PG的9倍多。
这意味着什么,表达同样的意思、说同样的话,PG使用了1万个字,高斯使用9万多个字。高斯使用的字数,是PG的9倍多。
说句不好听的话,我听到我儿子幼儿园同学们的谈话,费话极多、还有大量的重复、逻辑略微混乱,能用一个字说清的,可能用了9个字才说清楚。有时候用了9个字也没有说清楚。
华为高斯和幼儿园小朋友不同是,高斯用9个字,把话说清楚了。
为什么是这样?
我这里使用的技术极简单,仅用一条perf命令,只观察了一个计数器的结果:指令数。高斯的表现就已经这样了,还需要从L1~L3 Cache、TLB、iCache、前端吞吐、译码效率、ROB/RS/LB/SB使用情况、流水线STALL比例、……,等等方面完整分析吗。(上面这些分析我计划后面开一个系列好好讲讲)
CPU中的计数器可是多达近千个的,可以对程序进行全方面的profilling。
我想表达的意思是:基础软件开发有自己的知识体系,从处理器层对程序进行profilling,也仅是其中的一环。从现实的表现看,华为高斯团队并不掌握基础软件开发的知识体系。
但高斯仍是一个典型的工程实现很棒的应用层软件。
我是说,高斯是一个应用软件,工程质量很棒。但高斯并不是一个基础软件。原因是走错了方向,在按应用层软件的思路,开发基础软件。
配资指数平台提示:文章来自网络,不代表本站观点。