我的Long Polling实现是否正确？Web系统通知场景技术验证求助

Hey there! Totally get where you’re coming from—when time’s tight, long polling is a smart, low-fuss alternative to WebSocket-based solutions like Socket.io or Ratchet. Let’s break down your concerns one by one to help you validate your implementation and avoid server overload.

A solid long polling setup should hit these core markers:

• Server-side request suspension: Your server doesn’t immediately return an empty response. It holds the request open until either a new notification is available, or a predefined timeout is reached.
• Automatic client reconnection: After receiving a response (whether it has new data or timed out), the client immediately fires off a new long polling request to maintain the "connection."
• Duplicate request prevention: The client doesn’t spawn multiple overlapping requests. Use a simple flag (like isPolling) to ensure only one request is in flight at a time.
• Error handling: There’s logic to catch network failures, server errors, or timeouts, and gracefully restart the polling cycle instead of breaking entirely.

This is the big one—here’s how to keep your server from getting swamped:

• Set reasonable timeouts: Aim for 30-60 seconds on the server (slightly shorter than the client’s timeout to avoid race conditions). Too short, and you’ll get constant requests; too long, and you’ll tie up server connections unnecessarily.
• Client-side request deduplication: As mentioned above, never let the client send a new request until the previous one has completed (success or failure).
• Server-side concurrency limits: Restrict how many active long polling requests a single user can have (1 is ideal). This stops misbehaving clients or edge cases from hogging connections.
• Ditch database polling: Don’t have your server repeatedly query the database for new notifications. Instead, use an event-driven system (like Redis Pub/Sub or an in-memory queue) to trigger responses when a new notification is created. This cuts down on unnecessary database load and makes your server more efficient.
• Enable HTTP Keep-Alive: This reuses existing TCP connections for subsequent requests, reducing the overhead of establishing new connections constantly.

Most tutorials show stripped-down examples—here’s where they often differ from production-ready setups:

• Missing error handling: Examples skip edge cases like network drops, server timeouts, or duplicate requests to keep code simple.
• No event-driven triggers: Many basic implementations use naive database polling instead of message queues, which is fine for demos but not scalable.
• Simplified retry logic: Some examples add a small delay after receiving new data (instead of retrying immediately) to reduce request frequency when notifications are frequent.
• Cursor-based updates: Good production implementations let the client pass a lastNotificationId parameter, so the server only returns notifications newer than that ID. This cuts down on data transfer and redundant processing.

Client-side (JavaScript) #

let isPolling = false;
const SERVER_TIMEOUT = 25000; // 25s (shorter than client timeout)
const RETRY_DELAY = 1000; // 1s delay after errors/timeouts

function startLongPoll(lastNotificationId = 0) {
  if (isPolling) return;
  isPolling = true;

  fetch(`/api/notifications?last_id=${lastNotificationId}`, {
    signal: AbortSignal.timeout(SERVER_TIMEOUT + 5000) // Client timeout 30s
  })
  .then(res => res.json())
  .then(data => {
    if (data.notifications.length) {
      // Update your UI with new notifications
      renderNotifications(data.notifications);
      // Use the latest notification ID for next poll
      lastNotificationId = data.notifications.at(-1).id;
    }
  })
  .catch(err => {
    console.warn("Long poll failed:", err.message);
  })
  .finally(() => {
    isPolling = false;
    // Restart the poll after a short delay
    setTimeout(() => startLongPoll(lastNotificationId), RETRY_DELAY);
  });
}

// Initialize the poll when the page loads
startLongPoll();

Server-side (PHP, simplified) #

<?php
session_start();
$userId = $_SESSION['user_id'];
$lastId = isset($_GET['last_id']) ? (int)$_GET['last_id'] : 0;

// Set headers for long polling
header("Content-Type: application/json");
header("Cache-Control: no-cache");
header("Connection: keep-alive");

$timeout = time() + 25; // 25s server timeout

// Use Redis Pub/Sub instead of database polling in production!
while (time() < $timeout) {
  $newNotifications = getNewNotifications($userId, $lastId);
  
  if (!empty($newNotifications)) {
    echo json_encode(["notifications" => $newNotifications]);
    exit;
  }
  
  // Sleep to reduce CPU usage
  sleep(1);
}

// Timeout: return empty response
echo json_encode(["notifications" => []]);
exit;

function getNewNotifications($userId, $lastId) {
  // Query database for notifications newer than $lastId
  // Replace with Redis Pub/Sub listen in production
  return [];
}
?>

• Monitor metrics: Track active connections, request frequency, and database query rates to catch bottlenecks early.
• Handle background tabs: Browsers throttle background tabs—use Service Workers if you need notifications to keep working when the tab is inactive.
• Add logging: Tag long polling requests with user IDs and request IDs to debug issues quickly.

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