摘要：这是我走过最长的路。
炎炎夏日，先说个笑话给大家降降温：某君带着一只宠物乌龟，下班后开车回家。到北京二环路遭遇堵车高峰，半天挪不了几步。乌龟耐不住性子，坚持要先爬回家，主人只好由它去了。不知过了多久，主人在车里听见有敲门声，打开一看，只见乌龟满头冒汗，气鼓鼓地说：“你忘了给我家门钥匙 ……”
电台里讲着不冷不热的笑话，与眼前堵得水泄不通的情形倒相得益彰。在大城市，早晚高峰堵车，是逃不掉的煎熬。如果道路可以根据车流量自行拓宽和收缩，该有多好！当然，在现实中这是不可能了。不过，希望可以自动伸缩的，又何止是路？
小林躺倒在座椅上，想着客户们各种奇葩的要求，头都大了几圈。他是一家知名 IT 服务公司的咨询顾问，专为客户解决各种难题。
方案讨论现场
客户A：“我们公司的《**直播》APP 刚上线，现在没法预估业务负载情况。 “
林：“目前贵司流量不多，但直播节目一夜爆红的例子比比皆是。到时候千万级流量涌入，满屏礼物和互动，还要保障直播清晰不卡顿。”
客户A：“所以能不能请你设计套方案，可以随时根据流量变化扩容那种？”
林：“随时？？？？”
客户 B：“我们公司推出一款游戏超火，每天晚上 6 点到 12 点东南区挤爆。”
林：“要及时响应大量玩家同时在线的需求，对后端数据处理能力要求非常高。处理不及时导致的请求超时登录不上、操作大幅延迟、团战掉线等等，都非常伤害玩家体验。”
客户 B：“所以有没有一套可以定时拓展和收缩的方案，能缓解业务高峰期压力就行？“
林：“定时？？？？”
客户 C：“我们公司是做车联网的，接入大量终端产品后，有海量数据并发接入需要处理。“
林：“车联网平台数据不但量大，而且种类多，处理起来确实麻烦。遇到高峰期，要根据实时路况分析最优行程路线；尤其是车祸等紧急情况下，不但要迅速判断车辆损毁、人员伤亡等信息，更是要及时协助处理善后，后台支撑马虎不得。”
客户 C：“所以可不可以设计一套方案，会根据行程情况自动分配资源那种？”
林：“自动？？？？”
你们怕不是对扩容有什么误解吧？小林的嘴角隐隐抽搐。。。
但凭着服务人员春风化雨般的耐心，还是柔声解释道：“各位的问题，都集中在弹性扩容需求上。所谓弹性伸缩，就是一种可以根据用户已有计算资源与实际业务量，推算出供需是否匹配，并决定增加或减少资源的功能。“
客户B：“弹性扩容能解决我的问题？ “
林：“打个比方，B 先生公司的游戏平台，资源配置是按照处理 100 万人同时在线的平均标准来的；但晚上 6 点到 12 点高峰期，在线玩家数可能高达 1000 万。弹性扩容的功能，就是能自动根据在线玩家人数，把资源调整成处理100万人在线、还是1000万人在线的配置。“
客户A：”那我的问题也解决了呀？”
林：“弹性扩容是能解决流量峰值的性能问题，但是，弹性扩容需要时间。一般情况下，1 亿 6 千万条文档记录、100GB 的数据，扩容大概需要 29 小时 35 分钟。”
客户C：”一天多？你这扩容好，黄花菜都凉了吧？”
。。。。。
这扩容要这么久，也不是自己能解决的啊。要快速扩容，就绕不开数据库，传统数据库架构采用存储与计算混合架构，扩容就是一场计算资源带着数据一起的大型“逃亡”， 29 小时 35 分钟还是好的了；数据量再多点你试试？
又 TM 不是猴子，一根如意金箍棒说长就长？
滴！！！！小林被身后的鸣笛拉回思绪，不知何时前面的车流已空了一截。摇下车窗，正打算出口闷气，冷不丁被广告牌上的海报晃了下眼：
原来，还能如此？小林掏出手机，车缓缓向前挪去。
了解 MongoDB 增强版更多信息请点击：
免费试用更多数据库畅销引擎请点击：