应用重启后，数据库里明明已有新任务，WEPC候选VPS上的监听进程却没有再醒来；如果系统只靠一条PostgreSQL通知触发处理，换一台更大的机器也不会补回断线期间的提醒。部署预算首先需要覆盖持久任务记录、重新订阅后的补扫和处理能力。通知可以缩短等待，但任务是否存在、是否完成，需要另有可追溯依据。
把通知当作唤醒信号，任务账留在表里
PostgreSQL官方说明，NOTIFY会向当前数据库内已经执行LISTEN的会话发送通知，会话结束时监听注册自动清除。因此它适合提示“有变化，去检查”，不能把它当成向离线消费者保存待领取任务的持久消息服务。通知不是按消费者完成状态逐条确认的任务账；如果业务要求断线重连后逐项处理，就需要把待办记录保存在表或其他可靠存储中。
例如订单事务可以同时保存订单和待发送邮件记录，再发出通知提示后台检查。通知随事务提交才交付，事务回滚也不会留下已提交的这次通知。这样的组合让“有任务的事实”随业务一起提交；通知丢失时仍能靠扫描发现。邮件已发而完成标记未写入的故障，则要由业务幂等键或明确的重复发送政策处理，不能依赖通知协议消除。
验收成功应定义为持久记录最终进入已完成或明确失败状态，而不是监听日志出现过一条消息。记录至少应能解释创建时间、最近处理结果与后续责任。保存哪些字段由业务决定，但不要只在进程内放一个待处理数组：一旦实例重启，通知和内存队列可能同时消失，无法判断还有多少工作没有交付。
图中的提示物与堆叠记录是抽象示意，分别表示唤醒与持久待办。它们承担不同职责。可以把通知载荷限制成记录标识或一个需要检查的范围，大对象仍放在数据库；官方文档对默认配置载荷要求小于8000字节。通知对所有用户可见，也不适合把敏感正文直接塞进载荷。
重连顺序写错，会留下无人察觉的空窗
LISTEN在事务提交时生效。官方给出的启动规则是：先执行并提交监听注册，再在一个新事务中检查数据库当前状态，随后依赖通知发现后续变化。这样初始扫描与后续提醒在逻辑上有接续关系。最初几条通知可能对应扫描已见过的记录，因此处理过程仍要能接受重复发现。
如果先扫表，再慢慢建立监听连接，二者之间提交的新任务可能落入空窗。增加CPU只能缩短某次扫描耗时，不能证明这个空窗不存在。代码验收应把连接建立、监听提交、初始扫描完成和进入循环四个时间点记下来，并在这些边界并发提交任务，核对最终任务账是否闭合。
断线重连需要重走注册与补扫，而不是只重建套接字后原地等待。对于数据库连接池，要核对实际会话是否稳定承载监听；应用拿到的是逻辑连接，并不能自动证明底层会话一直保持订阅。本篇不把池模式兼容性作为扩容依据，而是要求交付方给出所用驱动、连接模式和重连后的实际订阅证据。
没有通知时也要定期检查
可以在正常监听之外安排周期补扫，形成对遗漏提醒的检测。假设业务要求新任务至迟两分钟被发现，把扫描间隔设为一分钟只是预算起点：还要把连接恢复、扫描执行、领取等待和处理时间放进期限。若扫描本身需要七十秒，一分钟定时器就不能保证一分钟发现，重复启动还可能增加数据库压力。
判断门槛可写成发现延迟加排队延迟加处理耗时，不超过业务可接受期限。需要用故障注入观测整个链路，而不是把几个平均值简单拼接。验收时主动断开监听、在空档提交任务、恢复连接并核对记录状态；再测试扫描失败和进程重启，确认告警指向真正负责补账的人。
把停机积压换算成恢复能力
假设每秒产生4条任务，监听和扫描同时停摆15分钟，则新增积压为3600条；恢复后持续产生量仍为每秒4条。若整套后台实测只能每秒完成10条，净消化能力为每秒6条，清完这段积压的理论时间是600秒，即10分钟。这里的任务率和处理率都是容量规划假设，不是WEPC实测，实际还需考虑失败重试与耗时不均匀。
这个算例说明，恢复后“处理率大于新增率”只证明积压有机会减少；是否能在剩余业务期限内清完，还要比较净处理能力与积压量。若完成率不高于新增率，增加补扫频率只会更快发现越来越多的未完任务，不能修复交付能力。采购更多工作节点之前，先确认瓶颈是否在外部邮件接口、串行限制或数据库争用上。
上图以连续轨道和分开的物件表示持久记录对提醒空档的承接，不代表真实队列或处理测试。把持久记录补齐之后，仍需限制每轮扫描规模，并观察索引访问、事务持续时间和完成更新的开销。一个能很快醒来的后台，如果每次都扫描整张历史表，运行时间会随业务年龄增长，后来补发的扩容账可能比最初实例费更大。
长事务会把通知故障推到提交端
NOTIFY在发出通知的事务提交后交付；监听会话处在事务中时，客户端也要等事务结束才收到。相同事务对同一频道发送相同载荷时，还可能合并为一条通知。所以一条通知不能直接解释成一条业务任务，事务持续时间也会影响可见的提醒延迟。
官方文档指出，长期保持事务的监听者可能阻止通知队列清理；队列满时，调用NOTIFY的事务会在提交时失败。可以观察pg_notification_queue_usage返回的占用比例，并根据实际增长率和业务期限设置告警；不能照搬别人的固定百分比。当告警出现时，应定位阻碍清理的会话，而不是只把服务器磁盘加大。
这会改变部署责任：监听进程应避免在等待通知时长期占用事务，提交失败也必须进入应用错误处理。若业务把通知与订单放在同一事务，通知队列问题可能影响订单提交；需要评估这种耦合是否可以接受。分开发送又会引入业务提交成功但提醒未发出的空档，持久待办和补扫正是处理这个边界的依据。
WEPC候选订单该买什么，暂时还缺什么
本轮渠道通实时返回了WEPC对应推广入口，但官网访问返回403，未取得可核验的当前套餐、价格、CPU政策或退款条款。本篇仅按自建PostgreSQL任务服务讨论采购方法，不把历史采集信息写成当前优惠，也不承诺WEPC提供托管数据库或代维护。两张配图均为生成示意，不是官网或测试截图。
适合进入候选测试的场景，是团队能维护数据库与任务账、业务能处理重复发现，并且允许在约定时间内恢复积压。若要求离线消费者获得逐条确认、长期重放或严格的跨系统交付，应先比较专门消息服务与自建方案的运维成本。不要只把另一台VPS的月费当成完整解决方案，备份恢复、监控和故障值班仍需计价。
下单前要求商家明确自建数据库和后台常驻进程是否允许、持续CPU和磁盘写入如何限制、断电或宿主机故障由谁恢复实例，以及备份是否包含、数据怎样导出、退款从什么时间开始计算。通过WEPC订单核对入口（推广链接）查看实际可售配置，本站可能获得推广收益；官网未核实部分应在付款前书面确认。
最终交付时交一份故障任务账：断线期间新增多少条、恢复后何时全部进入明确状态、重复发现有没有产生不可接受的副作用。只要这份记录仍有无法解释的缺口，就继续修正补扫与处理流程，暂缓以加机器作为验收结论。
用户评论