基于Express+TypeORM(PostgreSQL)的订单转Gig触发策略选型咨询

需求回顾 #

当Order处于ready状态，且viable_pickup_time（无时区UTC时间戳）落在当前UTC时间的1小时范围内时，自动将Order数据转换为Gig实体。

可选方案分析 #

1. Node-cron定时任务方案 #

• 实现思路：用node-cron配置定时任务（比如每分钟/每5分钟执行一次），每次触发时通过TypeORM查询所有符合条件的未处理Order：status = 'ready'且viable_pickup_time BETWEEN NOW() AND NOW() + INTERVAL '1 hour'，同时processed = false。对查询到的订单创建对应Gig记录，再标记Order的processed为true。
• 优缺点：
  • 优点：实现简单，代码全在应用层，调试维护门槛低，适合小数据量场景。
  • 缺点：存在延迟（取决于定时频率，比如5分钟一次的话最长延迟5分钟）；数据量大时，全表扫描式查询会占用数据库资源。
• 极简代码示例：

  const cron = require('node-cron');
  const { getRepository } = require('typeorm');
  const { Order, Gig } = require('./entities');
  
  cron.schedule('* * * * *', async () => {
    const orderRepo = getRepository(Order);
    const gigRepo = getRepository(Gig);
    
    const eligibleOrders = await orderRepo.find({
      where: {
        status: 'ready',
        processed: false,
        viable_pickup_time: Between(new Date(), new Date(Date.now() + 3600000))
      }
    });
  
    for (const order of eligibleOrders) {
      const gig = new Gig();
      gig.gig_price = order.total_price;
      await gigRepo.save(gig);
      
      order.processed = true;
      await orderRepo.save(order);
    }
  });
  

2. PostgreSQL触发器+函数方案 #

• 实现思路：在Order表上创建AFTER UPDATE触发器，当Order的status被更新为ready时，触发PL/pgSQL函数，检查viable_pickup_time是否在当前UTC时间的1小时范围内。符合条件则直接在数据库层插入Gig记录，同时标记Order为已处理。另外补充一个低频定时任务（比如每小时一次），处理那些status已是ready、但viable_pickup_time刚进入1小时范围的订单（这类情况触发器无法捕获）。
• 优缺点：
  • 优点：实时性强（状态变更时立即处理），数据库层面执行性能远高于应用层定时查询，适合大数据量场景。
  • 缺点：逻辑写在数据库层，需要团队熟悉PL/pgSQL；迁移数据库时要同步触发器和函数，维护成本略高。
• 极简SQL示例：

  -- 创建处理函数
  CREATE OR REPLACE FUNCTION create_gig_from_order()
  RETURNS TRIGGER AS $$
  BEGIN
    IF NEW.status = 'ready' AND NEW.viable_pickup_time BETWEEN NOW() AND NOW() + INTERVAL '1 hour' AND NEW.processed = false THEN
      INSERT INTO gig (gig_price) VALUES (NEW.total_price);
      NEW.processed = true;
    END IF;
    RETURN NEW;
  END;
  $$ LANGUAGE plpgsql;
  
  -- 创建触发器
  CREATE TRIGGER order_ready_trigger
  AFTER UPDATE OF status ON "order"
  FOR EACH ROW
  EXECUTE FUNCTION create_gig_from_order();
  

3. TypeORM订阅者+定时任务混合方案 #

• 实现思路：用TypeORM的订阅者监听Order实体的update事件，当Order被更新时，在应用层检查是否符合status = 'ready'且时间在1小时范围内的条件，符合则创建Gig。同时单独配置定时任务，处理那些status已为ready、但时间刚进入1小时范围的订单（这类事件无法通过实体更新触发订阅）。
• 优缺点：
  • 优点：业务逻辑全在应用层，和现有代码栈统一，不需要额外学习PL/pgSQL；兼顾了状态变更的实时性和时间到期的覆盖。
  • 缺点：需要维护两个逻辑模块（订阅者+定时任务），复杂度略高于单一方案。
• 极简订阅者代码示例：

  import { EntitySubscriberInterface, EventSubscriber, UpdateEvent } from 'typeorm';
  import { Order } from './entities/Order';
  import { Gig } from './entities/Gig';
  
  @EventSubscriber()
  export class OrderSubscriber implements EntitySubscriberInterface<Order> {
    listenTo() {
      return Order;
    }
  
    async afterUpdate(event: UpdateEvent<Order>) {
      const order = event.entity;
      if (!order || order.status !== 'ready' || order.processed) return;
  
      const now = new Date();
      const oneHourLater = new Date(now.getTime() + 3600000);
      if (order.viable_pickup_time >= now && order.viable_pickup_time <= oneHourLater) {
        const gig = new Gig();
        gig.gig_price = order.total_price;
        await event.manager.save(gig);
        
        order.processed = true;
        await event.manager.save(order);
      }
    }
  }
  

最优方案选择 #

• 如果业务对实时性要求高、数据量较大，优先选PostgreSQL触发器+低频定时补漏方案，性能和实时性最优。
• 如果团队不熟悉PL/pgSQL，更倾向于在应用层统一维护逻辑，选TypeORM订阅者+定时任务混合方案，兼顾开发效率和功能覆盖。
• 小数据量、对延迟容忍度高的场景，直接用node-cron定时任务即可，实现最快。

通用注意事项 #

• 必须给Order实体添加processed布尔字段，标记已处理的订单，避免重复创建Gig。
• 定时任务的频率根据业务容忍的延迟调整，比如允许1分钟延迟就每分钟执行一次。
• 涉及数据库写入的操作要做好事务处理，避免数据不一致。

内容的提问来源于stack exchange，提问作者xoro_anti