演講嘉賓簡介：陳招尚（勝通），資深DBA崗位從業者，有着十三年資料庫領域從業經驗，目前負責阿裡雲資料庫RDS、專屬叢集MyBase産品管理工作。重點參與和負責阿裡集團去O、雙十一資料庫管理等工作，對中大型企業的資料庫管理工作有很豐富的經驗。
以下内容根據演講視訊以及PPT整理而成。
觀看回放
https://developer.aliyun.com/live/245325 更多課程請進入“資料庫大講堂”了解 https://developer.aliyun.com/topic/database/lives本次分享主要圍繞以下四個方面：
一、自建資料庫需要考慮的問題
二、阿裡巴巴内部資料庫的部署曆史
三、經驗總結
四、雲資料庫專屬叢集
其實無論是在雲上還是雲下，尤其是雲下都是自建資料庫，在自建資料庫過程中DBA需要考慮很多問題。如下圖所示，是曾經受困擾居多的一些執行個體。
首先是資料庫高可用問題，第二是提升資料庫資源利用效率問題，在提升資料庫資源利用效率問題的同時又需要去解決資源瓶頸方面的問題，當然作為DBA運維資料庫還存在運維幸福感的問題，否則連夜工作會影響到健康及生活。随着公司的業務發展或是各方面的情況，公司還有節省成本的一大要求。
自建資料庫時會遇到的主要困擾如下圖所示。DBA基本的崗位要求是應該将資料庫管理好，裝成有卻無。如果資料庫産品沒有問題并且每年為公司節省成本，從公司管理層來說這是DBA管理工作者的基本功。資料庫能否正常如所料想的去運作，其實在實際中還會受到很多因素的影響，這些影響因素會導緻資料庫存在一些問題，這時大部分情況下DBA會被拉出來背鍋，因為資料庫是最先需要處理的情景且無法擴機器解決。另外DBA人數和研發人數的比例嚴重失衡，研發者有一百或二百人，但DBA在疲于支援業務的同時還要解決運維間的問題，這就導緻了失衡。DBA如果在業務上支援的多一些那麼運維上投入就會少一些，運維一旦變少就會疲于支援業務上的問題，是以這兩者是互相制約的。
從這些角度來說自建資料庫要考慮的問題還有很多的，在過去很長一段時間裡為了解決這些問題阿裡采用了很多方式。例如為了提升運維幸福感，在處理小業務時為防止夜晚出現挂掉的情況出現，就會采用延時處理機制進行處理，根據這些業務的特點其實不會存在大問題，但是這樣操作會提升運維幸福感。
是以作為DBA要盡最大努力并且一定要盡職做好工作，否則就會背鍋擔責，類似高危職業。擔任DBA如果遇上聚會或是旅遊需要随身攜帶電腦，也是為了防止出問題可以及時解決。
下面從阿裡巴巴内部資料庫的部署曆史來了解如何部署資料庫。尤其是MySQL的出現，MySQL在十多年前的版本比較低，并且沒有運用于大型系統中，是以MySQL的運用規模較小。
1.穩定性壓倒一切
部署形态很簡單，相對以前來說機器硬體能力在不停提升，是以當時是處在如下圖的簡單部署當中，将所有的主機電源全部部署在一台機器上。由于公司的業務高速發展，是以在後端運維崗位的投入包括ID的資本投入都是非常大的。
連接配接數問題：從DBA的角度來說要穩定性壓倒一切的，就要選擇合适的部署方式，例如一台機器部署三個執行個體，這三個執行個體同時提供服務，隻要這台機器資源使用率夠用就使用該種部署方式。這樣的部署在以前的平時是沒有問題的。但是曾經在雙十一時遇到過由于業務壓力突然上漲而出現問題。如果一條資料庫的執行個體實際服務兩百台應用服務區，在平時連接配接到資料庫中隻有五個連結，這時正常情況下這條執行個體隻有一千個人連接配接，但是如果在高壓的情況下例如雙十一，應用伺服器可能會默默的從兩百台擴充到一千台，為了撐住壓力連結數一般會設定到二十、四十，這時突然到資料庫裡的連接配接可能達到上萬或是超過一萬。這樣系統面臨的情況就是應用資料庫本身和各個方面都沒有異常，但是應用的響應時間非常高。在當時MySQL5.1版本下，如果MySQL連結數建的很高，在處理連接配接時會存在很大的問題，壓力大對資料庫的響應時間會很長。這是當時面臨的第一個挑戰，阿裡花了很長時間才解決此問題。
主機當機問題：第二個挑戰，如圖所示，如果一台主機挂掉三個執行個體會全部切到新機器上，這時會産生很大影響。因為三個執行個體都會發生切換，緻使受力面積變得很大，最後導緻業務受到非常大的影響，如果三個執行個體服務1/3的業務，那麼這1/3的業務都會受到影響。這是第一個階段，接下來即便要進入第二階段也輕易不敢進入，不敢進入的原因是如果一台主機挂掉備用機器要百分百支撐起主機挂掉的情況，這裡的主機挂掉是指主機的CPU突然損壞或者常見的硬碟損壞等場景，導緻主機可能會整個挂掉，這時備用機器就要百分百支撐起來，是以兩台機器的配置都是一樣的。在成本方面，主執行個體所在的機器投入與備執行個體所在的機器投入是一樣的。
2.成本優化
由于後來業務發展超快，硬體達到指數級的投入，這時公司會做出成本優化。作為DBA想到的方法如下圖所示，實作主備交叉部署。
部分超賣：相對來說主執行個體可以用到更多資源，備執行個體使用的資源會較少些。如果主機是64核，例如兩個64核卻可以部出96核節點，這就實作了部分超賣，有賭運氣的成分。例如左邊主機挂掉就會全部切到右邊的主機上，就會超過原來64核實體上CPU總數。這是第一個面臨的問題。
讀寫分離：第二個問題，主備挂掉時如果仍想提升資源利用效率，就需要讀寫分離，将讀的請求放在備機上，這樣左側的主機與右側的主機都具有流量，使得使用率提高。同樣此操作具有賭運氣的成分，在大型大促時關掉主備自動HA切換，相信尖峰時刻機器不會挂掉，另外在業務上切了很多機器，這樣影響相對較小。
3.兼顧成本與穩定性
兼顧成本與穩定性，将不同機器進行打散，這裡引入現在仍使用的内部移山系統來資源排程，監控每台機器資源的利用效率，及時根據一些觸發條件将執行個體進行資源挪騰，讓整個執行個體利用水位保持在相對均衡的狀态，這樣使整體使用率得到很大提升。
另外應對突然主備切換，備機不具備承擔組時是冷啟動過程，需要有個預熱的過程。如果流量很大時突然啟動備庫可能會出問題，這時就需要備庫預熱。另外關于讀寫分離的問題，需要考慮到讀的流量。
整體來說根據主機資源使用率例如CPU、IO，來考慮整個叢集的水位。
4.重要系統和非重要系統交叉部署
在之前講解的模式下核心系統和非核心系統是分成兩個叢集來處理，也就是核心系統更加偏向穩定性保守部署，而非核心系統向成本優化角度部署。這時就會出現雖然知道哪個為核心系統或非核心系統，但是核心系統會突然有一天變為非核心系統。這時就存在很大問題，認定的核心業務系統卻在非核心業務系統叢集中，這樣非核心系統會有資源争搶等問題。
另外阿裡又增加了對核心系統在此種情況下可進行資源綁定模式，有效制止了資源被争搶的情況，也就是鎖定資源，不被争搶。非重要系統也可以實作資源随時的彈性，如果今天做活動流量會漲上來，那麼就可以根據資源的利用效率将這台機器其他資源移走，這樣會實作資源利用效率整體平衡。
根據之前所講解的内容，總結出以下四條經驗。
經驗1：主備交叉部署，一種僞超配的降成本方案
如圖所示，一台機器用到96核，但是主機實際上是64核，由于主備交叉部署利用效率并沒有達到滿負載利用效率。
收益：
- 有利于CPU資源有效利用提高，整體上達到70%的- - 利用效率。
-
有利于連接配接資源達到有效利用效率。
相對來說成本更低。
注意點：
- HA機制需要做好，如果圖中左側主機挂着，什麼時候需要切，或者前面提到尖峰時刻的時間點甚至可以直接關閉HA，這是之前應對高流量的預案。
- 主機問題監控，例如CPU、磁盤，圖中所示兩台機器為一對，如果有128台機器就有64對，一定要将核心資源進行充分打散。例如在雙十一時在後端資源保障上都會将資源打散。
- 千萬不要讓主機實行滿負載運作，這點非常重要，如果在滿負載運作的狀态下挂掉，則會出現雪崩情況，因為切過去另外一台也可能會挂掉。
資料庫大講堂·第三期 親曆阿裡雲0到1的資料庫老司機解密資料庫資源排程的藝術
經驗2：應用分級，保障粒度差異化
一定要做應用分級，不同分級保障不同粒度差異化。
主要針對一般業務或是重要業務。一般業務可以利用主備交叉部署方式獲得更多的資源利用，重要業務則要使用更偏向穩定性的方案，不會使用主備交叉部署運作。另外重要業務一定要有對外SLA保障，因為很多一般業務會依賴重要業務。運用應用分級不僅可以提升整體利用效率同時也提高可用性。
兩種不同等級業務的資料庫資源模式：
當兩種不同等級業務的資料庫資源進行模式部署時，MySQL實際上是吃記憶體性的，如果分了64G記憶體MySQL基本上會将64G記憶體全部用完，是以做不到超賣記憶體。
記憶體隔離，隔離過後在一台機器上不會出現搶占記憶體的情況。如果是稍微重要的業務，例如在非重要的叢集中業務突然變得重要，這時需要綁定CPU叢集實行CPU隔離，就不會被争搶。如果是核心業務就需要将其獨立出來，進行實體機層面的隔離。
經驗3：兩種抽象的資源部署方案
無論是部署資料庫還是部署應用，做資源排程對資源最底層的配置設定方式僅為兩種：
- 均衡配置設定：如下圖右側所示，離散型資料庫執行個體分布，會優先在更空的機器上配置設定執行個體，這樣資源的利用效率會相對較為均衡，整體性會更穩定。此類方式比較偏向于核心性的業務。
- 緊湊配置設定：或者隊列配置設定，先将兩個機器全部配置設定完，再配置設定後面的兩台機器，優先在更滿的機器上配置設定資源，這時更關注成本，資源使用率會更高，但各個主機性能會表現不一。
資料庫大講堂·第三期 親曆阿裡雲0到1的資料庫老司機解密資料庫資源排程的藝術
緊湊型和均衡性交叉典型應用場景：
如果一開始是緊湊型配置設定則更關注成本，在大促時增加機器變成均衡配置設定實作資源均衡排程，大促過後要傳回成緊湊型配置設定，這時會有機器空出來就可以拿到其他地方利用。執行個體挪騰可以自動化也可手動進行挪騰。以上為應對大促和平時所采用的方案，平時時更緊湊資源使用率更高成本更低，大促時更均衡穩定性更高。大促過後再将機器替換掉。
經驗4：兩資源彈性，消除業務流量評估焦慮
講師作為DBA做了很多年開發支援的工作，也會遇到業務流量評估焦慮。
如下圖所示，業務方在做新業務時心目中的資料庫地位都是同等重要的，因為這項業務是業務方的全部，是以業務方會要求DBA重保是以資料庫的内容，從業務方的角度來看每一個資料庫都是很重要的。但是其實公司會有創新型或是實驗型的業務，在實際運作一段時間後業務一定會出現其中某些業務才是真正的核心業務（如圖中紅色圖形），而其他業務相對來說不會那麼高，或者有些業務在運作一段時間以後下線了。是以從DBA角度來看實際表現中的資料庫地位是具有差異性的方式，DBA在内部有專門處理混合型的叢集，對于混合型的叢集DBA不需要評估業務流量，隻需放入該叢集中就可以。如果某個業務突然上漲叢集可以迅速鎖定業務CPU不會被争搶，這樣在一段時間内可以保證其地位，如果業務持續上漲，就需移動到專供叢集中，在此過程中就保證了業務的重要性、穩定性和可用性。同時大大降低因為沒有評估好而被指責的機率，例如一開始的業務名額可能是到1000萬UV，或許實際隻到10萬UV（不排除真的到1000萬UV），如果DBA按照100萬UV出評估結果，那麼評估就會出錯，是以采用混合型的叢集方法就能降低出錯機率。
在了解完阿裡巴巴資料庫的部署實踐及累積的經驗分享後，下面來學習一下阿裡在雲上推出的專屬叢集形态。
1.雲資料庫專屬叢集 -- 部署架構圖
專屬叢集形态與普通PAAS叢集形态的差別：普通PAAS叢集形态購買的都是執行個體，而專屬叢集購買的則是主機，這樣可以自己建構一整套叢集模式并管理業務。
專屬叢集形态相對于普通PAAS叢集形态的好處：專屬叢集可以做超配并自行管理，可以實作主備交叉部署的資源利用，可以實作在不同機器之間資源的排程、資源的再均衡、資源的迅速彈伸和收縮等方面的能力都提供在專屬叢集中。
以上為雲資料庫專屬叢集産品的簡單介紹。總的來說，專屬叢集首先是雲上專屬資料中心，其次DBA可自主可控，最後根據不同業務實作成本最優化，提供最省成本的方案。
2.雲資料庫專屬叢集 -- 能力建設進展
目前專屬叢集能力建設基本都是支援的，除了混合部署還在研發當中，其他都已實作支援。
原資料庫的PAAS服務擁有的功能，雲專屬叢集全部都有，例如高可用、高可靠、高性能等。此外。還可以做資源的排程，關于本節課前面所分享的堆疊型、緊湊型、均衡型，通過移山進行資源均衡，資源的彈性伸縮等能力都在專屬叢集中提供。因為專屬叢集是以一個叢集主機的形式來管理資料庫資源，而不是像PAAS是以執行個體的形式管理。這款産品與本次課程講解的主機具有一定關聯，是以給大家進行了介紹。
掃碼進群答題互動環節：
感興趣的使用者可以掃碼進群讨論下面兩道問題：
問題1:（多選）如果主執行個體都在同一個主機上，我們曾經遇到的問題有哪些？
問題2：（單選）一般抽象而言，有幾種資源部署方案？