أعد محاولة التوجيه لخدمات Azure

مقالة
10/10/2023

تتضمن معظم خدمات Azure وSDKs للعميل آلية إعادة المحاولة. ومع ذلك، تختلف هذه لأن لكل خدمة خصائص ومتطلبات مختلفة، وبالتالي يتم ضبط كل آلية إعادة محاولة لخدمة معينة. يلخص هذا الدليل ميزات آلية إعادة المحاولة لمعظم خدمات Azure، ويتضمن معلومات لمساعدتك في استخدام آلية إعادة المحاولة لتلك الخدمة أو تكييفها أو توسيعها.

للحصول على إرشادات عامة بشأن معالجة الأخطاء العابرة، وإعادة محاولة الاتصالات والعمليات مقابل الخدمات والموارد، راجع إرشادات إعادة المحاولة.

يلخص الجدول التالي ميزات إعادة المحاولة لخدمات Azure الموضحة في هذا الدليل.

الخدمة	قدرات إعادة المحاولة	تكوين النهج	النطاق	ميزات بيانات تتبع الاستخدام
معرِّف Microsoft Entra	أصلي في مكتبة MSAL	جزء لا يتجزأ من مكتبة MSAL	‏‏داخلي	بلا
Azure Cosmos DB	أصلي في الخدمة	غير قابل للتكوين	عمومي	TraceSource
Data Lake Store	أصلي في العميل	غير قابل للتكوين	العمليات الفردية	بلا
مراكز الأحداث	أصلي في العميل	Programmatic	العميل	بلا
مركز IoT	أصلي في العميل SDK	Programmatic	العميل	بلا
ذاكرة التخزين المؤقت Azure ل Redis	أصلي في العميل	Programmatic	العميل	TextWriter
Search	أصلي في العميل	Programmatic	العميل	ETW أو مخصص
ناقل الخدمة	أصلي في العميل	Programmatic	مدير مساحة الاسم ومصنع المراسلة والعميل	ETW
Service Fabric	أصلي في العميل	Programmatic	العميل	بلا
SQL Database مع ADO.NET	Polly	التصريحي والبرنامجي	عبارات مفردة أو كتل من التعليمة البرمجية	مخصص
SQL Database مع Entity Framework	أصلي في العميل	Programmatic	عالمي لكل AppDomain	بلا
SQL Database مع Entity Framework Core	أصلي في العميل	Programmatic	عالمي لكل AppDomain	بلا
التخزين	أصلي في العميل	Programmatic	العميل والعمليات الفردية	TraceSource

إشعار

بالنسبة لمعظم آليات إعادة المحاولة المضمنة في Azure، لا توجد طريقة حالياً لتطبيق نهج إعادة محاولة مختلف لأنواع مختلفة من الخطأ أو الاستثناء. يجب عليك تكوين نهج توفر أفضل متوسط أداء وتوافر. تتمثل إحدى طرق ضبط النهج في تحليل ملفات السجل لتحديد نوع الأخطاء المؤقتة التي تحدث.

Microsoft Entra ID

معرف Microsoft Entra هو حل سحابي شامل لإدارة الهوية والوصول يجمع بين خدمات الدليل الأساسية وإدارة الهوية المتقدمة والأمان وإدارة الوصول إلى التطبيقات. كما يوفر معرف Microsoft Entra للمطورين نظاما أساسيا لإدارة الهوية لتوفير التحكم في الوصول إلى تطبيقاتهم، استنادا إلى النهج والقواعد المركزية.

إشعار

لإعادة محاولة التوجيه بشأن نقاط نهاية هوية الخدمة المُدارة، راجع كيفية استخدام أجهزة Azure الظاهرية Managed Service Identity (MSI) للحصول على الرمز المميز.

آلية إعادة المحاولة

هناك آلية إعادة محاولة مضمنة لمعرف Microsoft Entra في مكتبة مصادقة Microsoft (MSAL). لتجنب عمليات الإغلاق غير المتوقعة، نوصي بأن تقوم مكتبات الجهات الخارجية والتعليمة البرمجية للتطبيق بعدم إعادة محاولة الاتصالات الفاشلة، مع السماح لـ MSAL بمعالجة عمليات إعادة المحاولة.

أعد محاولة إرشادات الاستخدام

ضع في اعتبارك الإرشادات التالية عند استخدام معرف Microsoft Entra:

عندما يكون ذلك ممكناً، استخدم مكتبة MSAL والدعم المدمج لإعادة المحاولة.
إذا كنت تستخدم واجهة برمجة تطبيقات REST لمعرف Microsoft Entra، أعد محاولة العملية إذا كان رمز النتيجة 429 (طلبات كثيرة جدا) أو خطأ في النطاق 5xx. لا تقم بإعادة المحاولة لأي أخطاء أخرى.
بالنسبة لأخطاء 429، أعد المحاولة فقط بعد الوقت المحدد في العنوان إعادة المحاولة بعد.
بالنسبة لأخطاء 5xx، استخدم التراجع الأسي، مع إعادة المحاولة الأولى بعد 5 ثوانٍ على الأقل من الاستجابة.
لا تقم بإعادة المحاولة على أخطاء أخرى غير 429 و5xx.

الخطوات التالية

مكتبة مصادقة Microsoft (MSAL)

Azure Cosmos DB

Azure Cosmos DB هي قاعدة بيانات متعددة النماذج مدارة بالكامل تدعم بيانات JSON بدون مخطط. إنه يوفر أداءً قابلاً للتكوين وموثوقاً، ومعالجة عمليات JavaScript أصلية، وهو مصمم للسحابة ذات النطاق المرن.

آلية إعادة المحاولة

تعيد Azure Cosmos DB SDKs المحاولة تلقائيا في حالات خطأ معينة، ويتم تشجيع تطبيقات المستخدم على أن يكون لها نهج إعادة المحاولة الخاصة بها. راجع دليل تصميم التطبيقات المرنة باستخدام Azure Cosmos DB SDKs للحصول على قائمة كاملة بحالات الخطأ ومتى يجب إعادة المحاولة.

القياس عن بعد

اعتماداً على لغة التطبيق الخاص بك، يتم عرض التشخيصات وبيانات تتبع الاستخدام كسجلات أو خصائص تمت ترقيتها في استجابات العملية. لمزيد من المعلومات، راجع قسم "التقاط التشخيصات" في Azure Cosmos DB C# SDK وAzure Cosmos DB Java SDK.

Data Lake Store

يجعل Data Lake Storage Gen2 Azure Storage الأساس لبناء مستودعات بيانات المؤسسة على Azure. يسمح لك Data Lake Storage Gen2 بإدارة كميات هائلة من البيانات بسهولة.

تتضمن مكتبة عميل Azure Storage Files Data Lake جميع الإمكانات المطلوبة لتسهيل تخزين البيانات من أي حجم وشكل وسرعة على المطورين وعلماء البيانات والمحللين، والقيام بجميع أنواع المعالجة والتحليلات عبر الأنظمة الأساسية واللغات.

آلية إعادة المحاولة

يسمح لك DataLakeServiceClient بمعالجة موارد خدمة Azure Data Lake وأنظمة الملفات. يوفر حساب التخزين مساحة الاسم ذات المستوى الأعلى لخدمة Data Lake. عند إنشاء العميل، يمكنك توفير خيارات تكوين العميل للاتصال بخدمة Azure Data Lake (DataLakeClientOptions). تتضمن DataLakeClientOptions خاصية إعادة المحاولة (موروثة من Azure.Core.ClientOptions) التي يمكن تكوينها (فئة RetryOptions).

القياس عن بعد

تعد مراقبة استخدام Azure Storage وأدائه جزءا مهما من تشغيل الخدمة. ومن أمثلة ذلك العمليات المتكررة أو العمليات ذات زمن انتقال عالي أو العمليات التي تسبب تقييد الخدمة.

