DadaVinCi's Blog

RAG 系统中的文档频繁新增、修改和删除，会带来向量化成本、索引维护和数据一致性等问题。合理的设计需要先过滤无效变更，再按变更类型分别处理，并通过版本切换、异步清理和全链路对账保证稳定性。

Goal 模式把一次性的指令变成一份跨多轮有效的完成契约：用户定义目标和完成证据，Agent 每轮执行一部分工作，外层 Harness 保存任务状态，并在满足条件时安排续跑。

它的关键不是让模型一直生成，而是把目标、续跑资格、完成判定和停止条件放进一个可管理的闭环。

私聊和群聊用同一套数据做已读。每个会话的消息按序号只存一份，每个用户在这个会话里只存一个水位线。私聊拿对方那一个数，把消息显示成已读或未读。群聊拿其余成员的水位线，数出「几人已读」。两边都不要把已读写回消息正文。

离线任务用 Job 包装一层，跑完即结束。在线任务如果只用裸 Pod，restartPolicy 默认是 Always，容器异常退出后会被拉起；但 Pod 被删除、节点宕机时，容器级策略无法补救，实例会直接消失。需要多副本时，数量、健康和更新也只能靠人工维护。

处理方式仍然是对象组合：Pod 只负责容器，在线业务再套一层控制器。这一层有两种，调度策略不同：

• Deployment：在集群中维持 N 个相同副本，不指定必须落在哪台机器。Nginx、WordPress 这类业务用它。
• DaemonSet：每个节点恰好运行一个 Pod，与节点绑定。kube-proxy、日志采集、监控代理用它。

多节点集群里，这两种差别才明显。

上一讲说了，Kubernetes 调度的最小单位是 Pod，不是容器。那是不是写个 Pod 就能上业务了？还不行。

一个 echo 跑完就退出的 Pod，会被反复拉起，最后变成 CrashLoopBackOff。Nginx 这类长期在线的服务没有这个问题；日志分析、转码这类“算完就退出”的任务则会踩中默认重启策略。另外，端口、密码如果写死在镜像里，改一次配置还得重新构建镜像。

所以先要把任务分成在线和离线。分清了，才知道什么该直接用 Pod 的默认行为，什么该用 Job / CronJob 包一层。配置再用 ConfigMap / Secret 从外面注入。

容器已经很成熟了，为什么 Kubernetes 还要再抽象出一个 Pod，而且几乎所有人都说它是最核心的概念？

最近在学极客时间《Kubernetes入门实战课》，把第 10 讲工作机制这一块过了一遍。这篇文章是我学完之后的一些总结，主要想把自己理解的架构、组件和协作方式写清楚，后面排障时也有一条能顺着走的线。

容器解决的是“应用怎么打包、怎么分发”，真正难的是后面那一堆运维问题：调度到哪台机器、挂了怎么恢复、网络怎么通、状态怎么盯。Kubernetes 能成为事实标准，我觉得不只是因为它出身 Google，而是它把这些事抽象成了一套能自己运转的工作机制。

严格单调递增 ID 很难水平扩展，而基于时间戳的趋势递增 ID 放宽了全局顺序要求：只要整体随时间递增，局部允许少量乱序，就可以让多个机房、多个服务实例并行生成唯一 ID。Snowflake 的核心价值，就是把时间、机房、实例和毫秒内序列号编码进一个 64 位整数里。

高并发写场景可以通过数据分片把数据或请求拆成多份并行处理，数据库中的典型实现是分库分表；分表解决单表数据量问题，分库解决单库并发和资源瓶颈，垂直拆分侧重业务和字段拆分，水平拆分侧重数据行拆分，而范围分区、哈希分区、一致性哈希和从库升级扩容共同构成了分库分表落地时最关键的数据路由与扩容能力。

分库分表之后，单库自增主键不再能保证全局唯一；而 UUID 虽然生成简单，却存在空间占用大、写入索引不友好等问题。真正适合亿级流量系统的唯一 ID，需要在全局唯一、空间占用、高并发、高可用和数据库主键友好之间取得平衡。