基于Laravel Elasticsearch的匹配记录定时通知方案咨询

Got it, let's walk through a practical, production-ready implementation plan for this feature—here's how to tackle each part step by step:

1. Data Model Adjustments #

First, you'll need to extend your existing schema to track check times and notification states:

• Update your saved search conditions table: Add a last_check_timestamp (datetime) column to store when the cronjob last checked for new matches for this search. Initialize it to the search creation time for existing entries.
• Create a search_notifications table: This will track unread counts and states per user-search pair. Columns should include:
  • user_id (foreign key to users)
  • search_id (foreign key to saved searches)
  • unread_count (integer, default 0)
  • last_notified_at (datetime)
  • is_read (boolean, default false)

2. Cronjob Core Logic #

The cronjob will handle scanning for new matches and updating notifications. Here's the step-by-step flow:

• Schedule the job: Use a cron expression that fits your business needs (e.g., */5 * * * * for every 5 minutes). Run a backend script/worker (Python, Node.js, etc.—whatever your stack uses).
• Fetch active saved searches: Filter out deleted searches and searches belonging to inactive users to avoid unnecessary processing.
• Query new matches for each search: For each search, fetch records where created_at > last_check_timestamp OR updated_at > last_check_timestamp (adjust based on your record schema).
• Update notifications:
  • If new matches exist:
    • Check if a search_notifications entry already exists for the user-search pair. If yes, increment unread_count by the number of new matches. If no, create a new entry with unread_count set to the match count.
    • Update the search's last_check_timestamp to the current datetime to avoid reprocessing the same records.
• Batch operations: Use bulk SQL queries (e.g., UPDATE ... WHERE IN (...) or ORM bulk methods) wherever possible to minimize database round-trips—this is critical for performance if you have thousands of saved searches.

3. Frontend Notification Flow #

Make the notifications visible and interactive for users:

• Fetch unread count on load/interval: The frontend should either:
  • Poll a backend endpoint every 60-120 seconds to get the total unread notification count for the current user (sum of unread_count where is_read = false).
  • Use WebSockets for real-time updates (if your stack supports it) to push count changes immediately when the cronjob runs.
• Render the notification icon: Display a badge with the total unread count next to the icon. If count is 0, hide the badge or show an empty state.
• Handle icon click: When the user clicks the icon, fetch the full list of unread notifications:
  • For each notification entry, retrieve the actual new match records (you can either pre-cache these in the search_notifications table, or run the search query again filtered to the last_check_timestamp range for accuracy).
  • Show the list grouped by saved search (e.g., "5 new matches for your 'Active Projects' search").
• Mark as read: When the user views the list, send a request to the backend to set is_read = true and reset unread_count = 0 for the relevant search_notifications entries.

4. Performance & Edge Case Optimizations #

• Indexing: Add database indexes on:
  • Record table: created_at, updated_at (to speed up filtering new records)
  • Saved searches table: last_check_timestamp, user_id (to speed up fetching active searches)
  • search_notifications table: user_id, is_read (to speed up fetching unread counts)
• Asynchronous processing: If you have a high volume of saved searches, don't process all of them in the cronjob directly. Instead, push each search to a message queue (e.g., Redis Queue, RabbitMQ) and have worker processes handle the match queries in parallel.
• Timezone consistency: Ensure all datetime fields use the same timezone (UTC is recommended) to avoid mismatches between the cronjob's check time and record timestamps.
• Avoid duplicate notifications: If a single record matches multiple saved searches for the same user, make sure each search's notification is updated independently—don't merge counts across searches unless your UX requires it.

5. Edge Cases to Handle #

• User deletes a saved search: Ensure the cronjob skips deleted searches, and clean up any associated search_notifications entries.
• Record is updated multiple times: The cronjob should count it once per check interval (since updated_at will be after last_check_timestamp), not multiple times.
• Cronjob fails mid-run: Add error logging and idempotency checks (e.g., only update last_check_timestamp after successfully processing the search) so that failed runs don't leave partial data.

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