Megosztás a következőn keresztül:

Irányelvek és javaslatok az Azure Service Fabric megbízható gyűjteményeihez

  • Cikk

Ez a szakasz útmutatást nyújt a Reliable State Manager és a Reliable Collections használatához. A cél az, hogy segítsen a felhasználóknak elkerülni a gyakori buktatókat.

Reliable Collection guildelines

Az irányelvek egyszerű javaslatokként vannak rendszerezve, amelyek a Do, a Consider, az Avoid és a Do(ne) kifejezéssel vannak előtagban.

  • Ne módosítsa az olvasási műveletek által visszaadott egyéni típusú objektumokat (például TryPeekAsyncTryGetValueAsync). A megbízható gyűjtemények, csakúgy, mint az egyidejű gyűjtemények, az objektumokra mutató hivatkozást ad vissza, nem pedig egy másolatot.
  • A módosítás előtt végezze el az egyéni típusú visszaadott objektum részletes másolását. Mivel a szerkezetek és a beépített típusok értékenkéntiek, nem kell mély másolatot készítenie róluk, hacsak nem tartalmaznak módosítani kívánt referencia típusú mezőket vagy tulajdonságokat.
  • Ne használja TimeSpan.MaxValue időtúllépéshez. A holtpontok észleléséhez időtúllépéseket kell használni.
  • Ne használjon tranzakciót a véglegesítést, megszakítást vagy elidegenítést követően.
  • Ne használjon számbavételt a létrehozott tranzakció hatókörén kívül.
  • Ne hozzon létre tranzakciót egy másik tranzakció utasításában using , mert az holtpontot okozhat.
  • Ne hozzon létre megbízható állapotot IReliableStateManager.GetOrAddAsync ugyanabban a tranzakcióban, és ne használja a megbízható állapotot. Ez egy InvalidOperationException eredményt ad.
  • Győződjön meg arról, hogy a IComparable<TKey> megvalósítás helyes. A rendszer függőséget vesz fel IComparable<TKey> az ellenőrzőpontok és sorok egyesítéséhez.
  • A frissítési zárolást akkor használja, ha olyan elemet olvas, amelynek célja a frissítés, hogy megakadályozza a holtpontok egy bizonyos osztályát.
  • Fontolja meg, hogy a megbízható gyűjtemények száma partíciónként 1000-nél kevesebb legyen. Inkább megbízható gyűjteményeket részesítsen előnyben, amelyek több elemet használnak a több, kevesebb elemből rendelkező megbízható gyűjtemények helyett.
  • Fontolja meg, hogy az elemeket (például a TKey + TValue for Reliable Dictionary) 80 KByte alatt tartsa: minél kisebb, annál jobb. Ez csökkenti a nagyméretű objektum halomhasználatát, valamint a lemez- és hálózati I/O-követelményeket. Gyakran csökkenti a duplikált adatok replikálását, ha az értéknek csak egy kis része frissül. Ennek a Reliable Dictionaryben való elérésének gyakori módja, ha a sorokat több sorra bontja.
  • Fontolja meg a biztonsági mentési és visszaállítási funkciók használatát a vészhelyreállításhoz.
  • A különböző elkülönítési szintek miatt kerülje az egyetlen entitásműveletek és a többentitásos műveletek (pl GetCountAsync. , CreateEnumerableAsync) keverését ugyanabban a tranzakcióban.
  • Kezelje az InvalidOperationException parancsot. A felhasználói tranzakciókat a rendszer számos okból megszakíthatja. Ha például a Reliable State Manager nem elsődlegesként módosítja a szerepkörét, vagy ha egy hosszú ideig futó tranzakció blokkolja a tranzakciós napló csonkolását. Ilyen esetekben előfordulhat, hogy a felhasználó az InvalidOperationException azonosítót kapja, amely jelzi, hogy a tranzakciója már le lett állítva. Feltételezve, hogy a tranzakció befejezését nem kérte a felhasználó, a kivétel kezelésére a legjobb módszer a tranzakció elvetése, a lemondási jogkivonat jelzésének ellenőrzése (vagy a replika szerepkörének módosítása), és ha nem hoz létre új tranzakciót, és próbálkozzon újra.
  • Ne alkalmazzon párhuzamos vagy egyidejű műveleteket egy tranzakción belül. A tranzakción belül csak egy felhasználóiszál-művelet támogatott. Ellenkező esetben memóriavesztést és zárolási problémákat fog okozni.
  • A véglegesítés befejezése után (különösen a ConcurrentQueue használata esetén) érdemes a lehető leghamarabb elidegeníteni a tranzakciót.
  • Ne végezzen blokkolási kódot egy tranzakción belül.
  • Ha egy megbízható szótár kulcsaként sztringet használ, a rendezési sorrend az alapértelmezett CurrentCulture sztring-összehasonlítót használja. Vegye figyelembe, hogy a CurrentCulture rendezési sorrendje eltér az ordinális sztring-összehasonlítótól.
  • A véglegesítési tranzakciót ne dobja el vagy mondja le. Ez nem támogatott, és összeomlhat a gazdagépfolyamat.
  • A holtpont elkerülése érdekében ügyeljen arra, hogy a különböző szótárak műveleti sorrendje azonos maradjon az egyidejű tranzakciók esetében, ha több szótárat olvas vagy ír.

