medical-mall/server/消息推送文档/PUSH_WORKFLOW.md

推送工作流说明（Push Queue + 后端消费者 + 云函数 invoke）

概述

• 目的是将数据库中产生的待推送消息可靠地传递到云函数进行实际推送（云函数使用 uniPush）。
• 思路：业务写库 → 写入 push_queue（持久化队列）→ push-server 或消费者监听队列 → 构造 event 并调用云函数 invoke URL → 云函数从 event 中读取参数并发送推送。

优点

• 可靠：持久化队列可重试、审计与人工干预。
• 解耦：业务写库与实际推送解耦，降低失败传播风险。
• 可扩展：支持多 worker 并发消费与并发控制。

组件与职责

• push_queue（数据库表）：保存待推送任务与状态；保证持久化与可重试。
• push-server：消费者或 HTTP 接口，负责从队列读取任务、锁定、调用云函数，并更新任务状态。
• 云函数（已上传并发布一次）：例如 uniCloud 云函数 testUnipush2，接收 event 并调用 uniPush.sendMessage 完成推送。

Schema 示例（Postgres / Supabase）

CREATE TABLE push_queue (
  id serial PRIMARY KEY,
  push_clientid varchar NOT NULL,
  title text,
  content text,
  payload jsonb DEFAULT '{}'::jsonb,
  status varchar(16) DEFAULT 'pending', -- pending, processing, success, failed
  retry_count int DEFAULT 0,
  last_error text,
  created_at timestamptz DEFAULT now(),
  updated_at timestamptz DEFAULT now()
);
CREATE INDEX ON push_queue (status);

写入队列（业务侧）

• 在业务事务中，除了写业务表外，同时插入一条 push_queue 记录（保证一致性）。
• 如果业务不想同步写队列，也可由异步任务或触发器生成。

消费者（push-server）行为说明

• 1. 轮询或订阅：通过 Supabase Realtime、Postgres LISTEN/NOTIFY、或定时轮询读取 status='pending' 的记录。
• 2. 锁定任务：在读取后将该记录设为 processing（或用数据库事务/乐观锁），防止重复消费。
• 3. 构造 event： { token: <PUSH_TOKEN>, push_clientid: <push_clientid>, title: