Close親愛(ài)的讀者：我們最近添加了一些個(gè)人消息定制功能應用的因素之一，您只需選擇感興趣的技術(shù)主題，即可獲取重要資訊的郵件和網(wǎng)頁(yè)通知預期。

　　Talk is cheap，show me the demo幅度。MySQL 到底能不能放到 Docker 里跑結構？同程旅游目前已經(jīng)有超過(guò)一千個(gè) MySQL 實(shí)例安全穩(wěn)定地跑在 Docker 平臺(tái)上。

　　前言

　　前幾月經(jīng)池暙I？吹接?MySQL 到底能不能放到 Docker 里跑的各種討論規模最大。這樣做是錯(cuò)的！這樣做是對(duì)的統籌！說(shuō)錯(cuò)的理由也說(shuō)了一大堆MySQL文章入庫(kù)助手最深厚的底氣，說(shuō)對(duì)的思想也很明確。大家都有道理振奮起來。但是我本人覺(jué)得這樣的討論落地意義不大品質。因?yàn)閷?duì)與錯(cuò)還是要實(shí)踐來(lái)得出的。

　　所以同程旅游也很早開(kāi)始了 MySQL 的 Docker 化實(shí)踐深入各系統，到目前已經(jīng)有超一千多個(gè) MySQL 實(shí)例在 Docker 平臺(tái)安全穩(wěn)定地跑著解決問題，DB 運(yùn)維能力發(fā)生了質(zhì)的提高（DBA 再也不用擔(dān)心刪庫(kù)跑路了）。

　　相關(guān)廠商內(nèi)容

　　一堂課教你看懂技術(shù)創(chuàng)新與商業(yè)模式

　　面向未來(lái)的原生化Web開(kāi)發(fā) Airbnb的閃訂功能和增長(zhǎng)策略 Dubbo開(kāi)源現(xiàn)狀與未來(lái)規(guī)劃 Apache Kafka的過(guò)去mysql文件入庫(kù)工具 作用，現(xiàn)在相互配合，和未來(lái)

　　相關(guān)贊助商

　　當(dāng)然這樣是不是可以證明之前的討論結(jié)論——是對(duì)的mysql文章入庫(kù)軟件 。我想也不一定著力增加，因?yàn)槲覀冞€只是一只在學(xué)飛行的小鳥(niǎo)智能化，還要更多的學(xué)習(xí)，所以我們特將我們?cè)?MySQL 的 Docker 化上的實(shí)踐分享給大家深入。

　　背景介紹

　　同程旅游早期的數(shù)據(jù)庫(kù)都以 MSSQL 為主技術研究，這個(gè)產(chǎn)品有個(gè)特點(diǎn)就是 UI 操作很棒重要的。但是批量和自動(dòng)化管理很難做，人力的工作很多結論。后來(lái)逐漸替換為 MySQL 后也是按照傳統(tǒng)的運(yùn)維方式管理和諧共生。導(dǎo)致大部分的工作需要人肉運(yùn)維。

　　當(dāng)然像我們?cè)缙谑褂眠^(guò)的 MSSQL 也是有優(yōu)點(diǎn)的：就是單機(jī)性能比較好適應性強，在當(dāng)年那個(gè)資源不夠的年代里我們臣夹g交流？梢栽诟呖捎玫膶?shí)例上運(yùn)行多個(gè)庫(kù)。這種情況下物理機(jī)數(shù)量與實(shí)例數(shù)量還是比較可控的拓展，相對(duì)數(shù)量比較少創造更多，人肉運(yùn)維完全可以應(yīng)對(duì)。

　　但是 MSSQL 的缺陷也很多不斷進步，比如做水平拆分比較困難工藝技術，導(dǎo)致數(shù)據(jù)庫(kù)成為系統(tǒng)中最大的一個(gè)瓶頸。但在我們使用 MySQL+ 中間件（我們做這個(gè)中間件也是下了不少心思的規模，以后可以分享一下）做水平拆分后就開(kāi)始解決了這個(gè)瓶頸mysql文章入庫(kù)軟件近年來。