Íme néhány dolog, amit szem előtt kell tartani:

  • Az alapértelmezett időtúllépés 4 másodperc az összes Reliable Collection API esetében. A felhasználók többsége az alapértelmezett időtúllépést használja.
  • Az alapértelmezett lemondási jogkivonat az összes Reliable Collections API-ban található CancellationToken.None .
  • A Reliable Dictionary kulcstípusparaméterének (TKey) megfelelően kell implementálnia és Equals()implementálniaGetHashCode(). A kulcsnak nem módosíthatónak kell lennie.
  • A megbízható gyűjtemények magas rendelkezésre állásának eléréséhez minden szolgáltatásnak legalább 3-as cél- és minimális replikakészlet-mérettel kell rendelkeznie.
  • A másodlagos olvasási műveletek olyan verziókat olvashatnak, amelyek nem kvórum-véglegesítettek. Ez azt jelenti, hogy az egyetlen másodlagosról beolvasott adatok egy verziója hamis állapotú lehet. Az elsődlegesből származó olvasások mindig stabilak: soha nem lehet hamis előrehaladást elérni.
  • Az alkalmazás által megbízható gyűjteményben tárolt adatok biztonsága/védelme az Ön döntése, és a tároláskezelés által biztosított védelemre vonatkozik; Az operációs rendszer lemeztitkosítása használható az inaktív adatok védelmére.
  • ReliableDictionary Az enumerálás kulcs szerint rendezett adatstruktúrát használ. A számbavétel hatékonyabbá tétele érdekében a véglegesítések egy ideiglenes kivonatolóhoz lesznek hozzáadva, majd később átkerülnek a fő rendezett adatstruktúrába az ellenőrzőpont után. Az adds/Frissítések/Deletes esetében az O(1) és a legrosszabb esetben az O(log n) futásideje a legjobb, ha a kulcs meglétét ellenőrzi az ellenőrzés. A lekérés O(1) vagy O(log n) lehet attól függően, hogy egy legutóbbi véglegesítésből vagy egy régebbi véglegesítésből olvas.

További irányelvek az illékony reliable collectionshez

Az illékony megbízható gyűjtemények használata során vegye figyelembe a következőket:

  • ReliableDictionary nem rendelkezik ingadozó támogatással
  • ReliableQueue nem rendelkezik ingadozó támogatással
  • ReliableConcurrentQueue nem rendelkezik ingadozó támogatással
  • A fenntartott szolgáltatások nem tehetők volatilissé. Ha úgy módosítja a HasPersistedState jelzőt, hogy false a teljes szolgáltatást újra kell újraépíteni az alapoktól
  • A volatilis szolgáltatások nem tárolhatók. Ha úgy módosítja a HasPersistedState jelzőt, hogy true a teljes szolgáltatást újra kell újraépíteni az alapoktól
  • HasPersistedState szolgáltatásszintű konfiguráció. Ez azt jelenti, hogy az ÖSSZES gyűjtemény megmarad vagy változékony lesz. Az illékony és a tartós gyűjtemények nem keverhetők össze
  • A változó partíció kvórumvesztesége teljes adatvesztést eredményez
  • A biztonsági mentés és a visszaállítás nem érhető el a változó szolgáltatásokhoz

Következő lépések