تتوفر جميع عمليات بيانات تتبع الاستخدام عن بعد لحساب التخزين الخاص بك من خلال سجلات Azure Storage في Azure Monitor. تدمج هذه الميزة حساب التخزين الخاص بك مع Log Analytics و Event Hubs، وفي نفس الوقت تمكنك أيضا من أرشفة السجلات إلى حساب تخزين آخر. للاطلاع على القائمة الكاملة لسجلات المقاييس والموارد والمخطط الخاص بها، راجع مرجع بيانات مراقبة تخزين Azure.

مراكز الأحداث

تعد مراكز الأحداث خدمة استيعاب لبيانات تتبع الاستخدام تقوم بجمع ملايين الأحداث وتحويلها وتخزينها.

آلية إعادة المحاولة

يتم التحكم في سلوك إعادة المحاولة في مكتبة عميل مراكز الأحداث بواسطة الخاصية RetryPolicy في الفئة EventHubClient. يعيد النهج الافتراضي المحاولة مع التراجع الأسي عندما تقوم Azure Event Hubs بإرجاع عابر EventHubsException أو OperationCanceledException. نهج إعادة المحاولة الافتراضية لمراكز الأحداث هي إعادة المحاولة حتى 9 مرات مع وقت تراجع أسي يصل إلى 30 ثانية.

مثال

EventHubClient client = EventHubClient.CreateFromConnectionString("[event_hub_connection_string]");
client.RetryPolicy = RetryPolicy.Default;

الخطوات التالية

مكتبة عميل Azure Event Hubs ل .NET

IoT Hub

Azure IoT Hub هي خدمة لتوصيل الأجهزة ومراقبتها وإدارتها لتطوير تطبيقات إنترنت الأشياء (IoT).

آلية إعادة المحاولة

يمكن أن تكتشف SDK لجهاز Azure IoT الأخطاء في الشبكة أو البروتوكول أو التطبيق. استناداً إلى نوع الخطأ، يتحقق SDK مما إذا كانت هناك حاجة إلى إعادة المحاولة. إذا كان الخطأ قابلاً للاسترداد، تبدأ SDK في إعادة المحاولة باستخدام نهج إعادة المحاولة المكون.

نهج إعادة المحاولة الافتراضية هي التراجع الأسي مع عدم الاستقرار العشوائي، ولكن يمكن تهيئتها.

تكوين النهج

يختلف تكوين النهج حسب اللغة. لمزيد من المعلومات، راجع تكوين نهج إعادة محاولة مركز IoT.

الخطوات التالية

ذاكرة التخزين المؤقت في Azure لـ Redis

Azure Cache for Redis هي خدمة وصول سريع إلى البيانات وذاكرة تخزين مؤقت منخفضة زمن الوصول تستند إلى ذاكرة التخزين المؤقت Redis الشهيرة مفتوحة المصدر. إنه آمن، تديره Microsoft، ويمكن الوصول إليه من أي تطبيق في Azure.

تستند الإرشادات الواردة في هذا القسم إلى استخدام عميل StackExchange.Redis للوصول إلى ذاكرة التخزين المؤقت. يمكن العثور على قائمة بالعملاء المناسبين الآخرين على موقع Redis على الويب، وقد تكون لهم آليات إعادة محاولة مختلفة.

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

آلية إعادة المحاولة

يستخدم عميل StackExchange.Redis فئة مدير الاتصال التي تم تكوينها من خلال مجموعة من الخيارات، بما في ذلك:

ConnectRetry. عدد المرات التي ستتم فيها إعادة محاولة الاتصال الفاشل بذاكرة التخزين المؤقت.
ReconnectRetryPolicy. استراتيجية إعادة المحاولة لاستخدامها.
ConnectTimeout. أقصى وقت انتظار بالملّي ثانية.

تكوين النهج

يتم تكوين نُهج إعادة المحاولة برمجياً عن طريق تعيين الخيارات للعميل قبل الاتصال بذاكرة التخزين المؤقت. يمكن القيام بذلك عن طريق إنشاء مثيل للفئة ConfigurationOptions، وملء خصائصها، وتمريرها إلى طريقة Connect.

تدعم الفئات المضمنة التأخير الخطي (الثابت) والتراجع الأسي مع فترات إعادة المحاولة العشوائية. يمكنك أيضاً إنشاء نهج إعادة محاولة مخصصة عن طريق تنفيذ واجهة IReconnectRetryPolicy.

يقوم المثال التالي بتكوين إستراتيجية إعادة المحاولة باستخدام التراجع الأسي.

var deltaBackOffInMilliseconds = TimeSpan.FromSeconds(5).TotalMilliseconds;
var maxDeltaBackOffInMilliseconds = TimeSpan.FromSeconds(20).TotalMilliseconds;
var options = new ConfigurationOptions
{
    EndPoints = {"localhost"},
    ConnectRetry = 3,
    ReconnectRetryPolicy = new ExponentialRetry(deltaBackOffInMilliseconds, maxDeltaBackOffInMilliseconds),
    ConnectTimeout = 2000
};
ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

بدلاً من ذلك، يمكنك تحديد الخيارات كسلسلة، وتمريرها إلى طريقة الاتصال. لا يمكن تعيين الخاصية ReconnectRetryPolicy بهذه الطريقة، فقط من خلال التعليمات البرمجية.

var options = "localhost,connectRetry=3,connectTimeout=2000";
ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

يمكنك أيضاً تحديد الخيارات مباشرةً عند الاتصال بذاكرة التخزين المؤقت.

var conn = ConnectionMultiplexer.Connect("redis0:6380,redis1:6380,connectRetry=3");

لمزيد من المعلومات، راجع تكوين Stack Exchange Redis في وثائق StackExchange.Redis.

يعرض الجدول التالي الإعدادات الافتراضية لنهج إعادة المحاولة المضمنة.

سياق	الإعداد	القيمة الافتراضية (v 1.2.2)	معني
خيارات الإعداد	إعادة الاتصال وقت الاتصال SyncTimeout ReconnectRetryPolicy	3 5000 مللي ثانية كحد أقصى بالإضافة إلى SyncTimeout 1000 LinearRetry 5000 ملّي ثانية	عدد مرات تكرار محاولات الاتصال أثناء عملية الاتصال الأولية. مهلة (ملّي ثانية) لعمليات الاتصال. ليس تأخيراً بين محاولات إعادة المحاولة. الوقت (ملّي ثانية) للسماح بعمليات متزامنة. أعد المحاولة كل 5000 ملّي ثانية.

إشعار

بالنسبة للعمليات المتزامنة، يمكن أن يضيف SyncTimeout وقت انتقال من طرف إلى طرف، ولكن تعيين القيمة منخفضة جداً قد يتسبب في انقضاء مهلات زائدة. راجع كيفية استكشاف أخطاء Azure Cache لـ Redis وإصلاحها. بشكل عام، تجنب استخدام العمليات المتزامنة، واستخدم العمليات غير المتزامنة بدلاً من ذلك. لمزيد من المعلومات، راجع التدفقات والمُعدِّدات.

أعد محاولة إرشادات الاستخدام

ضع في اعتبارك الإرشادات التالية عند استخدام Azure Cache لـ Redis:

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

القياس عن بعد

يمكنك جمع معلومات بشأن الاتصالات (وليس العمليات الأخرى) باستخدام TextWriter.

var writer = new StringWriter();
ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

يتم عرض مثال على الإخراج الذي يولده هذا أدناه.

