共计 1830 个字符，预计需要花费 5 分钟才能阅读完成。
起源：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 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！