面试题：为什么 MySQL 不要使用 Docker 部署。。。。

[michael2016]

如果你去找工作，遇到我问你以下几个问题如何回答：

1. 在大厂 MySQL 是不能用 Docker 的，为什么？
2. 今天业务被 DDoS 了，你如何在 10 分钟内解决问题？
3. 如果被爬虫爬了，你应该如何解决？
4. RAG 和 Agent RAG 有什么区别？

问题一再换个表达方式：在生产环境中不推荐使用 docker 运行 MySQL ，简单简述一下你的经验和最佳实践。

[tpxcer]

1.在大厂 MySQL 是不能用 Docker 的，为什么？

谁规定的，别进去

2.今天业务被 DDoS 了，你如何在 10 分钟内解决问题？

切服务器好了，老早准备好备用了。

3.如果被爬虫爬了，你应该如何解决？

日志统计，处理就好了。

4.RAG 和 Agent RAG 有什么区别？

沙雕面试官 GPT 都不会用。

[viking602]

2025 年了怎么还有数据库不能容器化这种问题

[moefishtang]

影响磁盘 I/O 性能？

[InDom]

1. 谁?
2. 上高仿, 或者我这有一套不用一直挂着高防的方案卖你三万
3. 上反爬
4. 不知道

[EastLord]

有没有大厂的哥们来回答一下 第一个问题

[BeforeTooLate]

各种云的数据不都是 docker 化的吗

[newaccount]

1. 在大厂 MySQL 是不能用 Docker 的，为什么？
不知道啊，我们一直用 docker 跑的啊，跟这里的环境相比，应该算是大厂吧

2. 今天业务被 DDoS 了，你如何在 10 分钟内解决问题？
给服务商打电话啊，买他们服务就是解决这个的

3. 如果被爬虫爬了，你应该如何解决？
爬就爬呗，线上数据不就是大家抄来抄去的，要是量太大影响业务就给服务商打电话，十分钟搞不定明年换别家

4. RAG 和 Agent RAG 有什么区别？
不知道啊，平时有另一个小组负责这些东西，你要不急我就打个电话让他来回答一下

[laminux29]

不建议新人在生产环境用 docker-Mysql 是为了防呆，或者说为了防止不熟悉 Docker 的人被坑。

docker 与正经的 OS ，有很多流程不一样，比如启停流程。大部分人学习 Mysql 是基于正常 OS 的，而 docker-Mysql 有很多行为与 OS-Mysql 不一样，不熟悉 Docker 的人很容易被坑。

[xiaomushen]

在网上：MySQL 不能用 docker 部署，理由 N 条
在实际：MySQL 扔一个，真香

[fxxkgw]

我们是大厂 数据库全部容器化 回答完毕

[Oxygen2025]

搞笑呢，还真是面试造火箭

[npe]

为啥不能？ 猜测：小白，不懂挂载数据目录，删除了容器数据丢失了。

[lovedoing]

@EastLord 生产确实不用，容器化并不能解决 MySQL 的瓶颈问题，反而会增加运维复杂度

[untitledabc]

怎么可能不用 docker 部署，出这种问题的人大部分半桶水。

[xmt328]

@newaccount 甲方区答案

[wqhui]

数据卷记得挂载出来就行，各种云厂商提供的数据库大概率也是容器化的东西

[mosesyou]

容器化一般是无状态的,优势在于动态扩缩容方便和利于迁移.mysql 容器化没什么优势,可能配置不当还会影响 io 速度吞吐量,高负载场景更不用说了,不利于 mysql 这种有状态服务.

[acorngyl]

服务部署区分有状态和无状态。无状态推荐容器化，有状态特别是重度有状态的，容器化容易丢配置。虽然 Mysql 也没什么好丢的吧。但是如果都给 dba 关的化，他们习惯一起物理了。

[zwt9407]

我们公司这两年从物理机迁移到 k8s 。优势很明显，十几个 dba 就可以管理公司上万个数据库，机器跟存储都节省了近 1/3

[xsen]

@laminux29 #8 docker 都用不明白的，还是转行算了

[Richared]