localhost:6379,connectTimeout=2000,connectRetry=3
1 unique nodes specified
Requesting tie-break from localhost:6379 > __Booksleeve_TieBreak...
Allowing endpoints 00:00:02 to respond...
localhost:6379 faulted: SocketFailure on PING
localhost:6379 failed to nominate (Faulted)
> UnableToResolvePhysicalConnection on GET
No masters detected
localhost:6379: Standalone v2.0.0, master; keep-alive: 00:01:00; int: Connecting; sub: Connecting; not in use: DidNotRespond
localhost:6379: int ops=0, qu=0, qs=0, qc=1, wr=0, sync=1, socks=2; sub ops=0, qu=0, qs=0, qc=0, wr=0, socks=2
Circular op-count snapshot; int: 0 (0.00 ops/s; spans 10s); sub: 0 (0.00 ops/s; spans 10s)
Sync timeouts: 0; fire and forget: 0; last heartbeat: -1s ago
resetting failing connections to retry...
retrying; attempts left: 2...
...

الأمثلة

يكوّن مثال التعليمة البرمجية التالي تأخيراً (خطياً) ثابتاً بين عمليات إعادة المحاولة عند تكوين عميل StackExchange.Redis. يوضح هذا المثال كيفية تعيين التكوين باستخدام مثيل ConfigurationOptions.

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using StackExchange.Redis;

namespace RetryCodeSamples
{
    class CacheRedisCodeSamples
    {
        public async static Task Samples()
        {
            var writer = new StringWriter();
            {
                try
                {
                    var retryTimeInMilliseconds = TimeSpan.FromSeconds(4).TotalMilliseconds; // delay between retries

                    // Using object-based configuration.
                    var options = new ConfigurationOptions
                                        {
                                            EndPoints = { "localhost" },
                                            ConnectRetry = 3,
                                            ReconnectRetryPolicy = new LinearRetry(retryTimeInMilliseconds)
                                        };
                    ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

                    // Store a reference to the multiplexer for use in the application.
                }
                catch
                {
                    Console.WriteLine(writer.ToString());
                    throw;
                }
            }
        }
    }
}

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

using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using StackExchange.Redis;

namespace RetryCodeSamples
{
    class CacheRedisCodeSamples
    {
        public async static Task Samples()
        {
            var writer = new StringWriter();
            {
                try
                {
                    // Using string-based configuration.
                    var options = "localhost,connectRetry=3,connectTimeout=2000";
                    ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(options, writer);

                    // Store a reference to the multiplexer for use in the application.
                }
                catch
                {
                    Console.WriteLine(writer.ToString());
                    throw;
                }
            }
        }
    }
}

لمزيد من الأمثلة، راجع التكوين على موقع المشروع على الويب.

الخطوات التالية

موقع Redi s على الويب

Azure Search

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

آلية إعادة المحاولة

يتضمن Azure SDK ل .NET مكتبة عميل Azure.Search.Documents من فريق Azure SDK المكافئ وظيفيا لمكتبة العميل السابقة، Microsoft.Azure.Search.

يتم التحكم في سلوك إعادة المحاولة في Microsoft.Azure.Search بواسطة أسلوب SetRetryPolicy على فئتي SearchServiceClient و SearchIndexClient. يعيد النهج الافتراضي المحاولة مع التراجع الأسي عندما يُرجع Azure Search استجابة 5xx أو 408 (مهلة الطلب).

يتم التحكم في سلوك إعادة المحاولة في Azure.Search.Documents بواسطة SearchClientOptions (وهو جزء من الدالة الإنشائية SearchClient) في الخاصية Retry، التي تنتمي إلى فئة Azure.Core.RetryOptions (حيث تتوفر جميع التكوينات).

القياس عن بعد

تتبع مع ETW أو عن طريق تسجيل موفر تتبع مخصص. لمزيد من المعلومات، راجع وثائق AutoRest.

ناقل الخدمة

ناقل خدمة Microsoft Azure عبارة عن نظام أساسي للرسائل السحابية يوفر تبادلاً غير محكم للرسائل مع نطاق ومرونة محسنين لمكونات أحد التطبيقات، سواء تمت استضافتها في السحابة أو في أماكن العمل.

آلية إعادة المحاولة

تعتمد مساحة الاسم وبعض تفاصيل التكوين على حزمة SDK لعميل ناقل خدمة Microsoft Azure المستخدمة:

الحزمة	‏‏الوصف	مساحة الاسم
Azure.Messaging.ServiceBus	مكتبة عميل ناقل خدمة Azure ل .NET	`Azure.Messaging.ServiceBus`
WindowsAzure.ServiceBus	هذه الحزمة هي مكتبة عميل ناقل خدمة Microsoft Azure الأقدم. يتطلب .NET Framework 4.5.2.	`Microsoft.Azure.ServiceBus`

أعد محاولة إرشادات الاستخدام

ServiceBusRetryOptions تحدد الخاصية خيارات إعادة المحاولة للكائنServiceBusClient:

الإعدادات	القيمة الافتراضية	المعنى
نهج إعادة المحاولة المخصصة		نهج إعادة محاولة مخصص لاستخدامه بدلا من قيم الخيارات الفردية.
تأخير	0.8 ثانية	التأخير بين محاولات إعادة المحاولة لنهج ثابت أو التأخير الذي تستند إليه العمليات الحسابية لنهج قائم على التراجع.
MaxDelay	60 ثانية	الحد الأقصى للتأخير المسموح به بين محاولات إعادة المحاولة.
MaxRetries	3	الحد الأقصى لعدد محاولات إعادة المحاولة قبل اعتبار العملية المقترنة قد فشلت.
وضع	المتزايد	الأسلوب المستخدم لحساب تأخيرات إعادة المحاولة.
TryTimeout	60 ثانية	الحد الأقصى لمدة الانتظار لإكمال محاولة واحدة، سواء كانت المحاولة الأولية أو إعادة المحاولة.

تعيين الخاصية Mode لتكوين ServiceBusRetryMode مع أي من هذه القيم:

الخاصية	القيمة‬	‏‏الوصف
المتزايد	1	ستتأخر محاولات إعادة المحاولة استنادا إلى استراتيجية التراجع، حيث ستزيد كل محاولة من المدة التي تنتظرها قبل إعادة المحاولة.
ثابت	0	تحدث محاولات إعادة المحاولة على فترات زمنية ثابتة؛ كل تأخير هو مدة متناسقة.

مثال:

using Azure.Messaging.ServiceBus;

string connectionString = "<connection_string>";
string queueName = "<queue_name>";

// Because ServiceBusClient implements IAsyncDisposable, we'll create it
// with "await using" so that it is automatically disposed for us.
var options = new ServiceBusClientOptions();
options.RetryOptions = new ServiceBusRetryOptions
{
    Delay = TimeSpan.FromSeconds(10),
    MaxDelay = TimeSpan.FromSeconds(30),
    Mode = ServiceBusRetryMode.Exponential,
    MaxRetries = 3,
};
await using var client = new ServiceBusClient(connectionString, options);

القياس عن بعد

يجمع ناقل خدمة Microsoft Azure نفس أنواع بيانات المراقبة مثل موارد Azure الأخرى. يمكنك مراقبة ناقل خدمة Azure باستخدام Azure Monitor.

لديك أيضا خيارات مختلفة لإرسال بيانات تتبع الاستخدام باستخدام مكتبات عميل ناقل خدمة Microsoft .NET.

مثال

يوضح مثال التعليمات البرمجية التالي كيفية استخدام الحزمة Azure.Messaging.ServiceBus من أجل:

تعيين نهج إعادة المحاولة لاستخدام ServiceBusClient جديد ServiceBusClientOptions.
إنشاء رسالة جديدة بمثيل جديد ل ServiceBusMessage.
إرسال رسالة إلى ناقل خدمة Microsoft Azure باستخدام ServiceBusSender.SendMessageAsync(message) الأسلوب .
تلقي باستخدام ServiceBusReceiver، والتي يتم تمثيلها ككائنات ServiceBusReceivedMessage .

// using Azure.Messaging.ServiceBus;

using Azure.Messaging.ServiceBus;

string connectionString = "<connection_string>";
string queueName = "queue1";

