腾讯数据库二三事

本文来自微信公众号：浅黑科技（ID：qianheikeji），作者：史中

电影《头脑特工队》的封面上，有五个颜色各异的小精灵。他们在主人公小女孩的脑海里上班儿，专门负责整理她的记忆。

小女孩儿的每段新经历，都会被涂上“喜怒忧恐厌”这五种颜色之一，然后封装成水晶球，存入记忆库房。不过故事里的小女孩有点丧，当时她刚刚转学，每天都生活在被陌生环境支配的恐惧中。为了让她的记忆里多一些欢乐，这几个小精灵每天上班996，差点累进ICU。

当年，中哥看完整部电影热泪盈眶——这简直是一部绝好的数据库科普电影啊！

啥是数据库？能吃吗好吃吗？

其实数据库并不神秘，就是把怕丢的东西记在小本本上。最简单的数据库人人都见过，就是 Excel 表格嘛：女神动不动就搞个 Excel 表格把备胎们的姓名、财富状况、消费记录都记下来，方便统一管理。但是这种靠手动查询和改写的表格，经常眼一花就搞串行，查了半天还叫错名字，难堪大用。

《头脑特工队》里那套记忆系统就高级多了——每一个记忆小球，就是一段数据。有个灵活的机械手，不仅可以随时批量存入新数据，还能根据条件实时找出指定数据，精准无比绝不出错。这差不多就是真实世界里“数据库”的样子。

你每时每刻都沐浴在数据库的恩泽下。

随便举个栗子：你打开心爱的女神票圈那一刻，她的所思所想，每一张泛着香气的美颜自拍，都是从微信的数据库里掏出来贴到你脸上的。女神“呵呵去洗澡”之后，你自己去吃鸡，每次战果也都是会记录在游戏数据库里的。

别看我说得轻松，可千万不要小看数据库的技术含量。

假设你在QQ上改了自己的个性签名，如果下次登陆的时候 QQ 告诉你：“哎呀上次你改的是啥来着，我给忘了，再说一遍呗？”

你能把电脑砸了。

只是个性签名错了你都忍不了，如果你的银行账户钱数错了怎么办？如果神舟飞船的轨道数据搞错了，又怎么办？

实际上，在浩瀚如海的数据洪流里，几毫秒间就能锁定数据位置，查询改写，一字不错，一字不漏，是一项世界级别的软件工程能力。

不夸张地说：数据库是可以和操作系统、芯片技术相提并论的“民族复兴专用技术”。

踢个球什么的，中国队不爱和别的国家计较，但平胸而论，搞计算科学，中国队历来是认真的。这两年拽着云计算的衣角，中国在数据库领域进展迅猛。腾讯精，百度倔，阿里喷热血，华为怼一切。大厂性格不同，却各自在数据库领域建功立业。

这里面最有反差萌的，当属腾讯数据库。

因为历史正是一个超大的数据库，一个字节都不会丢。最近和腾讯的“老湿傅”们聊天，往事如沙钩沉。我迫不及待给你讲述腾讯数据库的三场战役。

一、微信红包的“珍珠港”

腾讯的故事，还得从 QQ 说起。

2006年，QQ 同时在线人数逼近2000万。

这让 QQ 产品团队欢欣鼓舞，却把底层技术老湿傅吓出了一身冷汗。这2000万人都是凶猛的动物，他们同时相互发信息、查看资料、改写资料——这些操作产生的数据就像机枪一样把子弹喷射向数据库，而数据库必须化作《黑客帝国》里的 Neo，把每一颗子弹都接住。

那时候的腾讯还在使用开源的数据库，其中以 MySQL 数据库为主。啥是 MySQL？如果非要类比的话，你可以理解为它是数据库里的 Android——免费、方便，但不包熟包甜。

但在那个热血的年代，QQ 用户量增长速度创造了人类历史，开源数据库还是个宝宝，被海量数据按在地上摩擦，呈现出“早晚要跪”的姿势。腾讯技术团队紧急组织了一个“特战队”，目标只有一个——研发一款能够支撑起几亿用户的数据库。

一年后，腾讯自研的第一个数据库呱呱坠地，这就是“CKV”（当时还叫做TDB）。

这里中哥强势插入科普一句：CKV 和 MySQL 有个奇妙的区别——CKV 是非关系型数据库，而 MySQL 是关系型数据库。

给你画两张图解释一下吧。