　　水平拆分的引入也帶來(lái)了一個(gè)小缺點(diǎn)，就是會(huì)造成數(shù)據(jù)庫(kù)實(shí)例數(shù)量大幅上升發展目標奮鬥。舉個(gè)例子我們做 1024 分片的話一般是做 32 個(gè) node技術先進，一主一從是必須的（大部分情況是一主兩從），那么至少 64 個(gè)實(shí)例延伸，再加上應(yīng)急擴(kuò)展和備份用的節(jié)點(diǎn)那就更多了（中間件的開(kāi)發(fā)者更希望是 1024 片就是 1024 個(gè)實(shí)例）認為。

　　一次上線做一個(gè) 32node 分片擴(kuò)展從庫(kù)，兩個(gè) DBA 足足花了 4 個(gè)小時(shí)新趨勢。另外反應能力，如果做單機(jī)單實(shí)例那肯定更不行了，別的不說(shuō)學習，成本也會(huì)是個(gè)大問(wèn)題結構重塑，且物理機(jī)的資源也未能最大化利用。況且因?yàn)?MySQL 單體的性能沒(méi)優(yōu)勢(shì)所以分片居多所以大部分情況下并不是每個(gè)庫(kù)都能跑滿整個(gè)物理機(jī)的新的力量。即使有部分能跑滿整機(jī)資源的庫(kù)先進水平，它的多節(jié)點(diǎn)備份，環(huán)境一至性和運(yùn)維動(dòng)作統(tǒng)一等問(wèn)題也會(huì)讓 DBA 一頭糟全面展示，忙碌又容易出錯(cuò)的工作其實(shí)是無(wú)意義的越來越重要的位置。

　　有了單機(jī)多實(shí)例運(yùn)行 MySQL 實(shí)例的需求。單機(jī)多實(shí)例要思考的主要問(wèn)題就是如果進(jìn)行資源隔離和限制共同學習，實(shí)現(xiàn)方案有很多順滑地配合，怎么選mysql文章入庫(kù)軟件？KVM效高，Docker前沿技術，Cgroups 是目前的可以實(shí)現(xiàn)隔離主流方案基礎。

　　KVM 對(duì)一個(gè) DB 的隔離來(lái)說(shuō)太重了，性能影響太大多種方式，在生產(chǎn)環(huán)境用不合適對外開放。這是因?yàn)?MySQL 運(yùn)行的就是個(gè)進(jìn)程而且對(duì) IO 要求比較高，所以 KVM 不滿足要求 (雖然優(yōu)化以后 IO 能有點(diǎn)提升)深入交流研討。

　　cgroups 比較輕資料，雖然隔離性不是很高，但對(duì)于我們的 MySQL 多實(shí)例隔離來(lái)說(shuō)是完全夠用了（Docker 的資源限制用的就是 cgroups）關註度。但是我們還想針對(duì)每個(gè) MySQL 實(shí)例運(yùn)行額外的管理進(jìn)程 (比如監(jiān)控等等)橫向協同。用 cgroups 實(shí)現(xiàn)起來(lái)會(huì)比較復(fù)雜，并且我們還想讓實(shí)例管理和物理機(jī)區(qū)分開(kāi)敢於挑戰，那 cgroups 也放棄不斷創新。

　　至于 Docker，那就很不錯(cuò)了提供了遵循，那些裸用 cgroups 的麻煩它都給搞定了參與水平。并且有 API 可以提供支持，開(kāi)發(fā)成本低服務效率。而且我們可以基于 Docker 鏡像來(lái)做部署自動(dòng)化情況較常見，那么環(huán)境的一至性也可輕松解決。所以最終我們選擇了 Docker 作為云平臺(tái)的資源隔離方案 (當(dāng)然過(guò)程中也做了很多性能主要抓手、穩(wěn)定性等的適配工作，這里就不贅述了)構建。