// Because ServiceBusClient implements IAsyncDisposable, we'll create it 
// with "await using" so that it is automatically disposed for us.
var options = new ServiceBusClientOptions();
options.RetryOptions = new ServiceBusRetryOptions
{
    Delay = TimeSpan.FromSeconds(10),
    MaxDelay = TimeSpan.FromSeconds(30),
    Mode = ServiceBusRetryMode.Exponential,
    MaxRetries = 3,
};
await using var client = new ServiceBusClient(connectionString, options);

// The sender is responsible for publishing messages to the queue.
ServiceBusSender sender = client.CreateSender(queueName);
ServiceBusMessage message = new ServiceBusMessage("Hello world!");

await sender.SendMessageAsync(message);

// The receiver is responsible for reading messages from the queue.
ServiceBusReceiver receiver = client.CreateReceiver(queueName);
ServiceBusReceivedMessage receivedMessage = await receiver.ReceiveMessageAsync();

string body = receivedMessage.Body.ToString();
Console.WriteLine(body);

الخطوات التالية

أنماط المراسلة غير المتزامنة والتوافر العالي

Service Fabric

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

داخلياً، تتعامل Service Fabric مع هذا النوع من الأخطاء العابرة. يمكنك تكوين بعض الإعدادات باستخدام فئة OperationRetrySettings أثناء إعداد الخدمات الخاصة بك. يبين الرمز التالي مثالاً. في معظم الحالات، لا ينبغي أن يكون هذا ضروريا، وستكون الإعدادات الافتراضية جيدة.

FabricTransportRemotingSettings transportSettings = new FabricTransportRemotingSettings
{
    OperationTimeout = TimeSpan.FromSeconds(30)
};

var retrySettings = new OperationRetrySettings(TimeSpan.FromSeconds(15), TimeSpan.FromSeconds(1), 5);

var clientFactory = new FabricTransportServiceRemotingClientFactory(transportSettings);

var serviceProxyFactory = new ServiceProxyFactory((c) => clientFactory, retrySettings);

var client = serviceProxyFactory.CreateServiceProxy<ISomeService>(
    new Uri("fabric:/SomeApp/SomeStatefulReliableService"),
    new ServicePartitionKey(0));

الخطوات التالية

معالجة استثناءات الاتصال عن بعد

SQL Database باستخدام ADO.NET

قاعدة بيانات SQL هي SQL Database مستضافة متاحة في مجموعة من الأحجام وكخدمة قياسية (مشتركة) ومتميزة (غير مشتركة).

آلية إعادة المحاولة

لا تحتوي SQL Database على دعم مضمن لعمليات إعادة المحاولة عند الوصول إليها باستخدام ADO.NET. ومع ذلك، يمكن استخدام التعليمة البرمجية للإرجاع من الطلبات لتحديد سبب فشل الطلب. لمزيد من المعلومات بشأن التحكم في SQL Database، راجع حدود موارد Azure SQL Database. للحصول على قائمة برموز الخطأ ذات الصلة، راجع رموز خطأ SQL لتطبيقات عميل SQL Database.

يمكنك استخدام مكتبة Polly لتنفيذ عمليات إعادة المحاولة لـ SQL Database. راجع معالجة الأخطاء العابرة باستخدام Polly.

أعد محاولة إرشادات الاستخدام

ضع في اعتبارك الإرشادات التالية عند الوصول إلى SQL Database باستخدام ADO.NET:

اختر خيار الخدمة المناسب (مشترك أو مميز). قد يعاني مثيل مشترك من تأخيرات في الاتصال والازدحام أطول من المعتاد بسبب استخدام المستأجرين الآخرين للخادم المشترك. إذا كانت هناك حاجة إلى أداء أكثر قابلية للتنبؤ وعمليات زمن انتقال منخفض موثوق بها، ففكر في اختيار الخيار المتميز.
تأكد من إجراء عمليات إعادة المحاولة على المستوى أو النطاق المناسب لتجنب العمليات غير الفعالة التي تسبب عدم تناسق في البيانات. من الناحية المثالية، يجب أن تكون جميع العمليات خاملة بحيث يمكن تكرارها دون التسبب في عدم الاتساق. في حالة عدم حدوث ذلك، يجب إجراء إعادة المحاولة على مستوى أو نطاق يسمح بالتراجع عن جميع التغييرات ذات الصلة في حالة فشل عملية واحدة؛ على سبيل المثال، من داخل نطاق المعاملات. لمزيد من المعلومات، راجع طبقة الوصول إلى البيانات في Cloud Service Fundamentals - معالجة الأخطاء العابرة.
لا يوصى باستخدام استراتيجية الفاصل الزمني الثابت مع قاعدة بيانات Azure SQL باستثناء السيناريوهات التفاعلية حيث لا يوجد سوى عدد قليل من عمليات إعادة المحاولة على فترات قصيرة. بدلا من ذلك، ضع في اعتبارك استخدام استراتيجية التراجع الأسي لمعظم السيناريوهات.
اختر قيمة مناسبة للاتصال ومهلة الأوامر عند تحديد الاتصالات. قد تؤدي المهلة القصيرة جداً إلى حدوث فشل سابق لأوانه في الاتصالات عندما تكون قاعدة البيانات مشغولة. قد تمنع المهلة الطويلة جداً عمل منطق إعادة المحاولة بشكل صحيح من خلال الانتظار لفترة طويلة قبل اكتشاف اتصال فاشل. قيمة المهلة هي مكون من زمن الانتقال من طرف إلى طرف؛ تتم إضافته بشكل فعال إلى تأخير إعادة المحاولة المحدد في نهج إعادة المحاولة لكل محاولة إعادة محاولة.
أغلق الاتصال بعد بعض عمليات إعادة المحاولة، حتى عند استخدام منطق إعادة محاولة التراجع الأسي، وأعد محاولة العملية على اتصال جديد. يمكن أن تكون إعادة محاولة نفس العملية عدة مرات على نفس الاتصال عاملاً يساهم في مشاكل الاتصال. للحصول على مثال لهذه التقنية، راجع طبقة الوصول إلى البيانات في Cloud Service Fundamentals - معالجة الأخطاء العابرة.
عند استخدام تجمع الاتصال (الافتراضي) هناك فرصة لاختيار نفس الاتصال من التجمع، حتى بعد إغلاق اتصال وإعادة فتحه. إذا كان الأمر كذلك، فإن تقنية لحلها هي استدعاء أسلوب ClearPool لفئة Sql الاتصال ion لوضع علامة على الاتصال على أنه غير قابل لإعادة الاستخدام. ومع ذلك، يجب عليك القيام بذلك فقط بعد فشل عدة محاولات اتصال، وفقط عند مواجهة فئة معينة من حالات الفشل العابر مثل مهلات SQL (تعليمة برمجية الخطأ -2) المتعلقة بالاتصالات المعيبة.
إذا كانت كلمة المرور إلى البيانات تستخدم العمليات التي تم بدؤها كمثيلات TransactionScope، يجب على منطق إعادة المحاولة إعادة فتح الاتصال وبدء نطاق عملية جديد. لهذا السبب، يجب أن تشمل كتلة التعليمة البرمجية القابلة لإعادة المحاولة النطاق الكامل للعملية.

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

سياق	عينة الهدف E2E أقصى زمن استجابة	إستراجية إعادة محاولة	الإعدادات	القيم	كيفية عملها
تفاعلي، واجهة المستخدم، أو المقدمة	ثانيتين	FixedInterval	عدد مرات إعادة المحاولة الفاصل الزمني لإعادة المحاولة إعادة المحاولة السريعة الأولى	3 500 ملّي ثانية صحيح	محاولة 1 - تأخير 0 ثانية المحاولة 2 - تأخير 500 ملّي ثانية المحاولة 3 - تأخير 500 ملّي ثانية
خلفية أو دفعة	30 ثانية	ExponentialBackoff	عدد مرات إعادة المحاولة Min back-off Max back-off Delta back-off إعادة المحاولة السريعة الأولى	5 0 ثانية 60 ثانية ثانيتين true	محاولة 1 - تأخير 0 ثانية محاولة 2 - تأخير ثانيتين تقريبًا محاولة 3 - تأخير 6 ثوانٍ تقريبًا محاولة 4 - تأخير 14 ثانية تقريبًا محاولة 5 - تأخير 30 ثانية تقريبًا