关系型数据库（简称 SQL）就像是教室，童鞋们每人手里举着一份数据，规规矩矩地排排坐，谁是谁的同桌，谁是谁的前座，这种关系都安排的明明白白，老师说“第三排全体起立”，第三排的同学们就能同时站起来。老师说“第一列最高的同学出列”，他就会站起来。管理起来很方便。

关系型数据库（SQL）

非关系型数据库（简称 NoSQL）像是操场，童鞋们踢球跑步搞基随便浪，虽然不像“关系型数据库”有那么多玩法，但是老师也能找到想找的人。他站在旁边大吼一声“林蛋大”，楚中天就会跑过来。老师喊“五年级同学集合”，五年级的孩子们也会跑过来。

非关系型数据库（NoSQL）

其实，“关系型数据库”是当时绝对的技术主流。因为这种数据库已经有30年的历史，它把数据存储得非常规范，对强迫症非常友好，又支持很多骚骚的查询计算方式。那为啥腾讯还偏要做“非关系型数据库” CKV 呢？

根本原因是，腾讯做的事情是“社交”。

现在说起来“社交软件”，小孩子都懂。但不要忘了，当时整个互联网刚刚发展到社交时代，没有人知道应该啥样的数据库支持社交最合适，只能靠老湿傅的直觉，摸着鱼过河。

老湿傅们选择非关系型数据库有两个理由：

• 社交数据由用户自己生成，数量巨大无比，需要最低成本的存储和管理方式；

• 社交场景对于数据读写速度要求很高，但数据之间却并不需要特别频繁的相互计算。

后来的历史也证明，这个选择是对的。

我们故事的第一个讲述人程彬，2008年毕业加入腾讯，他被分入的团队，恰好就是 CKV 数据库团队。

程彬

加入 CKV 的时候，这个数据库已经能很好地支持腾讯的业务了。程彬本以为自己可以躺在前人的成果上舒服一阵子，没想到，他大大低估了腾讯这家伙制造爆款的能力。

那段时间，“QQ空间”突然大火，爆点发生在2009年，QQ空间里上线了“QQ农场”“好友买卖”“抢车位”这一票社交游戏。

人们偷菜偷来偷去不亦乐乎，每偷一棵菜，就要改写一下数据库，数据库团队差点疯了。

程彬说，这个账是能算出来的：

当时我们用的是每分钟15000转的顶级机械硬盘，它每秒钟能读写300次。为了保证数据不丢，还要对每份数据另外做两个备份，加上原数据总共三份。按照当时人们那种疯狂的数据访问强度，光是支持一个“偷菜”就得一万台服务器，这谁顶得住啊。

注意，这里的瓶颈关键在于“每秒访问次数”太多。就像你每天喝八杯水能喝一辈子，但直接把你扔到游泳池里，你多半就喝不了了。

有什么东西能支持高并发访问吗？有，这就是“内存”。内存的访问并发可以达到硬盘的100倍，但它有个众所周知的弱点，一断电，数据就没了。

于是，同事们绞尽脑汁，想出了一个“中西医结合”的方案：把访问最频繁的数据库放在内存里，每隔一段时间，内存再向硬盘同步这部分数据。

然而，内存仍然是很贵的设备，买几万条也受不了。于是 CKV 团队又做了一套调度系统，能够自动把不同时段比较“热”的数据“倒着班”放进内存。例如，午饭后白领比较喜欢刷空间，那时就把白领们的数据放到最方便读取的地方；晚上下课后，大学生们又开始刷空间，那就把大学生的数据放在内存。

就这样，CKV 经受住了极高频度的访问冲击，而且成本还比想象中便宜了好多。腾讯内部孵化新项目，会直接找数据库团队“借用” CKV。

2010年，腾讯推出了“腾讯开放平台”。

当年最先抢滩登陆“开放平台”的螃蟹，以游戏团队为主，他们“馋”的主要是腾讯的流量。但是腾讯觉得，我们的技术也很好呀，你们要不要用用看？现实很骨感，大家只盯着腾讯的流量，没什么人关心腾讯还有技术，知道腾讯还有“数据库技术”的就更是凤毛麟角了。

领导把程彬他们叫来：“数据库是你们做的，要不，你带着做开发的几个兄弟，自己吆喝一下，卖卖数据库？”

一群整日写代码，一天都憋不出十句话的技术宅，居然“被逼”做销售，简直五雷轰顶。程彬坐在电话机前面，愁都愁死了。

