企业官网建设流程全解析

月底对账，老板发现三个会员的合同过期半个多月了，续费的钱一分没进来。问红娘，红娘说：我以为您那边盯着呢。两个人都以为对方在盯，结果是没人盯。

这不是态度问题，是婚恋系统没把节点接住。一个红娘手上同时跟着二三十个会员，每个人的服务周期、回访节点、材料补交时间都不一样，旺季会员量一翻倍，漏是必然的。人的记忆上限摆在那，靠"我脑子里有数"撑不住。

所以婚恋系统里真正值钱的模块之一，不是匹配算法，是把"什么时候该干什么"这件事从红娘脑子里搬出来的提醒引擎。听起来简单，我们做的时候踩的坑不少，这篇文章把节点表设计、扫描去重和订阅消息触达这几段拆开讲。

把节点从脑子里搬进一张表

婚恋系统的节点表设计，第一步是想清楚：提醒的不是"会员快到期"这一个事件，而是一串服务节点。婚介服务的实际流程里，至少有这几类节点值得钉住：合同到期前 30 天谈续费方案、服务中期做一次回访、材料齐了约见面、见面后 48 小时内收集反馈。

婚恋系统如果只做"到期提醒"一个字段，红娘很快会发现它只会催收钱，别的全靠她记，工具就用不起来。所以我们的节点表是规则驱动的，一条规则描述"什么事件发生前后、提前多少天、提醒谁"：

CREATETABLEservice_node(idBIGINTUNSIGNEDAUTO_INCREMENTPRIMARYKEY,member_idBIGINTUNSIGNEDNOTNULLCOMMENT'会员',node_typeVARCHAR(32)NOTNULLCOMMENT'renew/followup/material/feedback',trigger_dayDATENOTNULLCOMMENT'节点日期',offset_daysINTNOTNULLDEFAULT0COMMENT'提前提醒天数',owner_idBIGINTUNSIGNEDNOTNULLCOMMENT'负责红娘',statusTINYINTNOTNULLDEFAULT0COMMENT'0待办 1完成 2失效',created_atDATETIMENOTNULLDEFAULTCURRENT_TIMESTAMP,KEYidx_trigger(status,trigger_day,offset_days))ENGINE=InnoDBDEFAULTCHARSET=utf8mb4;

这里有个反直觉的设计：trigger_day存的是节点本身的日期，提醒日是查询时用trigger_day - offset_days算出来的，不单独存。原因是业务方经常改策略——这周把续费提醒从提前 30 天调成提前 45 天，如果提醒日落在数据里，就得批量回刷存量数据；放在查询时算，改配置只改一行。

节点从哪来？大部分不是人工录的。会员签约时按套餐规则批量生成，回访节点在上一次见面完成后自动排下一次，这样红娘只在异常情况下补录，表的完整性才有保证。人工补的节点越多，婚恋系统越退化成一本电子台账。

婚恋系统的扫描是条 SQL 的事，但重跑不能重发

每天早上七点跑一次扫描任务，把今天该提醒的节点捞出来推给对应红娘。SQL 本身很朴素：

SELECTid,member_id,node_type,owner_idFROM service_nodeWHEREstatus=0ANDtrigger_dayBETWEENCURDATE()+INTERVAL1DAYANDCURDATE()+INTERVAL1DAY+INTERVALoffset_days DAYLIMIT500;

真正的问题在执行侧。定时任务总会因为发布重启、机器故障漏跑一次，然后你补一个手动重跑入口——重跑的时候，昨天已经推过的提醒绝不能再推一遍。红娘一天收到两条"张姐会员下周到期"，第二次她就不看这个面板了，狼来了效应比漏提醒更伤工具的信用。

我们的做法是加一张发送流水表，用唯一索引兜底：

CREATETABLEnode_notify_log(idBIGINTUNSIGNEDAUTO_INCREMENTPRIMARYKEY,node_idBIGINTUNSIGNEDNOTNULL,notify_dateDATENOTNULL,channelVARCHAR(16)NOTNULLCOMMENT'wx/sms/inapp',sent_atDATETIMENOTNULLDEFAULTCURRENT_TIMESTAMP,UNIQUEKEYuk_node_date(node_id,notify_date,channel))ENGINE=InnoDBDEFAULTCHARSET=utf8mb4;

推送前先INSERT IGNORE这张表，插得进去才发，插不进去说明今天这个节点在这个渠道已经发过了。重跑、并发、多实例部署，全部被这一个唯一索引挡住。比在应用层加分布式锁简单得多，而且天然带了发送记录，排查"红娘说没收到"时直接查表。

订阅消息的一次性授权，是最容易翻车的地方

婚恋系统里，提醒怎么到红娘手上？站内信没人看，短信一条几分钱还容易被当垃圾拦截，最顺的路是微信小程序的订阅消息。但它有个新手必踩的坑：小程序订阅消息是一次性授权——用户点一次"允许"，你只能发一条，发完额度就没了。

婚恋系统里的提醒是天天发的，这意味着授权额度是持续消耗品。如果只在红娘第一次打开小程序时请求一次授权，第二周额度就耗光了，后面所有提醒都会静默失败，而且你这边看到的是"发送成功"，红娘那边什么都没收到。

我们在实际项目中观察到，示例数据：不做额度管理时，订阅消息的实际到达率在第二周后掉到两成以下；做了下面的机制后稳定在八成上下。做法是三件事：

1. 额度记账。每次发送前查额度，发一条扣一条，把微信侧的授权当成账户余额来管，低于阈值就在红娘下次打开小程序时补请求授权。
2. 选对请求时机。不要在启动页弹授权，红娘会条件反射点拒绝。在她刚完成一次"标记节点完成"的操作后弹，这个时刻她刚体会到提醒的价值，授权通过率明显更高（示例数据：约 3 倍于启动页）。
3. 多渠道降级。额度不足时降级到站内信加工作台红点，绝不让提醒因为单渠道失败而丢。渠道可以降，节点不能丢。

另外别忘了发送失败的重试要和上面那张流水表配合：重试只重发失败记录，且仍走唯一索引，避免重试风暴变成重复轰炸。

复盘：提醒引擎的价值在"不漏"，不在"智能"

这套东西没有任何高深技术：一张节点表、一条扫描 SQL、一张流水表、一个额度账本。但婚恋系统上线后（示例数据）婚介机构的续费节点遗漏率从每月 5 单左右降到基本归零，红娘的用法也很稳定——每天早上打开工作台看一遍今日待办，照着清单打电话。

回头看，最容易犯的错是把提醒做成"通知轰炸机"：什么节点都推、一天推五遍、渠道不管额度。工具的信用是靠"每次响都值得看"攒出来的。宁可少提醒，不能发噪音；宁可降级到红点，不能静默丢失。这两条原则比任何调度框架选型都重要。

下一篇打算聊聊节点完成后反馈怎么回流，让"见面 48 小时收集反馈"这类节点不是提醒完就结束，而是真能催出一笔回访记录。

文中方案来自我们在婚恋行业 SaaS（云中红线）的一线实践，欢迎交流。