إشعار

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

الأمثلة

يوضح هذا القسم كيف يمكنك استخدام Polly للوصول إلى Azure SQL Database باستخدام مجموعة من نُهج إعادة المحاولة المكونة في فئة Policy.

توضح التعليمة البرمجية التالية طريقة ملحق على الفئة SqlCommand التي تستدعي ExecuteAsync بالتراجع الأسي.

public async static Task<SqlDataReader> ExecuteReaderWithRetryAsync(this SqlCommand command)
{
    GuardConnectionIsNotNull(command);

    var policy = Policy.Handle<Exception>().WaitAndRetryAsync(
        retryCount: 3, // Retry 3 times
        sleepDurationProvider: attempt => TimeSpan.FromMilliseconds(200 * Math.Pow(2, attempt - 1)), // Exponential backoff based on an initial 200 ms delay.
        onRetry: (exception, attempt) =>
        {
            // Capture some information for logging/telemetry.
            logger.LogWarn($"ExecuteReaderWithRetryAsync: Retry {attempt} due to {exception}.");
        });

    // Retry the following call according to the policy.
    await policy.ExecuteAsync<SqlDataReader>(async token =>
    {
        // This code is executed within the Policy

        if (conn.State != System.Data.ConnectionState.Open) await conn.OpenAsync(token);
        return await command.ExecuteReaderAsync(System.Data.CommandBehavior.Default, token);

    }, cancellationToken);
}

يمكن استخدام طريقة التمديد غير المتزامن هذه على النحو التالي.

var sqlCommand = sqlConnection.CreateCommand();
sqlCommand.CommandText = "[some query]";

using (var reader = await sqlCommand.ExecuteReaderWithRetryAsync())
{
    // Do something with the values
}

الخطوات التالية

طبقة الوصول إلى البيانات في أساسيات الخدمة السحابية - معالجة الأعطال المؤقتة

SQL Database باستخدام Entity Framework 6

قاعدة بيانات SQL هي SQL Database مستضافة متاحة في مجموعة من الأحجام وكخدمة قياسية (مشتركة) ومتميزة (غير مشتركة). Entity Framework هو مخطط ارتباط عنصري يمكّن مطوري .NET من العمل مع البيانات العلائقية باستخدام عناصر خاصة بالمجال. فهو يلغي الحاجة إلى معظم التعليمات البرمجية للوصول إلى البيانات التي يحتاج المطورون عادةً إلى كتابتها.

آلية إعادة المحاولة

يتم توفير دعم إعادة المحاولة عند الوصول إلى SQL Database باستخدام Entity Framework 6.0 والإصدارات الأحدث من خلال آلية تسمى مرونة الاتصال / منطق إعادة المحاولة. الميزات الرئيسية لآلية إعادة المحاولة هي:

التجريد الأساسي هو واجهة IDbExecutionStrategy. هذه الواجهة:
- يحدد طرق التنفيذ المتزامنة وغير المتزامنة.
- يحدد الفئات التي يمكن استخدامها مباشرة أو يمكن تكوينها في سياق قاعدة البيانات كإستراتيجية افتراضية، أو تعيينها إلى اسم الموفر، أو تعيينها إلى اسم الموفر واسم الخادم. عند تكوينها في سياق ما، تحدث عمليات إعادة المحاولة على مستوى عمليات قاعدة البيانات الفردية، والتي قد يكون يوجد العديد منها لعملية سياق معينة.
- يحدد متى تتم إعادة محاولة اتصال فاشل، وكيف.
يتضمن العديد من التطبيقات المضمنة لواجهة IDbExecutionStrategy :
- الافتراضي: لا إعادة المحاولة.
- الإعداد الافتراضي لقاعدة بيانات SQL (تلقائي): لا توجد إعادة محاولة، ولكن يفحص الاستثناءات ويلفها باقتراح لاستخدام إستراتيجية SQL Database.
- الافتراضي لقاعدة بيانات SQL: أسي (موروث من الفئة الأساسية) بالإضافة إلى منطق الكشف عن SQL Database.
إنها تنفذ إستراتيجية تراجع أسية تتضمن التوزيع العشوائي.
تعد فئات إعادة المحاولة المضمنة ذات حالة ولا تكون آمنة لمؤشر الترابط. ومع ذلك، يمكن إعادة استخدامها بعد اكتمال العملية الحالية.
إذا تم تجاوز عدد مرات إعادة المحاولة المحدد، يتم التفاف النتائج في استثناء جديد. لا يفقيع الاستثناء الحالي.

تكوين النهج

يتم توفير دعم إعادة المحاولة عند الوصول إلى SQL Database باستخدام Entity Framework 6.0 والإصدارات الأحدث. يتم تكوين نهج إعادة المحاولة برمجياً. لا يمكن تغيير التكوين على أساس كل عملية.

عند تكوين إستراتيجية على السياق كإعداد افتراضي، فإنك تحدد وظيفة تقوم بإنشاء إستراتيجية جديدة عند الطلب. يوضح التعليمة البرمجية التالي كيف يمكنك إنشاء فئة تكوين إعادة المحاولة التي تعمل على توسيع الفئة الأساسية DbConfiguration.

public class BloggingContextConfiguration : DbConfiguration
{
  public BlogConfiguration()
  {
    // Set up the execution strategy for SQL Database (exponential) with 5 retries and 4 sec delay
    this.SetExecutionStrategy(
         "System.Data.SqlClient", () => new SqlAzureExecutionStrategy(5, TimeSpan.FromSeconds(4)));
  }
}

يمكنك بعد ذلك تحديد هذا كإستراتيجية إعادة المحاولة الافتراضية لجميع العمليات باستخدام طريقة SetConfiguration لمثيل DbConfiguration عند بدء تشغيل التطبيق. بشكل افتراضي، سوف تكتشف EF تلقائياً فئة التكوين وتستخدمها.

DbConfiguration.SetConfiguration(new BloggingContextConfiguration());

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

[DbConfigurationType(typeof(BloggingContextConfiguration))]
public class BloggingContext : DbContext

إذا كنت بحاجة إلى استخدام إستراتيجيات مختلفة لإعادة المحاولة لعمليات معينة، أو تعطيل عمليات إعادة المحاولة لعمليات معينة، يمكنك إنشاء فئة تكوين تسمح لك بتعليق الإستراتيجيات أو تبديلها عن طريق تعيين علامة في CallContext. يمكن لفئة التكوين استخدام هذه العلامة لتبديل الإستراتيجيات، أو تعطيل الإستراتيجية التي تقدمها واستخدام إستراتيجية افتراضية. لمزيد من المعلومات، راجع تعليق إستراتيجية التنفيذ (EF6 فصاعداً).

أسلوب آخر لاستخدام إستراتيجيات إعادة المحاولة المحددة للعمليات الفردية هو إنشاء مثيل لفئة الإستراتيجية المطلوبة وتزويد الإعدادات المطلوبة من خلال المعلمات. ثم تقوم باستدعاء أسلوب ExecuteAsync الخاص به.

var executionStrategy = new SqlAzureExecutionStrategy(5, TimeSpan.FromSeconds(4));
var blogs = await executionStrategy.ExecuteAsync(
    async () =>
    {
        using (var db = new BloggingContext("Blogs"))
        {
            // Acquire some values asynchronously and return them
        }
    },
    new CancellationToken()
);

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

لمزيد من المعلومات، راجع التكوين المستند إلى التعليمة البرمجية (EF6 فصاعداً).

يوضح الجدول التالي الإعدادات الافتراضية لنهج إعادة المحاولة المضمنة عند استخدام EF6.

