软件测试数据库面试：高并发下URL短链设计

面临面试之时，面试官抛出了一个表面看似简易的“URL 缩短器”设计问题，从而遭遇这般情况，即我于白板之上描绘得繁杂多样，形形色色，然而却被他仅用三句话便问得陷入困境。由此使我察觉到，自身不过是一个仅仅会背诵答案的、宛如纸上建筑师一般的存在，从来都没有针对真实世界里的流量冲击进行过思索。

每秒千万写入 数据库扛得住吗

从一开始，我便挑选了关系型数据库，并且满心得意地讲述了分片这件事，还提及了主从复制。然而，当写入量达到每秒1000万的那个时刻，面试官直接着让我去解释预写式日志的竞争问题。就在这个时候，我才发觉，MongoDB和Cassandra在这种场景之下的行为全然不同，它们所具备的写入协议、数据分布策略以及一致性模型决定了谁能够存活下来。

每秒钟要向磁盘写几千万条日志，这意味着每秒有1000万的写入量。在传统数据库当中，预写式日志会成为单线程写入时的瓶颈，原因在于日志必须依照顺序落盘。而Cassandra运用日志结构化合并树，将随机写转变为顺序写，再配合多磁盘并行，才好不容易能够支撑得住。

每加一个节点 系统反而变慢

我往昔认为横向扩展是具备一切通用能力的，然而面试官仅用一句话便让我恍然大悟似的清醒过来：每增添一个节点便会增多一次网络跳转情况，对于拥有1000个节点而言其协调所要花费的功夫，极有可能比一台通过垂直扩展方式所达成的具备高效性能的机器还要迟缓。如此道理我从前从未思考过，就连书本之上也未曾有过相关记述。

更为糟糕的情形是，要是存在一个短链接如同超级碗广告那般以病毒式进行传播，那么所有节点的请求将会同时抵达数据库的同一行。额外增加的服务器数量越多，并发请求便会愈发凶猛。进而那行数据的锁竞争就会越发激烈。解决的办法是运用请求合并，使得多个相同请求等待一次数据库读取，再或者进行自适应缓存。

主数据库着火后 灾难才刚开始

这位面试官给我设定了一个极其不寻常的场景，那就是US - East的主要数据库出现了烧毁的状况，需要切换至US - West的备用数据库，可是此时网络带宽仅仅剩下了10%。我原本脑子里对于“故障切换”的概念就如同是一个简单的按钮，按一下便搞定。然而他却要求我去计算数据不一致的时间窗口以及丢失量，这一下子让我完全愣住，说不出话来了。

针对真实的分布式系统而言，故障并非具有可能性，而是具备必然性。Netflix打造了Chaos Monkey，目的在于在生产环境中以随机的方式关停服务器，从而迫使工程师去设计能够自我恢复的系统。就我所设计的URL缩短器来讲，一定要假定短码生成器会出现重复的情况，网络分区会发生，时钟会出现不同步的现象。要是没有这些对应的黑天鹅预案，那么设计就只能是幻想。

Redis缓存竟然不是必须的

一记重拳来自面试官：要重新设计给抛开分布式缓存，我习惯先去画那些缓存层，他跟我讲，要是只用缓存去挡住百分之十的热点数据，那么百分之九十的请求仍旧得先去查缓存还要落到数据库，平白无故就增加了五毫秒延迟，命中率低的时候，管理分布式缓存所产生的开销远远超过了收益。

有效延迟的计算式子为：命中率乘缓存延迟，加上未命中率乘数据库延迟。当命中率小于90%时，分布式缓存的网络开销、序列化成本以及陈旧数据风险加一块儿，或许会直接致使系统崩塌。他期望我讲出“这次暂且不使用缓存”，可叹我没有那份胆量。

为什么这样设计 比怎么设计重要

“这个东西怎么工作”面试官根本没问，问的是“它怎么出问题”。他迫使我去理解LinkedIn为何放弃某些系统，而非盲目照着做。我一直背诵微服务、分片、高可用的方法，竟讲不清选择每个工具的实际约束条件。

系统设计之中的食材属于约束条件，这包括延迟要求、预算、团队能力以及运维复杂度。要是你阐释不清楚为何放弃Terraform转而采用别的方案，那么你并非在进行设计，而仅仅是在背诵。每一条设计背后的缘由，比图里的方块以及箭头要宝贵得多。

改变学习方法的三个关键动作

不要再如同收集宝可梦那般去攒架构图啦。其一，每当增添负载均衡或者消息队列时，首先得计算成本：多一跳致使延迟增加了多少，运维复杂度提升了几倍。其二呢，要先设计单机单库版本，凭借数据去证实何处需要增添复杂度，估算每秒查询率、五年的存储以及带宽需求。

去研读AWS、Cloudflare、Slack的事故剖析报告，瞧瞧那些堪称完美的设计在实际情形里是怎样崩塌的。切莫仅仅效仿大公司的行事方式，而要探究他们为何非得那般去做。白板并不在意你的图形有多么美观，它在意的是支撑每一个方块的逻辑能否经受住极致的推敲。

读完这篇文，你能否说出，在每秒千万级的写入压力状况下，预写式日志缘何会成为最为致命的瓶颈，你能吗？欢迎于评论区分享你的看法，点赞转发，让更多朋友跳出纸上谈兵设置的陷阱，快来呢。