运行一个 nginx 并映射端口。# 清理所有停止的容器和悬挂镜像。# 进入容器修改配置。# 保存修改到新镜像。

是一个开源的，最初由 Google 开发，后来捐赠给 Cloud Native Computing Foundation。

默认情况下：优先使用docker logs -f --tail 200 <容器名>实时跟踪。应用自身日志：建议也输出到 stdout/stderr，同时写入文件，方便和文件持久化两种方式。生产环境：使用json-file驱动并配置max-sizemax-file，或者采用等集中日志系统。不要手动删除/var/lib/docker/containers下的json.log文件，应使用truncate

真正复杂的是这一段。

机制（比如通过 Redis Pub/Sub、MQ、RPC 通知等）让所有节点同时删除本地的 Caffeine 缓存。如果每个节点都自己做延迟双删，第二次删除时只能删自己节点里的 Caffeine，删不到别的节点。延迟一段时间后，再次删除 Redis（第二次） —— 这就是延迟双删中的第二次删除。读：先读 Caffeine（本地），读不到再读 Redis，再读不到查数据库。负责让所有节点的 Caff

Feign：找到 URL 去请求Dubbo：找到 Invoker 直接调用。

CAS 的高效，核心在于两个层面，避免了传统锁的诸多开销。：线程获取锁失败，会进入阻塞状态（如调用），这需要操作系统介入，完成“用户态 → 内核态 → 用户态”的切换。一次上下文切换的代价可能高达几万到几十万个 CPU 时钟周期。：全部操作都在完成。它只是一条 CPU 原子指令（如 x86 的cmpxchg执行时，要么成功，要么失败立即返回，不会主动让线程挂起。这避免了系统调用和上下文切换的昂贵开

运行一个 nginx 并映射端口。# 清理所有停止的容器和悬挂镜像。# 进入容器修改配置。# 保存修改到新镜像。

下面按面试最清晰的逻辑拆开讲。

无锁 → 偏向锁（单线程）→ 轻量级锁（自旋）→ 重量级锁（阻塞），全部通过 CAS 修改对象头 Mark Word 实现，目的是在低竞争时避免操作系统互斥量开销。