الإعدادات	القيمة الافتراضية	المعنى
النهج	المتزايد	التراجع الأسي.
MaxRetryCount	5	الحد الأقصى لعدد المحاولات.
MaxDelay	30 seconds	الحد الأقصى للتأخير بين عمليات إعادة المحاولة. لا تؤثر هذه القيمة على كيفية حساب سلسلة التأخيرات. إنها تحدد فقط الحد الأعلى.
DefaultCoefficient	1 ثانية	معامل حساب التراجع الأسي. لا يمكن تغيير هذه القيمة.
DefaultRandomFactor	1.1	يستخدم المضاعف لإضافة تأخير عشوائي لكل إدخال. لا يمكن تغيير هذه القيمة.
DefaultExponentialBase	2	المضاعف المستخدم لحساب التأخير التالي. لا يمكن تغيير هذه القيمة.

أعد محاولة إرشادات الاستخدام

ضع في اعتبارك الإرشادات التالية عند الوصول إلى SQL Database باستخدام EF6:

اختر خيار الخدمة المناسب (مشترك أو مميز). قد يعاني مثيل مشترك من تأخيرات في الاتصال والازدحام أطول من المعتاد بسبب استخدام المستأجرين الآخرين للخادم المشترك. إذا كانت هناك حاجة إلى أداء يمكن التنبؤ به وعمليات زمن انتقال منخفض موثوق بها، ففكر في اختيار الخيار المتميز.
لا يوصى باستخدام استراتيجية الفاصل الزمني الثابت مع قاعدة بيانات Azure SQL. بدلاً من ذلك، استخدم إستراتيجية التراجع الأسي لأن الخدمة قد تكون محملة بشكل زائد، والتأخيرات الأطول تتيح مزيداً من الوقت لاستعادتها.
اختر قيمة مناسبة للاتصال ومهلة الأوامر عند تحديد الاتصالات. ضع المهلة بناءً على تصميم منطق عملك ومن خلال الاختبار. قد تحتاج إلى تعديل هذه القيمة بمرور الوقت حيث تتغير أحجام البيانات أو عمليات الأعمال. قد تؤدي المهلة القصيرة جداً إلى حدوث فشل سابق لأوانه في الاتصالات عندما تكون قاعدة البيانات مشغولة. قد تمنع المهلة الطويلة جداً عمل منطق إعادة المحاولة بشكل صحيح من خلال الانتظار لفترة طويلة قبل اكتشاف اتصال فاشل. قيمة المهلة هي مكون من زمن الانتقال من طرف إلى طرف، على الرغم من أنه لا يمكنك بسهولة تحديد عدد الأوامر التي سيتم تنفيذها عند حفظ السياق. يمكنك تغيير المهلة الافتراضية عن طريق تعيين خاصية CommandTimeout لمثيل DbContext.
يدعم Entity Framework تكوينات إعادة المحاولة المحددة في ملفات التكوين. ومع ذلك، لتحقيق أقصى قدر من المرونة في Azure، يجب أن تفكر في إنشاء التكوين برمجياً داخل التطبيق. يمكن تخزين المعلمات المحددة لنُهج إعادة المحاولة، مثل عدد عمليات إعادة المحاولة وفترات إعادة المحاولة، في ملف تكوين الخدمة واستخدامها في وقت التشغيل لإنشاء النُهج المناسبة. يسمح هذا بتغيير الإعدادات دون الحاجة إلى إعادة تشغيل التطبيق.

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

سياق	عينة الهدف E2E أقصى زمن استجابة	نهج إعادة المحاولة	الإعدادات	القيم	كيفية عملها
تفاعلي، واجهة المستخدم، أو المقدمة	2 seconds	المتزايد	MaxRetryCount MaxDelay	3 750 ملّي ثانية	محاولة 1 - تأخير 0 ثانية المحاولة 2 - تأخير 750 ملّي ثانية المحاولة 3 - تأخير 750 ملّي ثانية
خلفية أو دفعة	30 seconds	المتزايد	MaxRetryCount MaxDelay	5 12 seconds	محاولة 1 - تأخير 0 ثانية محاولة 2 - تأخير ثانية تقريباً محاولة 3 - تأخير 3 ثوانٍ تقريباً محاولة 4 - تأخير 7 ثانية تقريباً محاولة 5 - تأخير 12 ثانية

إشعار

الأمثلة

يعرّف مثال التعليمة البرمجية التالي حلاً بسيطاً للوصول إلى البيانات يستخدم Entity Framework. فهو يعيّن إستراتيجية معينة لإعادة المحاولة عن طريق تحديد مثيل لفئة تسمى BlogConfiguration تمتد إلى DbConfiguration.

using System;
using System.Collections.Generic;
using System.Data.Entity;
using System.Data.Entity.SqlServer;
using System.Threading.Tasks;

namespace RetryCodeSamples
{
    public class BlogConfiguration : DbConfiguration
    {
        public BlogConfiguration()
        {
            // Set up the execution strategy for SQL Database (exponential) with 5 retries and 12 sec delay.
            // These values could be loaded from configuration rather than being hard-coded.
            this.SetExecutionStrategy(
                    "System.Data.SqlClient", () => new SqlAzureExecutionStrategy(5, TimeSpan.FromSeconds(12)));
        }
    }

    // Specify the configuration type if more than one has been defined.
    // [DbConfigurationType(typeof(BlogConfiguration))]
    public class BloggingContext : DbContext
    {
        // Definition of content goes here.
    }

    class EF6CodeSamples
    {
        public async static Task Samples()
        {
            // Execution strategy configured by DbConfiguration subclass, discovered automatically or
            // or explicitly indicated through configuration or with an attribute. Default is no retries.
            using (var db = new BloggingContext("Blogs"))
            {
                // Add, edit, delete blog items here, then:
                await db.SaveChangesAsync();
            }
        }
    }
}

يمكن العثور على المزيد من الأمثلة على استخدام آلية إعادة محاولة Entity Framework في مرونة الاتصال / منطق إعادة المحاولة.

SQL Database باستخدام Entity Framework Core

Entity Framework Core هو مخطط ارتباط عنصري يمكّن مطوري .NET Core من العمل مع البيانات باستخدام عناصر خاصة بالمجال. فهو يلغي الحاجة إلى معظم التعليمات البرمجية للوصول إلى البيانات التي يحتاج المطورون عادةً إلى كتابتها. تمت كتابة هذا الإصدار من Entity Framework من الألف إلى الياء، ولا يرث تلقائياً جميع الميزات من EF6.x.

آلية إعادة المحاولة

يتم توفير دعم إعادة المحاولة عند الوصول إلى SQL Database باستخدام Entity Framework Core من خلال آلية تسمى مرونة الاتصال. تم تقديم مرونة الاتصال في EF Core 1.1.0.

التجريد الأساسي هو واجهة IExecutionStrategy. تدرك إستراتيجية التنفيذ الخاصة بـ SQL Server، بما في ذلك SQL Azure، أنواع الاستثناءات التي يمكن إعادة المحاولة ولديها إعدادات افتراضية معقولة للحد الأقصى من عمليات إعادة المحاولة والتأخير بين عمليات إعادة المحاولة وما إلى ذلك.

الأمثلة

تمكّن التعليمة البرمجية التالية عمليات إعادة المحاولة التلقائية عند تكوين عنصر DbContext، والذي يمثل جلسة مع قاعدة البيانات.

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder
        .UseSqlServer(
            @"Server=(localdb)\mssqllocaldb;Database=EFMiscellaneous.ConnectionResiliency;Trusted_Connection=True;",
            options => options.EnableRetryOnFailure());
}

يوضح التعليمة البرمجية التالي كيفية تنفيذ عملية باستخدام عمليات إعادة المحاولة التلقائية، باستخدام إستراتيجية التنفيذ. يتم تحديد العملية في مفوض. في حال حدوث فشل عابر، ستستدعي إستراتيجية التنفيذ المفوض مرة أخرى.

