ما هو نظام LISTEN و NOTIFY؟

Question

Accepted Answer

**`LISTEN`** و **`NOTIFY`** يوفران نظام **نشر/اشتراك** مدمج في PostgreSQL — حيث يمكن لجلسة واحدة إرسال إشعار على قناة معينة، والجلسات الأخرى المستمعة على تلك القناة تستقبله فوراً. إنها طريقة خفيفة الوزن لدفع أحداث فورية من قاعدة البيانات بدون الحاجة للاستقصاء.

## آلية العمل الأساسية

```sql
-- a session SUBSCRIBES to a channel
LISTEN order_created;

-- another session/transaction PUBLISHES a notification (with an optional payload)
NOTIFY order_created, 'order id 123';
-- → all sessions listening on 'order_created' receive the message immediately
```

LISTEN يشترك في قناة؛ NOTIFY ينشر عليها (مع حمولة نصية اختيارية). المستمعون يتلقون الإشعارات بشكل غير متزامن — لا حاجة للاستقصاء.

## تشغيل NOTIFY تلقائياً (نمط شائع)

```sql
-- a trigger that notifies whenever a row is inserted
CREATE FUNCTION notify_new_order() RETURNS trigger AS $$
BEGIN
  PERFORM pg_notify('order_created', NEW.id::text);   -- notify with the new id
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER order_notify AFTER INSERT ON orders
  FOR EACH ROW EXECUTE FUNCTION notify_new_order();
-- now inserting an order automatically pushes a notification to listeners
```

دمج NOTIFY مع **trigger** يسمح لقاعدة البيانات بدفع الأحداث تلقائياً عند تغيير البيانات (طلب جديد، تحديث حالة) — خوادم التطبيقات المستمعة على القناة تتفاعل في الوقت الفعلي.

## كيف تستخدمه التطبيقات

```text
Application code (Node, Python, etc.) opens a connection and LISTENs on a channel.
When a NOTIFY fires (e.g. from a trigger on data change), the app receives the event
and reacts — pushing to websockets, invalidating a cache, triggering a job, etc.
→ Real-time reactions to database changes WITHOUT polling the database.
```

## القيود التي يجب معرفتها

```text
✗ Notifications are NOT persisted — if no one is listening, the message is LOST
  (no durability/queue guarantees like a real message broker)
✗ Payload is small (limited size); delivered only after the transaction COMMITS
→ Good for lightweight real-time signaling; for durable/reliable messaging use a
  proper broker (RabbitMQ, Kafka) or a queue table.
```

## لماذا يهم

`LISTEN`/`NOTIFY` ميزة مفيدة وأقل شهرة نسبياً في PostgreSQL توفر **نظام نشر/اشتراك مدمج**، قيمة لإضافة **التفاعلية الفورية** للتطبيقات بدون استقصاء.

القيمة الأساسية هي تمكين قاعدة البيانات من **دفع الأحداث** للجلسات المستمعة فوراً عند حدوث شيء ما (طلب جديد، تغيير حالة) — عادة مدمج مع **triggers** بحيث تخطر تغييرات البيانات المستمعين تلقائياً، والتي تتفاعل معها خوادم التطبيقات (الدفع إلى websockets، إلغاء ذاكرة التخزين المؤقت، تشغيل عمل خلفي).

هذا مفيد لأنه يوفر سلوك حدثي فوري بدون عدم الكفاءة في **الاستقصاء** المتكرر لقاعدة البيانات للتحقق من التغييرات (نمط شائع ومهدر يستبدل LISTEN/NOTIFY به بأناقة).

فهم الآلية (LISTEN للاشتراك، NOTIFY للنشر، مع triggers للإشعار التلقائي عند تغيير البيانات) وكيفية استخدام التطبيقات له (الاستماع للأحداث لتشغيل التفاعلات الفورية) مفيد لبناء تطبيقات متجاوبة وموجهة بالأحداث باستخدام PostgreSQL فقط.

بنفس الأهمية معرفة **القيود**: الإشعارات **لا تُحفظ** (تُفقد إذا لم يكن هناك مستمعون — لا ضمانات متانة)، لها حمولات صغيرة، وتُطلق فقط بعد الالتزام — لذا فهي مناسبة للإشارات الفورية الخفيفة، *وليس* بديلاً لمجمع رسائل متين (RabbitMQ, Kafka) عندما تكون الموثوقية والثبات مهمة.

بما أن التفاعلية الفورية احتياج شائع و LISTEN/NOTIFY يوفر طريقة مدمجة خالية من الاستقصاء لتحقيقها في الحالات الخفيفة، فإن فهمه — آلية النشر/الاشتراك، نمط trigger، والأهم قيوده (متى يكفي مقابل متى نحتاج وسيط حقيقي) — معرفة PostgreSQL قيمة وعملياً مناسبة لبناء تطبيقات موجهة بالأحداث، ميزة مدمجة مفيدة غالباً ما يتم تجاهلها.