大佬们，生产环境的 Mysql 和 Redis 都是部署在哪里的呢

可以放，把数据源挂载出来

数据量特别小：自建
数据量中等：云数据库
数据库特别大：自建

@shenyuzhi 数据量怎么划分的，太抽象了

@lujiaosama 其实就是看预算，看钱。

@lujiaosama 直接买云，等老板觉得云贵了再自建。

首先云数据库。

@vikaptain 政企都是离线的自建机房，云不了一点。

我觉得放 docker 完全没问题啊。

预算和和稳定性成正比的情况下

1. 云 serverless 数据库
2. 云数据库服务器
3. 数据库自建
4. docker 自建（一机多用）

2 楼老哥说的没错，小就自建，中等上云，大了也自建/上云

放 docker 要小心一键 clear, 比如 docker system prune -a -f, 但是数据映射到宿主机目录总是有奇怪权限问题不优雅，看你选择了，运行在 docker 应该没有问题。

docker 有 2 个坑，cpu 限制和内存限制。

生产环境大都会限制容器的资源上限，通过容器参数限制 cpu 和内存，但是容器里获取 cpu 和内存都是 docker 主机的全量值。例如：nginx 默认是根据 cpu 数量来设定 workers 的，在 32 核心 cpu 的 linux 上容器只分配了 4 个 cpu ，nginx 会根据 32 核心生成 workers 导致性能异常。再例如：在 64GB 服务器限制 mysql 容器内存最大使用量为 16GB ，会导致 mysql 用一段时间会内存溢出被 kill 。

解决方式是在容器的参数里设置与 cpu/内存限制相匹配的参数，具体可以问 ai 。

docker compose + 数据卷映射，用了快一年了，没啥问题，中途还断电重启过很多次

容器化没问题，多少年了，很多项目上都很稳定，相比部署方式，更重要的是备份。

有预算的话还是买云的省心。自己建的话用 docker 也没问题，把数据挂载出来就行，云服务商的数据库其实也是跑在容器里的

@lujiaosama #3 算账。如果你们的业务撑死了就要 3 5 个集群，加起来 100 核，那上云就可以了。如果把上面这个数乘以 1w ，那就不一样了。

小公司运维降本 20%可能就 10w 块钱，大公司运维降本 1 个点估计就 200w

接#12 对于新手，建议不要设置 mysql 、redis 容器级别的 cpu 限制和内存限制。改成在 mysql 、redis 的参数里设置资源最大使用量。

@cominghome 前提是你能上云。抠比小客户不舍得订购云数据库的钱要求自建。政企则是数据合规安全，不允许上公有云，都是自建机房连政务云都用不到。

@yinmin 哪些参数，麻烦给几个参考下，正好有相关需要

上云是最好的选择，误删恢复、冷备什么的都很方便

上云最好，用 docker 只适合用户量小的场景

根据业务量，预算这些因素来考虑，如果丢到 docker 中，一定要把备份和数据卷映射做好，尤其是数据卷映射。

中小型能云就云

这种服务不适合放到 docker ，硬要放搞个 k8s 吧，这种高鲁棒服务都需要主从+热备的，特别是数据库，redis 如果不需要持久化随便搞就行 需要的话就同样放到 k8s 统一管理 多 node 节点负载，整个 f5 或者 nginx 作为负载出口就行

就那点业务量，说句不好听的，用 access 都吃不饱，docker 绰绰有余

能问这个问题，基本上可以断定小数据+不重要，先 run 起来再说，后面又不是不能换

公司机房

用云,简单省事.不麻烦自己

中小流量项目用 Docker 跑完全没问题，注意挂定 volumes 和定期备份即可。业务量上来或对 SLA 要求高的话，用云厂的 RDS/Redis 更合适，主要是睦备份和故障转移方便。

小项目 docker 够用了吧