using (var db = new BloggingContext())
{
    var strategy = db.Database.CreateExecutionStrategy();

    strategy.Execute(() =>
    {
        using (var transaction = db.Database.BeginTransaction())
        {
            db.Blogs.Add(new Blog { Url = "https://blogs.msdn.com/dotnet" });
            db.SaveChanges();

            db.Blogs.Add(new Blog { Url = "https://blogs.msdn.com/visualstudio" });
            db.SaveChanges();

            transaction.Commit();
        }
    });
}

تخزين Azure

تتضمن خدمات التخزين في Azure تخزين البيانات الثنائية الكبيرة والملفات وقوائم انتظار التخزين.

النقط، قوائم الانتظار والملفات

فئة ClientOptions هي النوع الأساسي لجميع أنواع خيارات العميل وتكشف العديد من خيارات العميل الشائعة مثل التشخيص وإعادة المحاولة والنقل. لتوفير خيارات تكوين العميل للاتصال بـ Azure Queue وBlob وFile Storage، يجب عليك استخدام النوع المشتق المقابل. في المثال التالي، يمكنك استخدام فئة QueueClientOptions (المشتقة من ClientOptions) لتكوين عميل للاتصال بخدمة Azure Queue Service. خاصية إعادة المحاولة هي مجموعة الخيارات التي يمكن تحديدها للتأثير على كيفية إجراء محاولات إعادة المحاولة، وكيف يكون الفشل مؤهلاً لإعادة المحاولة.

using System;
using System.Threading;
using Azure.Core;
using Azure.Identity;
using Azure.Storage;
using Azure.Storage.Queues;
using Azure.Storage.Queues.Models;

namespace RetryCodeSamples
{
    class AzureStorageCodeSamples {