@EastLord #5 主要是 mysql 这玩意用不到容器化的那些优势，反而会有拖累。而且有专门的集群的人去部署这玩意，又不需要其他人管，我们都是有专门的 mysql 机房，需要用去申请就完了。写代码的，管人组件怎么部署的，用就完了，有问题找集群的人被，他们就是干这个的。

[fengpan567]

只有生产不能用 docker 部署，docker 存在额外的网络和磁盘开销，还有容器重启导致数据丢失的风险

[capric]

@moefishtang volume 映射不影响文件 io 性能，cpu 就是本地进程不影响性能，唯一有影响的就是非 host 模式下网络 io 会有 5%-15%的性能降低

[dssxzuxc]

1. docker 部署数据库服务有 I/O 和网络的额外开销，虽然绝大部分场景完全可以忽略，并且可以通过某些手段缓解。能问出这种问题，说明他曾听说早期 docker 实践的一些问题，现在还问可能是被 the world 暂停了五年。
2. 花钱
3. 国外上 cf ，可以防住大部分脚本小子；接口加解密给脚本小子增加难度；接口被爬了就爬了，互联网环境本来就是不可信环境，如果担心爬虫问题就别放到公网，先问问自己是不是接口太过弱智了。
4. 新一代的八股文，RAG 依赖知识库，Agent 依赖工作流

[kuxuan]

我的小骗 2C2G 肯定不用 Docker 吧，直接的话，少占内存。

[Meteora626]

像 k8s 集群部署 mysql 底层不也是容器化技术？

[maichael]

“在大厂 MySQL 是不能用 Docker 的，为什么？”

关于这种已经带了立场且缺乏上下文的面试题，首先是不要带上你自己的立场去评判它正确与否，你应该做的是合理到位的去阐述你的观点。

无论是面试官还是被面试者也好，都应该知道这不是一道判断题，没有标准答案可言，在不同的环境、需求下会有不同的答案。

所以对于被面试者而言，你应该做的是结合你的经验、理解去阐述清楚，什么时候能，什么时候不能，为什么能，已经为什么不能等。

而对于合格的面试官而言，不应该去纠结被面试者回答的是能或者不能，而应该通过被面试者的回答来评估被面试者的逻辑思维、技术理解深度等方面的能力。

另外，对于被面试者而言，一定不要在面试中全程跟着面试官的节奏走，要大胆的打破节奏，表现出你的能力，面试是个动态的互动过程，不是应试做题，不要限于条条框框。

[dlmy]

@newaccount 典型的老白兔式回答，跟：“这个需求做不了、我以前都是这么做的、这个不归我负责” 有着异曲同工之妙 :)

[wanmyome]

在大厂 MySQL 是不能用 Docker 的，为什么？

有没有可能是法律问题，毕竟镜像和源全挂了

[Sendya]

我们这除了大型集群提供了公司级独立的 MySQL 实例可用，部门内部的偏小项目一般都是容器直接拉一个，在当下这个追求效率的年代，哪有那么多规矩

MySQL 放 docker 里也没网上传的那么玄乎的问题，甚至需要的话放 docker 里的 MySQL 照样做主从，双主

[wxxxcxx]

Mysql 出现问题--->找 Mysql 专家
Dokcer 出现问题--->找 Docker 专家
Docker 中的 Mysql 出现问题--->找 Docker ，Mysql 双料专家

当然也可以找两个不同领域的专家协作解决问题，但同时也会带来沟通成本的上升。
Docker 对于有状态的服务并没带来什么实质性的好处，反而会增加解决问题的成本。

[deplives]

能问出这种问题的，我一般会拍拍屁股走人

[michael2016]

@dssxzuxc 看了你的回答说明你还是了解实践过，有点料，但不多。这很明显是一个掉坑问题，如果实践过，你会发现不同的场景关注目标点和 ROI 完全不一样，分两个场景讨论：生产环境、测试或预发环境。
生产环境：
在生产环境中，稳定性和数据安全是第一位的，关注点放在架构尽可能简单化、资源使用率最大化、可管理监控成本，精细化的运维工作需要解决数据持久化、高可用、性能优化、备份和监控、安全漏洞、供应链风险等所有复杂问题，我们需要降低了运维成本，把人从这些不必要的工作中解放出来。
测试环境：
这个环境关注高效、快速交付，它能快速、一致地搭建数据库环境，避免了版本差异带来的问题，即开即用，资源周期短。

2.DDoS 本质是一个资源问题，这是技术问题，不是问你也能用钱成本的问题，你需要解释 DDoS 攻击类型，不同的攻击类型如何应对，攻击场景不一样，处理方式不一样，成本代价也不一样。

3.如果把你的客户数据、商品信息都爬走了，我相信你可能不是这样讲了，这里面要看数据价值、资源运行负载等稳定性相关的问题，这些问题看起来简单，实际处理面对非常复杂，攻击方式从简单到高阶的拟人方式，应对成本会从小到巨大，严重情况下会让业务停摆，公司关门。

4.最后一个问题讲了大概，具体原理要分步骤讲清楚实现方式、技术原理、利弊。

看了大家回答的问题，也就你从技术上回答的稍微沾边，但是对待技术态度不够深刻。其它的人就不说了，没有去深度思考，随意情绪化表达。年轻有时间还是要多深度学习。

[lvlongxiang199]

你是哪家公司的 ? 我避避雷

"在大厂 MySQL 是不能用 Docker 的，为什么？" 抛开事实, 只谈论这个问题的问法, 答主似乎假设大厂做的都是对的, 也没考虑大厂是否因为非技术的历史原因选择这条路. 不如换个问题, 生产环境上, MySQL 跑在 docker 里, 有什么优缺点

另外, 大厂的 MySQL 真不跑在 docker 里吗 ? 那为啥会有 https://dev.mysql.com/doc/mysql-operator/en/ https://kubeblocks.io/ 这些项目 ? 起码有些公司在用

[lvlongxiang199]

@michael2016 "在生产环境中，稳定性和数据安全是第一位的，关注点放在架构尽可能简单化、资源使用率最大化、可管理监控成本，精细化的运维工作需要解决数据持久化、高可用、性能优化、备份和监控、安全漏洞、供应链风险等所有复杂问题，我们需要降低了运维成本，把人从这些不必要的工作中解放出来。
"

说了一段没用的废话

如果按照这些标准, k8s operator 都比裸金属部署更合适呢 ?

[michael2016]

@Richared 你讲到了现实矛盾，挺好，说明你经历过体验过，这里面很多技术和管理问题混杂，没那么容易，很多问题。

[lvlongxiang199]

"JD.com: MySQL Containerization and Elastic Scheduling in E-commerce Scenarios"

https://kubeblocks.io/blog/run-databases-on-k8s-insights-
from-leading-chinese-internet-companies

看来在 OP 眼里, jd.com 不算大厂

[lvlongxiang199]

url 是这个: https://kubeblocks.io/blog/run-databases-on-k8s-insights-from-leading-chinese-internet-companies
@lvlongxiang199

[michael2016]

@lvlongxiang199 这个问题应该这么问：在生产环境中不推荐使用 docker 运行 MySQL ，简单简述一下。你要根据你的工作经验详细原理或踩过的具体的坑？

[michael2016]

@lvlongxiang199 PR 跟实际情况可能相差很远，你如果只看这个没有实践过我们就不讨论了，你是对的。
如果你管理过几万台机器，我们可以深度交流一下。

[DefoliationM]

在大厂 MySQL 是不能用 Docker 的，为什么？
没关系，我还可以用 kubernetes ，podman ，containerd 。
今天业务被 DDoS 了，你如何在 10 分钟内解决问题？
不加 cdn ，waf 就忍着吧。
如果被爬虫爬了，你应该如何解决？
套个 cloudflare ，自动解决。
RAG 和 Agent RAG 有什么区别？
几乎没区别，喜欢咬文嚼字怎么不去搞政治。

[shenlanAZ]

我又想起了这么个事

[michael2016]

@mosesyou 优秀的答案，如果你是实践过的出来的结论更加优秀。

[rebbie]

