資料庫隔離

      虛擬機器部署資料庫（我認為在自己練習環境可以，正式環境還是算了）。資料庫作為系統的核心，資源一定要獨享。甲骨文說如果Oracle安裝在虛擬機器上，都不提供支援。如果一個物理機上執行一個database比如（MySQL這裡的X PostgreSQL這裡的X）

，

這樣的其實有點浪費，那麼可能應該有多個。可能會有說現在微服務應該把資料庫分開。其實我想說微服務和資料庫是不是分開沒有關係。一個例項下不同database也能去做。

     不過我更加說句心裡話，真心話。那就是不用微服務更好，說這話可能招來一片噓聲。但是就我幫別人公司處理的經驗來說，不用微服務的穩定多了。我問對方負責人，你這個不用微服務架構簡單還穩定為什麼要用？負責人說，不搞這些都招不到人。別人一聽你沒有用新技術，不來了。這就是當今現實，別管好用不好用，新的就追逐。

    這個還能達成共識，下面的就比較難了。放在一起一個database裡面的SQL寫的不好，會影響這個例項上所有的database。的確是這樣的。不過一般來說管理上應該管好，大廠給出的經驗就是上線前稽核。不過國內大部分公司根本不重視這個，所以通常是以拆資料庫的方式維持著爛SQL衝擊資料庫。所以時至今日，我只要看到一個人簡歷上寫著擅長分庫分表，而且不是一線大廠，就從心裡不喜歡。中小公司的業務還要分庫分表說明，這寫的也太差了。以前有人問，我A資料庫和B資料庫可以合併嗎？我問，您能遵守開發規範嗎？對方想了想說，那還是分開吧。言下之意是，我不能遵守。

    現實就是這樣殘酷怎麼辦？前幾天在技術群內看到有人提出要做多租戶，多租戶也要面對這個問題。一個租戶（database）無節操的使用資源，其他租戶（database）怎麼辦？而這種又是非正規開發或者就是不能服從管理的人員或者團隊（SQL寫的差其實真的是管理問題還不是技術問題）。那就只有一個辦法了，資源隔離。

      資源隔離有兩個方面：

1、 限制最大的，確保資源使用不會超限。比如虛擬機器設定，包括我們資料庫Oracle的SGA_MAX_SIZE，MySQL的innodb_buffer_pool_size等引數，這種都是讓這種資源不得超過設定的閾值。

2、 保證最小的，確保資源至少供給。比如很多引數的預設值，其實都是保證最小不能低於這個。要求在使用資源的時候隔離出一個最小資源，有點像最低工資，要保證這個資料庫在大環境不好的情況下，也要活下去。不能因為整體資源緊張，就放棄了它。

    就我實際經驗而言，記憶體是最好限制的。IO是最難限制的，這裡到不是說他的取值多難，而是他會連帶把CPU也拖進來。 我經歷過一個案例是，意外的併發對一個表全表查詢，每次將近300萬次的IO物理讀，這樣大量的併發訪問某些個別資源，產生大量I/O等待，造成系統CPU的異常升高，從使用者態轉移到核心態，從而影響了全部。當時缺乏對CPU的限制。不過我覺得那個IO限制也使得我們有機會去重啟單個PDB，而不用整個CDB重啟。

     估計很多廠商都在考慮這個課題，不好做。相對好做的還是，請遵守資料庫的開發規範。這個非常容易，禁止的不要做；不能避免的看看是設計錯了，還是需求錯了。