从送多少，转向先审什么
内容召回和人工审核运行在不同的节奏上。热点事件可能让召回量短时间上涨，审核产能却不能随之即时扩张；低峰期又可能出现队列缺量、人员空转。
只靠静态播放量档位送审，还会遇到另一个问题：到达某个播放量，并不一定意味着更值得审核。尚未达到档位、但风险较高且可能继续传播的内容，也可能需要更早处理。
内容池在召回与送审之间增加了一层缓冲。它一方面按审核价值排序，另一方面根据实际审核吞吐控制推送节奏，把“内容何时被召回”和“内容何时进入人审”拆开。
按业务分池，按内容更新
不同业务使用独立的内容池。视频以 ItemID 作为池内唯一标识；同一个视频再次进入同一个池，执行更新策略，而不是新增一条重复记录。
平台允许业务根据标签配置 Score 计算公式。内容入池时计算分数，以 ItemID 作为 ZSet 的 member、Score 作为排序分数。重复入池走更新路径，使同一内容在池中保持一个排序位置。
这套机制将排序规则和存储执行分开：业务表达哪些标签值得关注、如何组合，平台负责计算与维护优先级。入池计算并不等于持续实时重算；仅有标签源变化，不足以推导池内分数会自动刷新。
有限容量下保留更有价值的候选
内容池大小有限。当容量不足时，低优先级内容会被挤出，让空间留给更值得处理的候选。
因此，内容池不是保证每条内容最终都会被消费的任务队列。它承担的是候选筛选与优先级缓冲：在有限审核资源下，尽量先处理高价值内容。
这个边界也决定了观察指标。除了入池量和出池量，还值得关注被淘汰内容的数量、优先级分布，以及高价值内容等待送审的时间。单纯追求“池中所有内容清空”，并不能说明审核资源使用得更好。
从审核反馈推测产能
审核人员不需要改变工作方式。调度侧根据一定时间窗口内的实际审出数量，估算审核吞吐，并做平滑处理，避免短时间波动直接传递到推送量。
但如果完全按照刚刚审出的数量补充内容，可能形成一个不利循环：队列供给不足导致审出量下降，调度又据此进一步减少送审，最后出现空转。
因此，策略允许在估算值上增加一个上浮系数，例如审核量乘以 1.05，让审核队列持续有内容可处理。同时配置最大积压量，限制推送，避免上浮和流量波动造成队列爆量。
可以把这个控制关系理解为三步：
- 用平滑后的审出量估算下一周期的处理能力。
- 用可配置的上浮系数增加供给余量。
- 结合当前队列积压和积压上限限制实际送审量。
这里的 1.05 是可配置示例，不是所有场景的固定最优值。窗口、平滑程度和余量共同决定了策略响应速度与稳定性。
一个内容，只分配到一个队列
一个业务池可以连接一个或多个审核队列，并按配置比例分配送审内容。每条内容只会分配到其中一个队列，不会向所有队列广播。
两类规则各有职责：优先级决定先取哪些内容，配比决定把这些内容分到哪里；动态产能策略控制送审节奏与积压。
送审成功后，内容离开池子，并记录以 pool_id + item_id 为维度的幂等键。目标队列不参与这个键，因此在幂等记录有效期间，同一池中的同一内容不会因为分配到了另一个队列就再次送审。不同业务池之间则独立判断。
幂等记录的有效期决定了去重的时间范围，不能把这个机制理解为永久禁止重复送审。
ZSet 的便利与扩展边界
ZSet 很适合这一版需求：通过唯一 member 更新内容，按分数维护顺序，并从高优先级一端选择送审候选。
但随着池子增大，把全部排序放在一个 key 中也形成了扩展约束。问题不只在元素数量，还在单池的读写集中度、批量操作以及故障恢复时的负载。
后来回看这套设计，我也思考过按 Score 分段：把一个全局有序池拆成多个有序区间，在使用方看来仍是统一排序，底层则避免所有内容集中在单个 ZSet。
这是一条后续设计方向。它需要进一步解决分段热点、跨段更新、取数顺序以及并发一致性；简单按分数切段，也不能保证每段的数据量一定均匀。
当时另一点体会来自存储容灾：主存储与备用存储即使提供相同的 ZSet 接口，也不意味着拥有相同的容量和性能边界。备用链路能维持业务不断流，与完整承接主池容量，是两种不同的保障。
调度正确性还需要看交接处
池内去重与送审幂等解决了内容身份问题，但并发和故障下的正确性还取决于交接过程。
例如两个调度实例同时选到一个候选，或者送审请求已经成功，但进程在移除候选、记录幂等键之前中断。仅仅使用 ZSet 和幂等键，并不能自动消除这些窗口。
评估这一类系统时，需要具体检查候选领取的并发控制、送审超时后的结果确认，以及出池与幂等记录之间的故障恢复方式。不能把“成功后出池”的正常流程直接等同于跨系统原子提交。
内容池的核心价值，是把审核资源分配变成一个可配置、可反馈的过程：用排序决定优先级，用缓冲吸收波动，用实际审核吞吐调整供给。存储结构支撑了这个过程，真正决定它是否有效的，仍然是风险价值与审核能力之间的匹配。