技术岗：这个能不能需要辩证来看，最合适的才是最好的。主要有以下几方面的考量：1.数据持续化 2.上线复杂度。3.架构弹性 4. 运行成本、5. 运维复杂度，6 、。。。
管理岗：谁说不能的？领导需求上容器我们就上容器，容器多便宜啊
市场岗：这个要看客户的预算和需求
运营岗：我不管，能用就行
运维岗：上了容器，数量增多维护更加困难了

题外，问这种问题的公司少去，揣着明白装糊涂。不给隐含前提，提前预设答案。有点脑子的公司问的是 MySql 适不适合在容器里部署。 正规的公司问的是，MySQL 和容器都有哪些最佳实践。

[latifrons]

看过原文，里面没一个解释是经得起推敲的，总结下来就是，怕你用不来 docker ，所以不推荐你用。
事实上我们在生产上各种 OLTP 、OLAP 数据库、MQ 、Redis 全部容器化用得飞起，爽的一批

[snw]

大厂生产环境用 MySQL ？？

[superchijinpeng]

2025 年了，还说大厂 MySQL 不能容器化，政府的那些国产化数据库都容器化部署了

[butanediol2d]

https://dev.mysql.com/blog-archive/mysql-with-docker-performance-characteristics/

TLDR: 在生产环境中使用 Docker 部署 MySQL *在性能上*也并不存在不可行的理由

[BeforeTooLate]

>在生产环境中不推荐使用 docker 运行 MySQL
这种问法在当前时间点也不对的

[junkk]

我的理解是性能问题？

当然我研究不深，我个人在 win 下容器化开发，php 的执行很慢，好像是 io 问题

不推荐 docker 我想到的只有一个性能问题，比如内存啥的，来个老哥解惑下

[Ayanokouji]

买的 RDS 还是虚拟上运行的容器部署的，有啥不行的，菜就多练。

[rekulas]

面试官是不是拿错了,这份题是 10 年前的

[hefish]

第 2,3 题我会， 打 110 报警。

[boringwheat]

这题我背过，但是现在完全记不得了，我来公司第一件事就是把数据库全部切到 RDS

[xmh51]

问题换成中厂会好点 大厂的运维团队给力，能够兜住容器化的 mysql 。小厂一般遇不到容器化导致的问题，只需要保证数据不丢失即可，性能不是重点。中厂业务复杂，负载大，运维资源较少，撑不住中间件和数据库的运维，使用云厂家的是最佳选择。

[julyclyde]

先定结论再找证据那就没啥意思了
跟文科专家的“论证”似的

其实工科应该是开放式的问题：
要求你讲述用和不用容器的区别，并给出各自问题的解决方法

[exonuclease]

在大厂 MySQL 是不能用 Docker 的，为什么？我用云服务托管的 instance 我哪知道是 host 在什么上面的
今天业务被 DDoS 了，你如何在 10 分钟内解决问题？- 试试看能不能用 WAF 清洗掉 不行就 engage 安全团队
如果被爬虫爬了，你应该如何解决？ Engage 安全团队

[exonuclease]

反爬虫这个我记得我们的反代自带 throttle 策略的 如果他换着 ip 带着正常用户的 token 非要扒拉这个数据那让他去吧 他成本已经够高了

[felixcode]

当年虚拟化很多人都接受不了，觉得和物理机相比稳定性会差很多

[michael2016]

@hefish 哈哈，报警前咱们不是得自己先止血？

[michael2016]

@xmh51 嗯，我想表达的是对于并发性能、网络延时要求高的业务场景也是各种救火，稳定性挑战很大，当然投入的资源代价也很大。

[sky3hao9]

技术差就别出面试题出来丢人了

[michael2016]

@Ayanokouji RDS 本地盘式物理机，云盘是容器，但是实践下来本地盘比 on ecs 要好多了，尤其是独享环境。

[dynastysea]

@lovedoing 谁告诉你不能用的？云上数据库都是跑在容器内的

[michael2016]

@felixcode 现在依旧是虚拟环境比物理机稳定性差，不行你去各大云厂商买几台机器部署业务试试看，你可能会天天提交工单。

[nvksie]

因为大厂有完善的基础设施，有专业的 dba 团队单独维护，自己搞 docker 就是挖坑埋雷

[michael2016]

