最近的“停課不停學”給互聯網教育行業這堆火又添了一把柴火。這把火燒的越旺，後臺的資源越緊張，尤其是數據庫。最近我就頻繁接到一些用戶有關數據庫過載的求援。
解決這個問題，有兩種思路：
- 優化數據庫系統的架構，令其能夠快速可持續的彈性擴容。
- 降低對關係型數據庫系統依賴，最好能夠實現即便數據庫掛了，業務也不會掛。
快速彈性擴容，這裡的關鍵詞是快速，雲服務商的數據庫服務一般都支持增加只讀實例，假如啟動一個只讀實例要很長時間，我們只能一直開著只讀而不敢釋放，這樣本來的彈性支出就變成了固定支出。假如能夠在5分鐘之內完成只讀節點的拉起提供服務，那麼我們就可以根據業務的需求來隨時拉起只讀實例。我們都知道在線教育行業一般都有非常明顯的業務高峰期，通過只在高峰期開啟只讀就可以節省大筆開支。
假如只能增加只讀，寫入很快就將變成另一個瓶頸，尤其是超大表的更新和寫入操作。分庫、分表成為下一階段的必然選擇。初期有分庫分表的需求的數據庫表和功能模塊不是很多，採取直接在程序裡編碼的方式關係不大，隨著“大表”越來越多，越來越多的模塊都加入了分庫、分表的代碼。代碼的味道就越來越不對了。於是負責維護代碼的同學開始備受煎熬，對代碼的潔癖催促他們趕緊把這些代碼整合起來，但一整合就發現事情又沒有那麼容易，早知道就選擇一些開源框架好了，但這樣的框架就沒有坑麼？是不能可持續的保證性能擴展呢，畢竟數據庫的事情關係重大。
關係型數據庫快速持續的彈性擴容，這樣的架構其實是現成的：
通過阿里雲DRDS整合多個阿里雲PolarDB，實現透明的水平拆分，及快速的彈性擴容。
阿里雲DRDS 是一個分庫分表中間件，也是阿里巴巴去O的功臣，經歷過雙十一的洗禮，經過這麼多年的考驗，“坑”早被填的差不多了，DRDS本身採用分佈式架構，最大支持1024核4096GB內存。99%的用戶都不會觸碰到這個性能上限，從而能夠實現可持續的性能彈性擴展。
PolarDB 是雲原生數據庫，採用共享存儲架構，因為新增只讀節點不需要複製數據，所以能夠快速彈性擴容。PolarDB 單節點最大88核710GB內存，最大可擴展到16個節點。節點配置越高，隨時彈性擴容節省的就越多。
解決問題的另一個思路是降低對關係型數據庫的依賴，例如可以考慮在一些業務中使用NoSQL數據庫。NoSQL數據庫本身就是從互聯網的高併發需求中催生出來的，無論是開源的HBase還是阿里雲的表格存儲都能夠提供PB級的存儲和千萬級的併發處理能力。
除了NoSQL數據庫，還可以考慮用一些消息隊列服務來緩衝突然增加的業務壓力對業務的衝擊，用戶的前臺操作可以先放到消息隊列中，再由後臺服務取出慢慢處理。每年的雙十一0點剛過的下單高峰就是通過阿里雲的消息隊列服務進行緩衝處理的。
另外，通過一些限流中間件可以將數據庫等一些關鍵部門保護起來。可以根據業務的優先級將不同等級的服務對數據庫的調用進行隔離，系統資源緊張時限制部分非關鍵業務對數據庫的訪問。阿里雲AHAS高可用服務就是一個這樣的限流中間件。
這種降低對關係型數據庫依賴的方案還有很多，具體選擇什麼方案，以及與繼續投入關係型數據庫如何平衡還要看具體應用場景，改造成本和可預期的業務成長速度相關。