تطبيق الدردشة ASP.NET باستخدام قاعدة البيانات لقائمة انتظار الرسائل

Question

لقد قمت بتطوير تطبيق ويب للدردشة يستخدم قاعدة بيانات SQLServer لتبادل الرسائل.

جميع العملاء استطلاع كل 8 ثوان للتحقق من رسائل جديدة.

من الواضح أن هذا النهج يستهلك العديد من الموارد، وكنت أتساءل عما إذا كان هناك طريقة "أرخص" للقيام بذلك.

أستخدم نفس النهج ل "وجود": التحقق من هو على.

Answer 1

لشيء مثل تطبيق الدردشة في الوقت الحقيقي، أوصي بذاكرة التخزين المؤقت الموزعة مع دعم SQL. يحدث أن أحب Memcached مع مزود Enyim .NET، لذلك سأفعل شيئا مثل ما يلي:

1. المشاركات المستخدم
2. النظام يكتب رسالة إلى قاعدة البيانات
3. النظام يكتب رسالة إلى ذاكرة التخزين المؤقت
4. جميع المستخدمين استطلاع ذاكرة التخزين المؤقت بشكل دوري للرسائل الجديدة

يتيح لك دعم قاعدة البيانات تحميل ذاكرة التخزين المؤقت في الحدث في الحدث يتم مسح ذاكرة التخزين المؤقت أو إعادة تشغيل التطبيق، ولكن البتات الوظيفية تعتمد على ذاكرة التخزين المؤقت في الذاكرة، بدلا من الاقتراع قاعدة البيانات.

Answer 2

بدون استخدام المستودع الإضافي / امتداد مثل Flash أو Java Applet، يكون المتصفح أساسا أداة اتصال طريقة واحدة. يجب أن يبدأ الطلب من قبل المتصفح لجلب البيانات. لا يمكنك "دفع" البيانات إلى المتصفح.

العديد من تطبيقات الويب باستخدام طريقة الاقتراع AJAX لمحاكاة خادم "دفع". الحيلة هي موازنة حجم التردد / البيانات مع عرض النطاق الترددي وموارد الخادم.

أنا فقط فعلت ملاحظة بسيطة ل Gmail. يقوم بإجراء اقتراع httppost كل 5 ثوان. إذا لم يكن هناك تغيير "حالة"، فإن حجم بيانات الاستجابة ليس سوى عدد قليل من البايتات (لا يشمل رؤوس HTTP). بالطبع لدى Google موارد خادم ضخمة وعرض النطاق الترددي، لهذا السبب أذكر: العثور على توازن جيد.

هذا هو "تحسين تجربة المستخدم VS Server Resource". قد تحتاج إلى الخروج مع طريقة إبداعية لاستراتيجية الاقتراع، بدلا من الاقتراع المسامي كل X ثانية.

على سبيل المثال إذا لم يكن هناك نشاط من الحزب أ، استطلاع كل 3 ثوان. في حين أن الطرف A هو الكتابة، استطلاع كل 5 ثوان. هذا مجرد industraton، يمكنك اللعب مع الأرقام، أو الخروج مع واحد أكثر كفاءة.

أخيرا، تبادل البيانات. التحدي هو إيجاد طريقة لتمرير أحجام البيانات الدنيا لنقل نفس المعلومات.

2 سنتات :)

Answer 3

إذا كنت تستخدم SQL Server 2005، فيمكنك إلقاء نظرة على خدمات الإعلام. منح هذا من شأنه أن يحفل لك في SQL 2005 حيث تمت إزالة خدمات الإعلام في SQL 2008، وقد تم تصميمه للسماح ل SQL Server بإخطار تطبيقات العميل بالتغييرات في قاعدة البيانات.

إذا كنت تريد شيئا أكثر قابلية للتوسعة قليلا، فيمكنك وضع إشارات بضعة بت تسجيلات المستخدمين. عندما تأتي رسالة للمستخدم في تغيير القليل للرسائل الجديدة إلى TRUE. عندما تقرأ الرسائل تغييرها إلى 0. نفس الشيء لأنه عند تسجيل الدخول وإيقاف تشغيله. بهذه الطريقة التي تقرأ فيها حقل صغير جدا لديه فرصة جيدة لعنة بالفعل في ذاكرة التخزين المؤقت.

هل سير العمل جاهزا قليلا. إذا كانت 1، فانتقل إلى رسائل جدول الرسالة. إذا كان 0 لا تفعل شيئا.

Answer 4

في ASP.NET 4.0 يمكنك استخدم نمط المراقب مع كائنات JavaScript والصفوفات أي: AJAX JSON يدعو بجائق و PageMethods.

سوف تضطر دائما إلى الضغط على قاعدة البيانات للقيام بتحليل حول ما إذا كانت هناك أي بيانات للعودة أم لا. ستكون الخدعة في جعل تلك المكالمات صغيرة وعدم الإرجاع عند الحاجة.

Answer 5

هناك نوعان من الحلول ذات الصلة المدمجة إلى SQL Server 2005 وما زالت متوفرة في SQL Server 2008:

1) وسيط خدمة, ، والتي تسمح للمشتركين بنشر القراءة في قوائم الانتظار (أمر التلقائي مع الانتظار ..). في حالتك، كنت ترغب في إرسال رسالتك عبر قاعدة البيانات باستخدام خدمات وسيط الخدمة التي تدمج قوائم الانتظار هذه، والتي يمكن بعد ذلك التقاطها عملاء الانتظار. لا يوجد اقتراع، لا يتم تنشيط عملاء الانتظار عند استلام رسالة.

2) إخطارات الاستعلام, ، والتي تسمح للمشترك بتحديد استعلام، وإخطارات التلقي عند تغيير البيانات التي ستنتج عن تنفيذ هذا الاستعلام. بناء على وسيط الخدمة، الإخطارات الاستعلام هي أسهل إلى حد ما، ولكن قد تكون أيضا أقل كفاءة إلى حد ما. (ليس هذا الإخطارات الاستعلام وأشقاءها، يتم تخطيط إشعارات الأحداث بشكل متكرر لخدمات الإعلام (NS)، مما يؤدي إلى الاهتمام لأنه تم الانتهاء من NS في عام 2008، ومع ذلك، لا تزال إعلامات الاستعلام والحدث متاحة بالكامل وحتى محسن في SQL Server 2008).