果然，硬着头皮顺着表格一个个电话打过去，人家要么就是不需要，要么就是信不过腾讯的技术，好不容易有一家公司觉得可以试一下，问完价格以后就再也没信了。

十几个兄弟这么熬了两三个月，几乎颗粒无收。就在那段时间，好几个骨干成员都跟程彬提出了离职。“还用打电话问么？这东西能不能卖出去谁心里没数？”一位同事离开的时候，撂下了这句话。

程彬压力山大，这样下去，同事们早晚要走光了呀。

他一拍桌子，给一位很喜欢腾讯数据库但是嫌贵的知音客户打电话：“我去找你，你给我们当面提提意见。”然后，从一群沉默的技术宅同事里挑了最爱说话的那个，一起买了飞机票去北京。

“你看到那幢特高特漂亮的大厦了吗？不不不，别上楼。大厦对面的小区，3号楼一单元502，我们就在这里办公！楼道里没灯，小心点。”电话里，客户指挥程彬找地址。

那是我有生以来第一见到“民房创业”，三室一厅，七八个人，就在里面黑漆漆地敲代码。我说，我们数据库一个月就几千块钱，也不贵呀。人家告诉我，整个这间办公室一个月才几千块。

程彬回忆。

一毕业就来到大公司腾讯的程彬，第一次体验到“民间疾苦”，他突然开悟，对于小公司来说，什么海量承载能力，什么世界级高吞吐，都是空中楼阁；一个便宜、够用的标准数据库才是最急需的。

回到深圳，他们马上确定了新方向：在 MySQL 的基础上，开始研发亲民的数据库“CDB”。这就是后来在腾讯云上的“腾讯 MySQL 数据库”。

时间拨回那一时刻，他面对的主要矛盾就是一句话：在保证数据库品质的基础上，最大限度降低成本。

数据库的成本怎么降低呢？这里就要说到它的一个小痛点。

数据库使用的硬件一台台标准的服务器，里面既有计算资源又有存储资源。但既然是标准服务器，计算资源和存储资源的比例就是固定的。

而人们使用数据库的姿势却千差万别——有时存储空间用满了，计算力还在闲置；有时计算力用满了，存储空间还闲置。

要想省成本，先从这个资源浪费下手。

于是团队设计了一个“存储和计算分离”的架构，有几台服务器专门负责计算，其他更多机器里塞满硬盘，专门负责存储。就好像煮饺子的时候，只煮5个饺子皮，再单独煮100个肉丸子，这样喜欢吃馅的老铁就能吃个够。

然鹅，这个新办法，又引入了新问题。

存储和计算之间虽然分离了，但他们本来是一家子——要想共同协作，就要频繁地进行信息交换。

当时主流的交换设备就是“千兆网卡”（1000M/Bps）。算一算，一页表单是16kB，除下来一个网卡每秒最多只能传6000多次数据。你可能会说，多加网卡不就行了？但那样成本不就又上去了么。

既然硬件的瓶颈明摆在这里，那别无选择，只能把数据库变小了。

那段时间，数据库的老湿傅们没白没黑地看 MySQL 的代码，凡是不需要的表单功能，就大刀阔斧地删减。

这一顿操作下来，CDB 数据库的成本直接杀到原来的三分之一，开放平台上的用户从腾讯云上买数据库，比自己雇人开发还要便宜。

回想起那几年，程彬觉得腾讯数据库简直就是玩了一把真人版的《CS》。

2014年春天，微信推出了一个“开玩笑”的小功能——红包。让微信支付最深入人心的一次战役，当属2015年微信赞助春晚的“摇红包”活动。

这是当时摇红包的宣传图

把时间再往前拨转，距离春晚还有两个月时，微信团队的童鞋找到当时的数据库团队，请求支援。春晚可不是闹着玩的，全国十几亿人民一起，普通的红包我们普通的摇。

团队估算了一下流量，无论是用并发性能强劲的 CKV 数据库，还是用关联计算能力更强的 CDB，恐怕都要跪。

最后，两个数据库团队想到了一种奇葩的解法——把 CDB 和 CKV 合体！

于是，在春晚前两个月，数据库的老司机们开始了“秋名山飙车”，在非关系型数据库 CKV 中插入了关系型数据库的“树结构”，这样在抢红包的时候，系统就不用告诉数据库每个数字的变化，而是数据库根据已有的关键数据，自己补全剩余的数据。无数这样的骚操作联合起来大大降低了对数据库的写入频率。

