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

數(shù)據(jù)庫的能力不是無限的，針對一些特別的高需求的應(yīng)用往往需要在集成架構(gòu)和應(yīng)用架構(gòu)上去做些優(yōu)化，從而滿足應(yīng)用的需求。數(shù)據(jù)庫廠商也在努力提升產(chǎn)品的能力，盡可能從數(shù)據(jù)庫的角度來滿足應(yīng)用的需求。不過數(shù)據(jù)庫產(chǎn)品的能力總是有上限的，不可能滿足應(yīng)用的所有需求。

第一個場景是0數(shù)據(jù)丟失，在傳統(tǒng)的數(shù)據(jù)庫災(zāi)備環(huán)境中，RPO為0是絕大多數(shù)系統(tǒng)的追求。0數(shù)據(jù)丟失十分有價值，雖然某些應(yīng)用系統(tǒng)允許少量數(shù)據(jù)丟失。

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

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

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

如果沒有這方面的能力，交易系統(tǒng)是無法滿足期貨交易這樣嚴(yán)苛的可用性要求的。十多年前我給移動的短信平臺做系統(tǒng)優(yōu)化，就發(fā)現(xiàn)有一家供應(yīng)商的系統(tǒng)可以脫離數(shù)據(jù)庫運(yùn)行30分鐘左右，而另外一家只要數(shù)據(jù)庫掛了系統(tǒng)就掛了。這就是應(yīng)用架構(gòu)產(chǎn)生的可用性差異。

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

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