來源：toutiao.com/i6675622107390411276/
容器的定義：容器是為了解決“在切換運行環境時，如何保證軟體能夠正常運行”這一問題，
目前，容器和 Docker 依舊是技術領域最熱門的詞語，無狀態的服務容器化已經是大勢所趨，同時也帶來了一個熱點問題被大家所爭論不以：資料庫 MySQL 是否需要容器化？
認真分析大家的各種觀點，發現贊同者僅僅是從容器優勢的角度來闡述 MySQL 需要容器化，幾乎沒有什么業務場景進行驗證自己的觀點；反過來再看反對者，他們從性能、資料安全等多個因素進行闡述 MySQL不需要容器化，也舉證了一些不適合的業務場景，之前推送過一篇文章：
下面，我們就聊一下 Docker 不適合跑 MySQL 的 N 個原因！
資料安全問題
不要將資料儲存在容器中，這也是 Docker 官方容器使用技巧中的一條，容器隨時可以停止、或者洗掉，當容器被rm掉，容器里的資料將會丟失，
為了避免資料丟失，用戶可以使用資料卷掛載來存盤資料，但是容器的 Volumes 設計是圍繞 Union FS 鏡像層提供持久存盤，資料安全缺乏保證，如果容器突然崩潰，資料庫未正常關閉，可能會損壞資料，另外，容器里共享資料卷組，對物理機硬體損傷也比較大，
性能問題
大家都知道，MySQL 屬于關系型資料庫，對IO要求較高，當一臺物理機跑多個時，IO就會累加，導致IO瓶頸，大大降低 MySQL 的讀寫性能，
在一次Docker應用的十大難點專場上，某國有銀行的一位架構師也曾提出過：“資料庫的性能瓶頸一般出現在IO上面，如果按 Docker 的思路，那么多個docker最終IO請求又會出現在存盤上面，現在互聯網的資料庫多是share nothing的架構，可能這也是不考慮遷移到 Docker 的一個因素吧”，
其實也有相對應的一些策略來解決這個問題，比如：
1）資料庫程式與資料分離
如果使用Docker 跑 MySQL，資料庫程式與資料需要進行分離，將資料存放到共享存盤，程式放到容器里，如果容器有例外或 MySQL 服務例外，自動啟動一個全新的容器，另外，建議不要把資料存放到宿主機里，宿主機和容器共享卷組，對宿主機損壞的影響比較大，
2）跑輕量級或分布式資料庫
Docker 里部署輕量級或分布式資料庫，Docker 本身就推薦服務掛掉，自動啟動新容器，而不是繼續重啟容器服務，
3）合理布局應用
對于IO要求比較高的應用或者服務，將資料庫部署在物理機或者KVM中比較合適，目前騰訊云的TDSQL和阿里的Oceanbase都是直接部署在物理機器，而非Docker ，
狀態問題
在 Docker 中水平伸縮只能用于無狀態計算服務，而不是資料庫，
Docker 快速擴展的一個重要特征就是無狀態，具有資料狀態的都不適合直接放在 Docker 里面，如果 Docker 中安裝資料庫，存盤服務需要單獨提供，
目前，騰訊云的TDSQL（金融分布式資料庫）和阿里云的Oceanbase（分布式資料庫系統）都直接運行中在物理機器上，并非使用便于管理的 Docker 上，
資源隔離方面
資源隔離方面，Docker 確實不如虛擬機KVM，Docker是利用Cgroup實作資源限制的，只能限制資源消耗的最大值，而不能隔絕其他程式占用自己的資源，如果其他應用過渡占用物理機資源，將會影響容器里 MySQL 的讀寫效率，
需要的隔離級別越多，獲得的資源開銷就越多，相比專用環境而言，容易水平伸縮是Docker的一大優勢，然而在 Docker 中水平伸縮只能用于無狀態計算服務，資料庫并不適用，
難道 MySQL 不能跑在容器里嗎？
MySQL 也不是全然不能容器化，以下幾種場景還是適合的，
1）對資料丟失不敏感的業務（例如用戶搜索商品）就可以資料化，利用資料庫分片來來增加實體數，從而增加吞吐量，
2）docker適合跑輕量級或分布式資料庫，當docker服務掛掉，會自動啟動新容器，而不是繼續重啟容器服務，
3）資料庫利用中間件和容器化系統能夠自動伸縮、容災、切換、自帶多個節點，也是可以進行容器化的，
典型案例：同程旅游、京東、阿里的資料庫容器化都是不錯的案例，大家可以自行去查看，
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2021最新版)
2.別在再滿屏的 if/ else 了，試試策略模式，真香！！
3.臥槽！Java 中的 xx ≠ null 是什么新語法？
4.Spring Boot 2.5 重磅發布，黑暗模式太炸了！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/299851.html
標籤：其他