@dynastysea 你的业务 QPS 有没有超过 5 万？

[lovedoing]

@dynastysea 我有说不能用吗，我只是说我们不用，ok ？你去看看大厂的交易系统，几个敢用容器的

[moen]

第一个这个所谓的不能用言论源于 https://myopsblog.wordpress.com/2017/02/06/why-databases-is-not-for-containers/ 这篇 2017 年的博文。国内看到的基本就是这篇文章的洗稿复读，把里面所谓 7 个理由排列组合一遍，甚至这两年还能看到洗稿复读的文章出现原文里的版本号。原文里提及的问题又没有列出 issue 进行佐证

一直复读这个的似乎是觉得这么多年就没有任何技术发展。放到 IaaS 刚出来的时候估计会说数据库不要放云服务器里

[dynastysea]

@michael2016 几十万都可以，容器化和 qps 又没啥关系，不过从你前面的回复看，你拿本地盘和云盘比。。你没搞懂两者的差异啊

[edisonwong]

@michael2016 #64 [天天提交工单] ？ 6...
前司阿里腾讯都用几千台 ecs cvm ，最容易出问题的大数据带本地盘的，其余的机器问题不大

[felixcode]

@michael2016
已经有这么多生产系统大规模部署在虚拟环境了，还能看到你这样的言论，让我以为现在是十年前或更早。

[xuanbg]

@tpxcer 被 DDoS 了切服务器有个鬼用，无非就是换一台服务器被打满流量罢了。但清洗流量就不是 10 分钟能搞得定的，你得预先准备好流量清洗方案才行。

[unco020511]

谁说 mysql 不能容器化部署了,还不是可以,只是有没有必要而已.而且很多将数据库容器化部署的呀

[michael2016]

@edisonwong 我是这么夸张的说了，大厂的技术团队在后面帮你解决了不少，如果你要自己搞，重新踩一遍坑，遇到高级问题了代价很大。

[Kumo31]

这个问题要问也是「在生产环境是否推荐...」而不是直接预设答案，下面也都指出了 op 的事实错误「在大厂 MySQL 是不能用 Docker 的」，至少我这边见过的大厂，线上百 PB 的集群都是容器化的。反观 op 的回复都是一股说教的语气，给我感觉是被时代淘汰的中年老登

[michael2016]

@dynastysea 有关系，业务 QPS 高，你的并发到后端就得具备很强的弹性收缩能力，如果无法自动化，人工规划就会出现很多成本浪费，你得提前准备 ECS 或 CVM 或服务器资源，然后再去部署交付等工作。这个问题本质上是要综合考虑成本和收益，docker mysql 运维成本高，sla 没有保证，如果你的公司有专门的几个人或数十人来支撑深挖研究，当然可以了，这里除了讨论 IO 、调度、宿主机 hang 、镜像内核各种版本管理、自我诊断修复等问题以外，还要考虑于运维管理、调度、扩容缩容等很多细节。
你一个人能不能搞定所有的问题，你愿意搞定这些问题吗？愿意付出多大的成本解决这些问题？

这个问题虽然问的不好，但是正好是深入了解业务综合性决策判断选择的最好的问题。
先审题再做题。

[kiraskyler]

磁盘 IO 上。容器默认用的 overlayfs 。开销很小吧，仅仅是打开、删除这类时候多一点点逻辑，实际读写没有影响，读写时候统计、节流时候多一点点 cgroup 计算开销，基本可以忽略。
而且也可以单独指定一个文件夹/硬盘挂载不用 overlayfs

[aino]

还有不会用 docker 都 AI 时代了

[blackmirror]

@newaccount 工作这么多年甩锅技术是精进不少

[tairan2006]

网络用--net host ，数据直接挂载宿主机，肯定能容器化

[tairan2006]

而且容器化最大好处是升级方便。楼主扯了半天优势，如果出现安全漏洞要升级 MySQL ，运维就麻了。

[dododada]

1 、mysql 容器化，一般业务量影响不大，但是 mysql 太底层了，容器什么的无所谓，也没有什么高并发业务会直接写 mysql ；如果 mysql 的数据要通过 binlog 做异地多活同城双倍的话，不要用 docker ，有网络的问题，比较吃运维的经验；

