SSE 连接只存在于接受它的那台机器上，浏览器断线后会带着 Last-Event-ID 自动重连；部署成多实例后，推送要跨节点找到连接，重连落到另一台机器时要从共享历史补发，中间代理的缓冲和空闲超时也要处理。

生产环境单节点 OpenSearch 的 Dashboards 对所有用户返回 401：按 _id 排序分页留下的 12.3 GiB fielddata 占着没有上限的缓存，几个跨月聚合又把堆推过了 parent 断路器上限。文中整理了时间线、原因和防护建议。

按峰值每秒 6 万到 7 万条、每天约 2.4 TB 主分片数据推算日志集群：Kafka 缓冲、节点角色分离、写入调优和 data stream 滚动；热数据在 14 台本地 NVMe 节点上保留 7 天，快照在 S3 保留约 30 天。

多站点电商的商品数据要同时处理站点间的本地化与合规差异、品类属性差异、跨洋读延迟和大促读压力。这套 PIM / MDM 架构用两层商品模型、类目属性规则、中心打版加事件分发到大区只读副本、版本号幂等写入与对账、多级缓存来逐个解决。

三个非生产环境 14 天共 47.5 GB 的日志里，一个接口的完整响应体估算占了约 23 GB。按文件后缀、字段抽样、mapping 开销和查询模式四步找出空间去向，并估算源头截断、zstd、去掉长文本 .keyword 和不存位置信息各能省多少。

开发环境的单节点 OpenSearch 查出六个问题：自报 98% 的内存使用率把 Page Cache 算成了已用，1 GiB 多的堆页被换出到 swap，PA 的 agent 没有运行，缺少基础设施告警，默认副本让集群一直 yellow，服务日志写了两份。

开发环境单节点只存 47.5 GB 日志，OpenSearch 却平均占 0.88 核。大头是 ISM 每 5 分钟对 1,388 个索引加锁放锁，锁索引两天多才 flush，软删除攒到 185 万条；在线调参后预计降到 0.2～0.25 核。

H5 应用容器和奖池活动条由 Cloudflare Workers 上的容器页、overlay 和 EKS 里四个 Spring Boot 服务组成，结构由同源入口、一张凭证两处验签、钱只走交易平台、推送层不存状态和 overlay 固定入口发版五条决策定下。

宿主用 script 引入的叠加层，挂载点、容器 id 和清单接口的字段默认都只有一个。入口换成 custom element 后三处都解开，代价是参数降成字符串、tag name 前缀、版本声明和 shadow root 里两条方向相反的 at-rule。

在 4 核 8 GB 的压测环境里，SSE 和 WebSocket 每条连接谁占内存多，取决于用 Tomcat、Jetty 还是 Netty；单机先后受限于 maxConnections 计数器、堆和扇出耗时，多实例部署后最先出问题的是路由。