那年春晚，微信红包一炮而红。

二、《王者荣耀》的“莫斯科保卫战”

1941年，苏联红军扬起烟尘，从红场阅兵直接开赴苏德战场前线。这次莫斯科保卫战，苏联做好了最后的巷战准备。仅仅妇女和儿童就构筑了700公里的反坦克战壕。在几百公里的战线上，两军拉锯，苏军虽然单点经常被攻破，但补防策略执行得天衣无缝，兵来将挡水来土掩，任凭德军装甲车、摩托兵套路用尽，都没办法撕破防线。

这场战役并无神来之笔，苏军最强的战斗力恰恰就是——“稳定性”。这三个字拯救了莫斯科，让二战的结果成为今天教科书里记录的样子。

而伴随一款游戏毫无预警的爆红过程，数据库承受的冲击，不亚于一场“莫斯科保卫战”。

我们故事的第二位讲述人张世维，就曾经历过这样的战役。

张世维

张世维曾在数据库领域的“殿堂级公司”甲骨文工作，加入腾讯时，腾讯其实面临一个大挑战。

当时的情况其实挺紧急的。因为谁也没搞明白，腾讯代理的游戏怎么突然一下就那么火，无数玩家涌进《CF》《DNF》，XXXX不亦乐乎。之后，腾讯自己也开发了一些大型游戏。

开发游戏本来就很难，一个游戏所需要的“高性能数据库”，更是难上加难。

没错，张世维团队的任务就是：在最短的时间内，开发一套为腾讯旗下所有游戏提供服务的数据库——TcaplusDB。

刚才说过，游戏对数据库的要求，就是苏联对莫斯科保卫战的要求——稳定。无论是游戏玩家突然暴增一百倍，还是机房突然停电，还是游戏本身升级维护。玩家就是一句话，游！戏！不！准！给我停！

技术人，得尊重科学。再高的技术水准，都难以保证完全不会出问题，所以要想数据库不熄火，最稳妥的方式就是，增加备用数据库。

于是，TcaplusDB 数据库一出生就是“三胞胎”——除了主数据库，还标配一个“热备份数据库”（简称热备）和一个“冷备份数据库”（简称冷备）。

这三份数据库都是实时同步的，可以相互替代。他们之间的替代关系不是整个替代，而是可以以服务器为单位的“细粒度”替代。举个例子就明白了：假设老大的左眼坏了，不用让老二整个人来替换他，而是只把老二的左眼抠出来给老大装上就行了。

具体工作原理是酱的：

如果主数据库的28号服务器出现硬件故障，那么系统就会在0.1秒内把热备服务器的28号服务器切过来继续使用，这边数据库的老湿傅们紧急换掉主数据库的28号服务器，把里面的数据补齐，然后系统又会在0.1秒内把服务器切换回来。

整个过程，对于游戏玩家来说根本感知不到。在他们看来，游戏一丝一毫都没有中断。

你可能会问：中哥你不说是“三胞胎”吗？还有个“冷备数据库”，是干嘛的？

答：只有在老大、老二同时挂了的时候，才会请出老三。由于老大老二同时挂的概率太低太低了，所以一般用不到老三，就把他先放在冰柜里冻着，需要的时候，紧急“解冻”它就好了。当然，如果需要启动冷备数据库，游戏就会中断十几分钟。这种情况，玩家免不了会吐槽，但好在他们的数据一个字节不会丢。正所谓——懵逼半天，归来仍是青铜。

2012年，TcaplusDB 数据库第一次出街，支持的游戏是腾讯自己开发的页游《夜店之王》。

《夜店之王》

为了继续讲故事，这里中哥先给你科普一个概念：“PCU”。PCU（Peak concurrent users）翻译过来就是“最高同时在线人数”。用这个数值来评价游戏的火爆程度，简单又直白。

下次如果你想装做游戏业内行，你就云淡风轻地问：这游戏的 PCU 是多少啊？

要知道，当时的游戏，大部分还是“分区分服”的，这个打游戏的童鞋都明白。由于服务器和数据库能力的限制，得把全国分成几个区域，每个区域内部自己玩儿。但是《夜店之王》由于采用了包括 TcaplusDB 数据库在内的新技术，可以做到“全区全服”，全国玩家在一个池子里“大乱斗”，爽得没边。

根据记录，当年《夜店之王》的 PCU 超过百万。这对于当年的腾讯自研游戏来说是相当不错的成绩。

