مرحبا جميعا
أنا أبني منصة أتمتة متعددة المستأجرين على أساس n8n وأحتاج إلى طريقة موثوقة لتتبع الاستخدام للفواتير والتقارير.
كل مستأجر ينتج:
تنفيذات سير العمل
رسائل WhatsApp
طلبات API
استدعاءات الذكاء الاصطناعي/LLM
وظائف معالجة الملفات
أود قياس الاستخدام لكل مستأجر ودعم أشياء مثل:
خطة مجانية → 1000 رسالة/شهر
خطة احترافية → 10000 رسالة/شهر
مؤسسة → حدود مخصصة
مخاوفي هي: تتبع دقيق للاستخدام عبر عمال متعددين
منع العد المزدوج أثناء إعادة المحاولات
فرض الحصص في الوقت الفعلي
التقارير التاريخية والفواتير
أنا أفكر في: أحداث الاستخدام المخزنة في PostgreSQL
عدادات Redis للحدود في الوقت الفعلي
خدمة فواتير منفصلة
تتبع الاستخدام المدفوع بالأحداث
وصف المشكلة/الخطأ/السؤال
للفرق التي تدير أنظمة n8n متعددة المستأجرين: كيف تتابعون وتفرضون استخدام المستأجرين؟
هل تحسبون الاستخدام في الوقت الفعلي أم تجمعونه لاحقاً؟
هل هناك أنماط تعمل بشكل جيد للفواتير والحصص والتقارير على نطاق واسع؟
ما هي رسالة الخطأ (إن وجدت)؟
يرجى مشاركة سير عملك
(حدد العقد على لوحتك القماشية واستخدم اختصارات لوحة المفاتيح CMD+C/CTRL+C و CMD+V/CTRL+V لنسخ ولصق سير العمل.)
مرحباً @Emmas نهج الإنتاج الشائع هو استخدام التتبع في الوقت الفعلي للحدود وسجلات قاعدة البيانات للفواتير والتقارير.
سير العمل → تسجيل حدث الاستخدام → تحديث العداد → متابعة المعالجة
تتبع الاستخدام لكل tenant_id، مثل:
الرسائل المرسلة
استدعاءات API
تنفيذات سير العمل
طلبات الذكاء الاصطناعي
لفرض الحصة يستخدم العديد من الفريق عدادات Redis للفحوصات السريعة: tenant_id → current_usage → plan_limit
إذا تجاوز المستأجر حده المسموح به، احجب أو اخنق الطلبات الجديدة.
للفواتير تأكد من تخزين أحداث الاستخدام في قاعدة بيانات وإنشاء التقارير أو الفواتير من تلك البيانات.
هذا يعطيك: سجل فواتير دقيق
التدقيق
التقارير الشهرية
يساعد في تجنب: عد تنفيذات سير العمل فقط
الاعتماد فقط على Redis لبيانات الفواتير
تجاهل المحاولات مجدداً (يمكن أن تسبب العد المزدوج)
الحدود المهمة هي مفتاح idempotency لكل حدث قابل للفواتير، وليس Redis مقابل Postgres.
أصدر حدث usage_event واحد فقط مع tenant_id و meter (whatsapp_message أو llm_call أو file_job) ومعرّف run/message المصدر والفترة والوحدات. ضع قيد فريد على مفتاح هذا الحدث، ثم حدّث عداد Redis فقط بعد نجاح الإدراج. إعادة محاولة تعيد تشغيل نفس المفتاح ولا تنشئ صفًا قابلًا للفواتير الثاني؛ تأتي الفواتير من جدول الأحداث أو التجميعات الشهرية، بينما Redis هو مجرد فحص سريع أولي.
أي meter يسبب أكبر خطر الآن: إرسالات WhatsApp أم استدعاءات LLM أم مهام الملفات؟
معمارية Redis + PostgreSQL الهجينة التي وصفها Niffzy هي المعمارية الصحيحة. بالنسبة لمشكلة العد المزدوج تحديداً، فإن أنظف نمط n8n هو استخدام معرّف التنفيذ كمفتاح الحد من التكرار (idempotency key): في بداية كل سير عمل، قم بتخزين $execution.id في Redis مع وقت انتهاء الصلاحية TTL (على سبيل المثال 24h) باستخدام SET execution:{id} 1 EX 86400 NX. إذا أرجعت عملية SET القيمة 0 (المفتاح موجود بالفعل)، تخطَّ زيادة الاستخدام - تم عد هذا التنفيذ بالفعل. هذا يتعامل مع إعادة المحاولات دون عد زائد ويعمل حتى عبر عمال n8n المتعددين لأن Redis مشتركة.