Node.js API用户请求触发延迟发邮：如何检测并终止旧计时器？

Great question! Let’s walk through both approaches you’re considering—using runtime variables and database storage—to help you decide which fits your use case best.

Runtime Variables: Feasible but with Limitations #

Yes, using runtime variables to track user timer states is absolutely feasible, especially for simpler, single-instance setups. Here’s how you could implement it with a Map to store active timers per user:

// Store active timers keyed by user ID
const userTimers = new Map();

// Handle incoming API requests
function handleUserRequest(userId) {
  // Check if the user already has an active timer
  if (userTimers.has(userId)) {
    // Clear the existing timer to reset the countdown
    clearTimeout(userTimers.get(userId));
    console.log(`Resetting email timer for user ${userId}`);
  }

  // Set a new 15-minute timer
  const newTimerId = setTimeout(() => {
    sendEmail(userId);
    // Clean up the timer record after sending the email
    userTimers.delete(userId);
  }, 15 * 60 * 1000);

  // Update the map with the new timer ID
  userTimers.set(userId, newTimerId);
}

// Mock email function
function sendEmail(userId) {
  console.log(`Sending reminder email to user ${userId}`);
}

Pros of this approach: #

• Blazing fast: No database calls involved—all operations happen in memory.
• Dead simple to implement: Minimal code needed to track and reset timers.

Cons to watch out for: #

• No persistence: If your Node.js server restarts (e.g., due to deployment, crash, or scaling), all active timer states are lost. Users might not get their emails, or timers might not reset correctly.
• Multi-instance issues: If you’re running multiple server instances (like in a load-balanced setup), each instance has its own separate userTimers map. A user’s request hitting a different instance won’t reset the timer stored on another instance, leading to duplicate emails or missed resets.
• Memory overhead: As more users trigger timers, the map will grow. While this is rarely an issue for small to medium traffic, you’ll want to ensure expired/inactive timers are cleaned up properly.

Database Storage: More Reliable for Production #

If you need your timer state to persist across server restarts or work with multiple instances, storing state in a database is the way to go. Here’s a high-level implementation using a relational database (we’ll use Sequelize with SQLite for example):

const { Sequelize, Model, DataTypes } = require('sequelize');
const schedule = require('node-schedule');

// Initialize database connection
const sequelize = new Sequelize('sqlite::memory:');

// Define a model to track user timers
class UserTimer extends Model {}
UserTimer.init({
  userId: {
    type: DataTypes.STRING,
    primaryKey: true
  },
  expireTime: {
    type: DataTypes.DATE,
    allowNull: false
  },
  isActive: {
    type: DataTypes.BOOLEAN,
    defaultValue: true
  }
}, { sequelize, modelName: 'userTimer' });

// Sync database schema
(async () => {
  await sequelize.sync();
})();

// Handle API requests
async function handleUserRequest(userId) {
  const now = new Date();
  const newExpireTime = new Date(now.getTime() + 15 * 60 * 1000);

  let timerRecord = await UserTimer.findByPk(userId);

  if (timerRecord && timerRecord.isActive) {
    // Update the existing timer's expiration time
    await timerRecord.update({ expireTime: newExpireTime });
    console.log(`Resetting email timer for user ${userId}`);
  } else {
    // Create a new timer record
    await UserTimer.create({ userId, expireTime: newExpireTime });
    console.log(`Created new email timer for user ${userId}`);
  }
}

// Scheduled job to check for expired timers every minute
schedule.scheduleJob('* * * * *', async () => {
  const now = new Date();
  const expiredTimers = await UserTimer.findAll({
    where: {
      expireTime: { [Sequelize.Op.lte]: now },
      isActive: true
    }
  });

  for (const timer of expiredTimers) {
    await sendEmail(timer.userId);
    // Mark the timer as inactive after sending the email
    await timer.update({ isActive: false });
  }
});

// Mock email function
async function sendEmail(userId) {
  console.log(`Sending reminder email to user ${userId}`);
}

Pros of this approach: #

• Persistent state: Timer data survives server restarts and scaling events.
• Multi-instance friendly: All instances share the same database, so timer resets work regardless of which instance handles the user’s request.
• Scalable: You can add more fields (like request count, last request time) to track additional user behavior if needed.

Cons: #

• Added complexity: You’ll need to set up and maintain a database, plus a scheduled job to check for expired timers.
• Slight performance overhead: Database reads/writes are slower than in-memory operations, but this is negligible for most API traffic.

Which Should You Choose? #

• Go with runtime variables if you’re running a single instance, don’t need state persistence, or are building a prototype/test environment.
• Opt for database storage if you’re deploying to production, need multi-instance support, or require that timer states are never lost.

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