2 、被 D 了，小流量切服务器，大流量当然是花钱上高防了

3 、爬就爬了嘛，你爬我爬大家一起爬，如果账号认证请求限制投毒什么的能控制住最好，控制不住就报案抓典型，抓起来送进去，圈子里再发一发公告，就清净了

4 、不知道

3 、

[Immunize]

在某大厂，大厂除非是特定团队不会问这种问题的。以业务团队的视角回答这些问题。

1. 在大厂 MySQL 是不能用 Docker 的，为什么？
现实：用数据库团队负责的云实例，底层是怎么做高可靠的无所谓。

2. 今天业务被 DDoS 了，你如何在 10 分钟内解决问题？
现实：联系安全团队做流量清理，同时在容器平台上扩容。

3. 如果被爬虫爬了，你应该如何解决？
现实：无所谓，反正大家都在互相爬，安全团队提供一定的安全保护能力，愿意用就用。

4. RAG 和 Agent RAG 有什么区别？
现实：不知道，公司里各种 AI Agent 平台，别让我理解复杂概念，哪个能最简单让我直接把文档平台直接接入，回答的最好用哪个。

[deplives]

先问是不是，再问为什么
巧了，我司上周刚对某核心业务进行过一波压测，我是压测参与人之一。
近半年，该业务日均流量 2 个亿左右，峰值 qps 6.5w 左右，线上服务 96 台 自运营 ECS
数据库自运营 MySQL k8s 集群。除此之外还有 redis 和 Doris 。除了 6 台 es 使用的裸金属，其余全容器化部署

压测目的是摸清水位，压测目标是 10w qps ，这周刚发的压测报告，SLA 99.99 % 接口响应平均耗时 334ms

这个服务从我 20 年五月入职以来从来没出现过 D 级以上故障，出现的 D 级故障和后端数据库也没有关系，全是上游物料的问题导致我们熔断。

所以你从哪儿得出来 在生产环境中不推荐使用 docker 运行 MySQL 的结论
说实话，菜就多练

[xiayun]

Q：在大厂 MySQL 是不能用 Docker 的，为什么？
A：什么大厂？没听说过不能用 Docker 的
Q：今天业务被 DDoS 了，你如何在 10 分钟内解决问题？
A：买高防，或者分析日志 先拉黑一批 IP
Q：如果被爬虫爬了，你应该如何解决？
A：先分析日志，拉黑一批 IP ；然后让研发想办法做过反扒验证
Q：RAG 和 Agent RAG 有什么区别？
A：类似知识库和自动化脚本的区别

[unbridle]

能看出 OP 对 docker 有着什么偏见，附言里也是直接就说“在生产环境中不推荐使用 docker 运行 MySQL”，难道不是先问是不是再问为什么吗，大概率 OP 玩不转 docker 。而且 OP 自以为能解决 ddos 问题。。。所有问题都问的莫名其妙让人无语

[ceilingyear]

不是后端开发，但是也好奇答案，所以问了一下 ai;
grok:这篇 V2EX 帖子中的主要争议围绕原帖主（ OP ，michael2016 ）提出的面试题：“为什么生产环境中，尤其是大公司，不用 Docker 部署 MySQL ？”这引发了关于是否在生产环境中使用 Docker 或 Kubernetes 等容器化 MySQL 的辩论。

反 Docker 观点（由 OP 和一些评论者如 wxxxcxx 和 laminux29 支持）：他们认为 Docker 会增加不必要的复杂性，提高故障排查成本（需要同时精通 Docker 和 MySQL ），在高负载场景下可能损害 I/O 性能，并在关键生产环境中存在稳定性/数据安全风险。OP 强调大公司因这些原因避免使用，并认为需要深厚的实践经验，而非浅显答案。
支持 Docker 观点（由用户如 deplives 、zwt9407 、newaccount 、lvlongxiang199 等支持）：他们反驳称许多大规模公司成功地在容器中运行 MySQL ，并举出真实例子（如在 Kubernetes 上处理每日数十亿请求的高流量服务，实现 99.99% SLA ）。好处包括更容易扩展、资源高效和现代编排。他们挑战 OP 的前提，认为其过时或无根据，并指出像 MySQL Operator for Kubernetes 这样的项目证明了在正确实施时它是可行的最佳实践。