张世维没有料到，这个数量级的 PCU 在接下来要到来的“手游”浪潮面前，简直就是个渣渣。

浅友们可能还记得，2013年的时候，腾讯冷不丁推出了几个“天天”系列游戏，《天天酷跑》《天天爱消除》。

《天天酷跑》的 PCU 很快就冲过了《夜店之王》的记录，张世维很开心。过了两天，冲到了两倍，张世维更开心。又过了两天，冲到了三倍，张世维心里咯噔一下。给数据库准备的100台服务器马上就不够了。

《天天酷跑》

他紧急向公司申请，添加了50台服务器。然而新服务器就像是刚建好的“空仓库”，你还得把原来仓库里的数据搬一部分过来，这才是真正的技术挑战所在。

虽然这种“搬家”当时基本已经做到系统自动调度了，但是，搬家和搬家还不一样。如果时间充足，搬家是一件很容易的事情；如果要求在一天之内搬空一个大厂房，就需要点骚操作了。

眼看旧数据库在逼近存储极限，那边玩家还在不解风情地制造新数据，搬家速度必须非常快，才能避免数据库爆棚。与此同时，搬家还不能造成游戏丝毫中断，玩家要什么姿势，数据库随时得给。

然而，用户增长的速度还是太快了，按照这种态势，24小时后数据库就会崩溃，游戏只能暂时停服。谁都不敢面对这样的结局。

而这套数据库自动迁移系统很快就迎来了最大难度的检验。

2015年底，《王者荣耀》上线。

《王者荣耀》野到了什么地步呢？几乎起跳点位的 PCU 就是历史峰值。

包括游戏的开发团队都没期待《王者荣耀》会这样蹿红，紧急找到 TcaplusDB 数据库团队，让他们帮忙看看，数据库可千万别跪了。

张世维和团队虽然做好了充分的准备，但心里还是很忐忑，毕竟这个逆天的游戏每一秒钟都在创造数据库的新纪录。

我没办法对外披露具体的数据，不过《王者荣耀》的 PCU 峰值是一个惊人的数字，创造了历史记录。

“几千万人在同时使用我们写数据库的代码，你能体会这种感受吗？”

三、腾讯视频的“诺曼底”

2014年，“腾讯游戏”正劈波斩浪，它的兄弟“腾讯视频”却前途未卜。

我们的第三位故事讲述人，邵宗文，就与此有关。当时他正在腾讯视频所在事业群（OMG）的数据库团队。

邵宗文

邵宗文是不折不扣的“老炮儿”，有10年数据库运维经验。他心里最清楚，不会有人把一个产品的成功归功于数据库；但一个坑爹的数据库，却很可能把产品拖垮。

“那时候腾讯视频的体验并不好。看着看着就会出现卡顿。但是由于没有足够细致的检查数据，技术团队也很难判断问题到底出在哪儿。大家都很着急。”

邵宗文回忆。

因为数据库是个巨复杂的系统，就像人体一样，靠五脏六腑、血液淋巴神经、骨骼、大脑、各种激素和分泌物共同维持运转，精密至极，哪里出了个小意外，都会导致整个系统发生意想不到的问题。所以，就像人类需要医生一样，数据库也需要一套“数据库运维系统”。

2009年，他刚加入腾讯的时候，做了一套数据库运维系统。这套系统就像戴在身上的“心电记录仪”，哪次查询过于缓慢，哪次进程卡死了，它都会记在小本本上，生成完整的报告发送给运维老湿傅作参考。

在运维微信群里，告警自动发送。

这种思路，如今已经成为了数据库运维的标准操作，但在当时来看，却领先了一个时代。这个数据库运维系统被命名为“扁鹊”，希望它药到病除妙手回春。

当时情况危急，“扁鹊”被用到了腾讯视频，很快就定位出了很多对于数据库不合理的查询语句。

与此同时，伴随着视频网站付费模式的兴起，内容为王的时代终于如晨曦降临。一场“诺曼底登陆”，就这样悄无声息地展开。

不得不说，2016年，是科技史上的一个“大年”。

阿法狗大战李世石，BAT 猛然疯狂争夺人工智能的权柄，今日头条异军突起，所有的内容平台的玩法更是一夜之间从“人找内容”倒向“内容找人”：

以往你还得冥思苦想，然后在框框里输入自己想要看什么；现在非常棒，你只需要宛若智障握着手机往下划，人工智能就会把你喜欢的内容“喂”到你嘴边。

