這兩天一直在出差，在高鐵上突然想起一些東西，先做個記錄吧。

數據庫的能力不是無限的，針對一些特別的高需求的應用往往需要在集成架構和應用架構上去做些優化，從而滿足應用的需求。數據庫廠商也在努力提升產品的能力，盡可能從數據庫的角度來滿足應用的需求。不過數據庫產品的能力總是有上限的，不可能滿足應用的所有需求。

第一個場景是0數據丟失，在傳統的數據庫災備環境中，RPO為0是絕大多數系統的追求。0數據丟失十分有價值，雖然某些應用系統允許少量數據丟失。

不過數據庫層面能保證RPO為0，對于應用來說是最為友好的。早些年阿里的支付寶在使用ORACLE 9i的時候，就創造性地使用了一種通過寫REDO遠程副本的方式實現了同城災備系統中RPO為0。這種技術目前還在ORACLE ADG的同城災備中使用。這種方案的實現比O記自身提供的FAR SYNC更為簡單實用，在某些場景中也更加有效。

第二種場景是極致高可用。大多數應用對于高可用的目標要低一些，早期ORACLE OPS/RAC就實現了分鐘級的TAF切換，通過FCF可以實現秒鐘級的切換。對于大多數應用場景而言，哪怕是銀行核心交易，醫院HIS系統等，分鐘級故障切換已經能夠滿足高可用切換要求了，當然監管部門對此提出了更高的要求，因此這方面的追求是無止境的

。而對于證券交易，期貨交易，電網調度等系統而言，可用性的要求更為極致。數據庫哪怕再安全都無法給這些系統提供足夠的可用性保障。因此這些系統都可用性不能完全依靠數據庫系統，應用本身能夠短時間脫離數據庫來完成交易撮合是十分關鍵點。

如果沒有這方面的能力，交易系統是無法滿足期貨交易這樣嚴苛的可用性要求的。十多年前我給移動的短信平臺做系統優化，就發現有一家供應商的系統可以脫離數據庫運行30分鐘左右，而另外一家只要數據庫掛了系統就掛了。這就是應用架構產生的可用性差異。

第三個場景是極致高并發。極致就是只你可能不大想象得出來的QPS，高到很可能超出單體數據庫的能力極限。這個場景最初是互聯網場景。當單體數據庫無法搞定的時候，首先我們會做分庫，如果分庫還解決不了，那么就分表。比較幸運的是這種場景的寫入或者查詢都相對簡單，因此分庫分表的實現對于應用來說還算可控。

分布式數據庫最初就是用來解決這些場景的，對于一些超高并發的簡單場景能給予很好的支撐。不過數據庫廠商的野心在不斷擴大，他們希望分布式數據庫不僅僅能解決簡單的業務，也能解決復雜度業務場景。不過到目前為止，分布式數據庫還沒有表現出對復雜的機制高并發場景的完全把控能力，因此針對這樣的場景，應用及應用架構上的優化依然十分重要。