我赞成支持 Docker 的一方。虽然存在合理的权衡（如确保适当的持久存储和监控以避免性能问题），但容器化已被主要科技公司广泛采用在生产环境中（如通过 AWS RDS 、Google Cloud SQL 或自管 K8s 设置），因为其灵活性和效率。反 Docker 的立场似乎过于泛化，没有考虑到容器技术的发展，这些发展缓解了早期的担忧。如果问题假设 Docker 本质上不适合，那就是一个有缺陷的面试前提，因为实际部署取决于上下文，而非一刀切的回避。

[datoujiejie221]

1 不是不能用，是怕 hold 不住，上容器化不仅之前的备份、主从等自动化脚本要重新写，还得吃透 K8s+StatefulSet+企业级存储+ipvs 等等知识，任何一环没吃透都要排查大半天，之前就因为 ipvs 配置的问题导致长链接异常断开
2 没搞过，就跟洪水来了一样，想办法联系上游把洪水堵了
3 限制 ip,升级加密算法，随机增加验证码
4 agent 有决策和工具调用能力，不过更耗时，而且难以控制和调试

[DIMOJANG]

@moefishtang V2EX 惊现娜娜奇！

[Sendya]

@michael2016 #65 这个我不认可，虚拟机在宿主机故障时可以动态飘到其他宿主机上，一般在 500ms 以内就能完成硬件故障漂移，而且漂移过程会把流量也拷贝过去，我们生产经过很久的验证。如果是物理机硬件故障你怎么能够做到这些容灾？

[lizy0329]

docker 只是个壳，数据还是放在本地的，没啥影响，如果说连数据还是放在 docker 就不好了

[blackbookbj277]

在大厂 MySQL 是不能用 Docker 的，为什么？
哪个大厂，不是所有大厂，不能以偏概全。

今天业务被 DDoS 了，你如何在 10 分钟内解决问题？
为什么不买防 DDos 服务，是谁做的决定，影响的业务是不是应该追责。

如果被爬虫爬了，你应该如何解决？
为什么不部署反爬虫服务，是谁做的决定，影响的业务是不是应该追责。

RAG 和 Agent RAG 有什么区别？
多个 Agent 。

[felixcode]

“凡我二十五岁以后所遇到的事物，几乎都没有用。二十五岁以前所遇到的东西，却都非常有用。”

[Richared]

@michael2016 #36 其实他们面试一般得看面试官他自己对于哪方面强，他就会问的比较深，全靠命，有可能这个面试官和你的知识点重合高，那你就感觉面试的还可以，我有朋友在大厂，职级还不低，但是他对于容器了解很少，基本也不用。

[deplives]

这么给你说吧，能处理 5w qps 的公司一定有能力组建团队将 MySQL 容器化，或者说一定会组建团队解决你这些问题。但你非要说一个人处理这些事情。一个日均 5w qps 的公司就只招一个 DBA 和运维吗？我是不信的。

这几句话给我的感觉就是 op 是一个干啥都是高并发高可用，张嘴闭嘴几万 qps ，说句实话，我都怀疑他不理解 5w qps 意味着什么

[luzihang]

公司容器镜像都是 k8s 管理，运维平台集中管理，如果 MySQL 的 pod ，到处飘，会影响敏感业务的耗时。

[luzihang]

存储也是要提前一年规划的，存储的预算，都是 DBA 提出。

[moefishtang]

@DIMOJANG んなぁ〜（嗯呐...）

[Sendya]

@deplives #96

我来帮你往简单了算，每个请求按 2~5KB 头，1B 的 Body （ 只响应个 "1" ），大概每秒传输 20M ；头大小计算方式

这个计算方式是行业里比较标准的流量计费方式，这里面我就不帮忙考虑重传了，一般就算网络质量非常好，也会考虑 1~3%的重传比消耗；

在我看来，很多小公司开个 4M,5M 上行带宽的机子 嚷嚷要万级 qps 其实就挺好笑