这里中哥还得插入一下，简单科普一下“AI 推荐”的原理。

AI 推荐的基本动作是“打标签”。假如你天天看番，系统也许就把你标注为“宅男”，那好了，从今以后给你推宅男更喜欢的视频。但究竟哪些视频是“宅男向”，哪些视频是“宅女向”，同样也需要人工智能“打标签”。（这是科普，当然并不是你只想看什么 AI 就只给你推什么。）

人工智能识别图片，并且打好标签。

按理说“AI 推荐”是业务上的变动，和底层的数据库没卵关系，其实不然。“打标签”这个动作，需要频繁地抽取数据进行计算。数据穿梭，如惊涛拍岸，卷起千堆雪，对数据库这个“河床”产生了巨大的冲击。

腾讯视频熬了这么多年，好不容易等到了“诺曼底大反攻”，数据库绝对不能掉链子。于是，他们一点点升级技术——在数据库内部“多走一步”，用人工智能给视频先打好基础标签，再交给业务同学进一步筛选。这样不仅降低了数据库的频繁访问，还能减轻业务同学的负担。

一个数据库团队搞起了人工智能，这听上去就好像厨师放下了菜谱，研究起了《孙子兵法》。

2016年，搜狐搞了一次“图文匹配大赛”，参赛队伍面对10w个文章和10w张图，要用人工智能自动为每一个文章匹配相应的图。你可能看出来了，这就是一个典型的“打标签”应用场景。结果邵宗文带队参加，在400多支队伍里拿了第10名。

弱水三千就是他们

搜狐的童鞋看着这几个陌生的面孔，一拱手：“还没请教几位是何来历，怎有如此身手？”邵宗文羞赧地摸摸头：“对不起，我们是搞数据库的，有点乱入，承让。”

2017年的时候，某女艺人突然被爆出轨，网络爆燃，瓜众纷纷搜索和她相关的视频和报道。数据库团队接到任务，为了应对搜索，要把之前与她相关的新闻全部找出来。

由于早年的报道和视频，很多都被放进了“冰箱”——冷数据库，所以要有一个“解冻”的过程。这个过程如果手动操作，虽然不难，但颇要费一些时间。不过，因为有人工智能打好的标签和成套的自动化工具，数据库团队只用了十分钟就完成了任务。

这次事件之后，数据库团队又推出了DBbrain。在 DBbrain 里，人工智能可以根据一个业务的爆发态势，预测数据库将要面临的压力，从而自动生成一个数据库运维策略。

这大概就像一个体检医生，可以预测你未来几个月可能出现的身体状况，然后提前帮你做好预案，开好药方。到时候不出问题当然更好，如果真出了问题，只要冷静地执行预案，也会化险为夷。

举个栗子。在 DBBrain 还在研发的时候，就曾经紧急派上了用场。

2018年，腾讯视频大爆发，把一个节目烙刻在所有人脑海里，那就是《创造101》。

那个周末，粉丝们涌上平台。由于缺少和饭圈儿“斗智斗勇”的经验，并没有对系统做特殊保护，瞬间数据库压力巨大。

这个时候，还在内部试用阶段的 DBBrain 给出了建议：自动扩容、数据同步降级、热点前置、代理层上推。数据库团队马上确认了这个建议，一秒钟，新配置生成。数据库承受的冲击断崖式下降，惊险地挺过了“饭圈儿”这一波“人肉冲锋”。

四、无尽的战役 

人说腾讯不性感。

这话没错。

我特意翻了一下腾讯云的产品页面，“腾讯 SQL 数据库”、“TcaplusDB”、“DBBrain”这些名字就那么沉默地躺在那里，甚至没听过的人想把它们读对都很困难。

在印尼，受限于机房供电条件，张世维平生第一次遇到了主数据库和主备数据库同时掉电的状况真实发生。

2019年，DBBrain 被好几家著名的电商平台请去做数据库的“私人医生”——在“618”和“双11”大促之前，自动给数据库做体检；在大促的过程中，遇到异常就会实时发送警报和处理建议；如果出现了意外故障，则会根据故障的情况，触发不同等级的“降级策略”。

临别前我问程彬：这么多年，挺过这么多风浪，最难的是什么时候？

“现在。”他脱口而出。

本文来自微信公众号：浅黑科技（ID：qianheikeji），作者：史中。