        public async static Task Samples() {

               // Provide the client configuration options for connecting to Azure Queue Storage
                QueueClientOptions queueClientOptions = new QueueClientOptions()
                {
                    Retry = {
                    Delay = TimeSpan.FromSeconds(2),     //The delay between retry attempts for a fixed approach or the delay on which to base
                                                         //calculations for a backoff-based approach
                    MaxRetries = 5,                      //The maximum number of retry attempts before giving up
                    Mode = RetryMode.Exponential,        //The approach to use for calculating retry delays
                    MaxDelay = TimeSpan.FromSeconds(10)  //The maximum permissible delay between retry attempts
                    },

                    GeoRedundantSecondaryUri = new Uri("https://...")
                    // If the GeoRedundantSecondaryUri property is set, the secondary Uri will be used for GET or HEAD requests during retries.
                    // If the status of the response from the secondary Uri is a 404, then subsequent retries for the request will not use the
                    // secondary Uri again, as this indicates that the resource may not have propagated there yet.
                    // Otherwise, subsequent retries will alternate back and forth between primary and secondary Uri.
                };

                Uri queueServiceUri = new Uri("https://storageaccount.queue.core.windows.net/");
                string accountName = "Storage account name";
                string accountKey = "storage account key";

                // Create a client object for the Queue service, including QueueClientOptions.
                QueueServiceClient serviceClient = new QueueServiceClient(queueServiceUri, new DefaultAzureCredential(), queueClientOptions);

                CancellationTokenSource source = new CancellationTokenSource();
                CancellationToken cancellationToken = source.Token;

                // Return an async collection of queues in the storage account.
                var queues = serviceClient.GetQueuesAsync(QueueTraits.None, null, cancellationToken);

دعم الجدول

إشعار

تم إهمال حزمة Nuget ل WindowsAzure.Storage وحزمة Nuget Microsoft.Azure.Cosmos.Table. للحصول على دعم جدول Azure، راجع حزمة Nuget Azure.Data.Tables

آلية إعادة المحاولة

تستند مكتبة العميل إلى مكتبة Azure Core، وهي مكتبة توفر خدمات شاملة لمكتبات العملاء الأخرى.

هناك العديد من الأسباب التي تجعل الفشل يحدث عندما يحاول تطبيق عميل إرسال طلب شبكة إلى خدمة. بعض الأمثلة هي المهلة، وفشل البنية الأساسية للشبكة، ورفض الخدمة للطلب بسبب التقييد/الشغل، وإنهاء مثيل الخدمة بسبب تقليص حجم الخدمة، وتعطل مثيل الخدمة لاستبداله بإصدار آخر، وتعطل الخدمة بسبب استثناء غير معالج، وما إلى ذلك. من خلال تقديم آلية إعادة محاولة مضمنة (مع تكوين افتراضي يمكن للمستهلك تجاوزه)، تصبح SDKs الخاصة بنا وتطبيق المستهلك مرنين في مواجهة هذه الأنواع من الإخفاقات. لاحظ أن بعض الخدمات تفرض رسوما حقيقية على كل طلب وبالتالي يجب أن يكون المستهلكون قادرين على تعطيل عمليات إعادة المحاولة بالكامل إذا كانوا يفضلون توفير المال على المرونة.

تكوين النهج

يتم تكوين نهج إعادة المحاولة برمجياً. يستند التكوين إلى فئة RetryOption. هناك سمة على TableClientOptions موروثة من ClientOptions

      var tableClientOptions = new TableClientOptions();
      tableClientOptions.Retry.Mode = RetryMode.Exponential;
      tableClientOptions.Retry.MaxRetries = 5;
      var serviceClient = new TableServiceClient(connectionString, tableClientOptions);

تعرض الجداول التالية إمكانيات نهج إعادة المحاولة المضمنة.

إعادة المحاولةOption

الإعداد	معني
تأخير	التأخير بين محاولات إعادة المحاولة لنهج ثابت أو التأخير الذي تستند إليه العمليات الحسابية لنهج قائم على التراجع. إذا كانت الخدمة توفر عنوان استجابة Retry-After، فسيتم تأخير إعادة المحاولة التالية حسب المدة المحددة بواسطة قيمة العنوان.
MaxDelay	الحد الأقصى للتأخير المسموح به بين محاولات إعادة المحاولة عندما لا توفر الخدمة عنوان استجابة Retry-After. إذا كانت الخدمة توفر عنوان استجابة Retry-After، فسيتم تأخير إعادة المحاولة التالية حسب المدة المحددة بواسطة قيمة العنوان.
وضع	الأسلوب المستخدم لحساب تأخيرات إعادة المحاولة.
مهلة الشبكة	المهلة المطبقة على عمليات شبكة فردية.

إعادة المحاولة

الإعداد	معني
المتزايد	ستتأخر محاولات إعادة المحاولة استنادا إلى استراتيجية التراجع، حيث ستزيد كل محاولة من المدة التي تنتظرها قبل إعادة المحاولة.
MaxDelay	تحدث محاولات إعادة المحاولة على فترات زمنية ثابتة؛ كل تأخير هو مدة متناسقة.

القياس عن بعد

أبسط طريقة لرؤية السجلات هي تمكين تسجيل وحدة التحكم. لإنشاء مستمع سجل Azure SDK الذي يقوم بإخراج الرسائل إلى وحدة التحكم، استخدم أسلوب AzureEventSourceListener.CreateConsoleLogger.

      // Setup a listener to monitor logged events.
      using AzureEventSourceListener listener = AzureEventSourceListener.CreateConsoleLogger();

الأمثلة

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

using Azure.Core;
using Azure.Core.Diagnostics;
using Azure.Data.Tables;
using Azure.Data.Tables.Models;

namespace RetryCodeSamples
{
    class AzureStorageCodeSamples
    {
        private const string connectionString = "UseDevelopmentStorage=true";
        private const string tableName = "RetryTestTable";

        public async static Task SamplesAsync()
        {
            // Setup a listener to monitor logged events.
            using AzureEventSourceListener listener = AzureEventSourceListener.CreateConsoleLogger();

            var tableClientOptions = new TableClientOptions();
            tableClientOptions.Retry.Mode = RetryMode.Exponential;
            tableClientOptions.Retry.MaxRetries = 5;

            var serviceClient = new TableServiceClient(connectionString, tableClientOptions);

            TableItem table = await serviceClient.CreateTableIfNotExistsAsync(tableName);
            Console.WriteLine($"The created table's name is {table.Name}.");
        }
    }
}

إرشادات عامة بشأن REST وإعادة المحاولة

ضع في اعتبارك ما يلي عند الوصول إلى Azure أو خدمات الجهات الخارجية:

استخدم نهجاً منظماً لإدارة عمليات إعادة المحاولة، ربما كتعليمة برمجية قابلة لإعادة الاستخدام، بحيث يمكنك تطبيق منهجية متسقة عبر جميع العملاء وجميع الحلول.
ضع في اعتبارك استخدام إطار عمل لإعادة المحاولة مثل Polly لإدارة عمليات إعادة المحاولة إذا لم يكن لدى الخدمة الهدف أو العميل آلية إعادة محاولة مضمنة. سيساعدك هذا في تنفيذ سلوك إعادة محاولة متناسق، وقد يوفر إستراتيجية إعادة محاولة افتراضية مناسبة للخدمة المستهدفة. ومع ذلك، قد تحتاج إلى إنشاء تعليمة برمجية مخصصة لإعادة المحاولة للخدمات التي لها سلوك غير قياسي لا تعتمد على استثناءات للإشارة إلى حالات فشل عابرة أو إذا كنت تريد استخدام رد إعادة المحاولة-الاستجابة لإدارة سلوك إعادة المحاولة.
سيعتمد منطق الكشف العابر على العميل الفعلي API الذي تستخدمه لاستدعاء مكالمات REST. لن يطرح بعض العملاء، مثل فئة HttpClient الأحدث، استثناءات للطلبات المكتملة مع رمز حالة HTTP غير ناجح.
يمكن أن تساعد تعليمة برمجية لحالة HTTP التي تم إرجاعها من الخدمة في توضيح ما إذا كان الفشل مؤقتاً أم لا. قد تحتاج إلى فحص الاستثناءات التي تم إنشاؤها بواسطة العميل أو إطار عمل إعادة المحاولة للوصول إلى تعليمة برمجية للحالة أو لتحديد نوع الاستثناء المكافئ. تشير أكواد HTTP التالية عادةً إلى أن إعادة المحاولة مناسبة:
- 408 انتهي وقت الطلب
- 429 عدد كبير جداً من الطلبات
- 500 خطأ داخلي بالخادم
- 502 بوابة غير صالحة
- 503 خدمة غير متاحة
- البوابة 504 انتهى الزمن
إذا بنيت منطق إعادة المحاولة على استثناءات، فإن ما يلي عادةً يشير إلى فشل عابر حيث لا يمكن إنشاء اتصال:
- WebExceptionStatus.ConnectionClosed
- WebExceptionStatus.ConnectFailure
- WebExceptionStatus.Timeout
- WebExceptionStatus.RequestCanceled
في حال عدم توفر الخدمة، قد تشير الخدمة إلى التأخير المناسب قبل إعادة المحاولة في رأس استجابة إعادة المحاولة بعد أو رأس مخصص مختلف. قد ترسل الخدمات أيضاً معلومات إضافية كرؤوس مخصصة، أو مضمنة في محتوى الاستجابة.
لا تحاول إعادة محاولة رموز الحالة التي تمثل أخطاء العميل (أخطاء في نطاق 4xx) باستثناء مهلة طلب 408 و429 طلبات كثيرة جدا.
اختبر بدقة إستراتيجيات وآليات إعادة المحاولة الخاصة بك في ظل مجموعة من الظروف، مثل حالات الشبكة المختلفة وتحميلات النظام المختلفة.

إستراتيجيات إعادة المحاولة

فيما يلي الأنواع النموذجية لفترات إستراتيجية إعادة المحاولة:

أسي. نهج إعادة المحاولة الذي ينفذ عدداً محدداً من عمليات إعادة المحاولة، باستخدام أسلوب التراجع الأسي العشوائي لتحديد الفاصل الزمني بين عمليات إعادة المحاولة. على سبيل المثال:

var random = new Random();

var delta = (int)((Math.Pow(2.0, currentRetryCount) - 1.0) *
            random.Next((int)(this.deltaBackoff.TotalMilliseconds * 0.8),
            (int)(this.deltaBackoff.TotalMilliseconds * 1.2)));
var interval = (int)Math.Min(checked(this.minBackoff.TotalMilliseconds + delta),
                this.maxBackoff.TotalMilliseconds);
retryInterval = TimeSpan.FromMilliseconds(interval);

تزايدي. إستراتيجية إعادة المحاولة مع عدد محدد من محاولات إعادة المحاولة وفاصل زمني تزايدي بين عمليات إعادة المحاولة. على سبيل المثال:
```
retryInterval = TimeSpan.FromMilliseconds(this.initialInterval.TotalMilliseconds +
                (this.increment.TotalMilliseconds * currentRetryCount));
```
LinearRetry. نهج إعادة المحاولة الذي ينفذ عدداً محدداً من عمليات إعادة المحاولة، باستخدام فترة زمنية محددة بين عمليات إعادة المحاولة. على سبيل المثال:
```
retryInterval = this.deltaBackoff;
```

التعامل مع خطأ عابر مع بولي

Polly هي مكتبة تعالج برمجياً عمليات إعادة المحاولة وإستراتيجيات قاطع الدائرة. مشروع Polly عضو في .NET Foundation. بالنسبة للخدمات التي لا يدعم فيها العميل عمليات إعادة المحاولة أصلا، تعد Polly بديلا صالحا وتتجنب الحاجة إلى كتابة التعليمات البرمجية المخصصة لإعادة المحاولة، والتي قد يكون من الصعب تنفيذها بشكل صحيح. يوفر Polly أيضاً طريقة لتتبع الأخطاء عند حدوثها، بحيث يمكنك تسجيل عمليات إعادة المحاولة.

Share via

أعد محاولة التوجيه لخدمات Azure

Microsoft Entra ID

آلية إعادة المحاولة

أعد محاولة إرشادات الاستخدام

الخطوات التالية

Azure Cosmos DB

آلية إعادة المحاولة

القياس عن بعد

Data Lake Store

آلية إعادة المحاولة

القياس عن بعد

مراكز الأحداث

آلية إعادة المحاولة

مثال

الخطوات التالية

IoT Hub

آلية إعادة المحاولة

تكوين النهج

الخطوات التالية

ذاكرة التخزين المؤقت في Azure لـ Redis

آلية إعادة المحاولة

تكوين النهج

أعد محاولة إرشادات الاستخدام

القياس عن بعد

الأمثلة

الخطوات التالية

Azure Search

آلية إعادة المحاولة

القياس عن بعد

ناقل الخدمة

آلية إعادة المحاولة

أعد محاولة إرشادات الاستخدام

القياس عن بعد

مثال

الخطوات التالية

Service Fabric

الخطوات التالية

SQL Database باستخدام ADO.NET

آلية إعادة المحاولة

أعد محاولة إرشادات الاستخدام

الأمثلة

الخطوات التالية

SQL Database باستخدام Entity Framework 6

آلية إعادة المحاولة

تكوين النهج

أعد محاولة إرشادات الاستخدام

الأمثلة

SQL Database باستخدام Entity Framework Core

آلية إعادة المحاولة

الأمثلة

تخزين Azure

النقط، قوائم الانتظار والملفات

دعم الجدول

آلية إعادة المحاولة

تكوين النهج

إعادة المحاولة

القياس عن بعد

الأمثلة

إرشادات عامة بشأن REST وإعادة المحاولة

إستراتيجيات إعادة المحاولة

التعامل مع خطأ عابر مع بولي

الخطوات التالية

الملاحظات

الملاحظات

الموارد الإضافية