Sdílet prostřednictvím

Okamžité a zpožděné potvrzení

  • Článek

V tomto článku se dozvíte o rozdílech mezi okamžitým a zpožděným potvrzením.

Okamžité potvrzení

U mnoha aplikací chceme zajistit, aby se události potvrdily okamžitě, aby trvalá verze nezaostala za aktuální verzí v paměti a neriskujeme ztrátu nejnovějšího stavu, pokud by se mělo agregační interval nezdařit. Můžeme to zaručit následujícími pravidly:

  1. Potvrďte všechna RaiseEvent volání, která se používají ConfirmEvents před vrácením metody agregačního intervalu.
  2. Před vrácením RaiseConditionalEvent metody agregační metody se ujistěte, že úkoly vrácené dokončením.
  3. Vyhněte se ReentrantAttribute nebo AlwaysInterleaveAttribute atributům, takže je možné zpracovat pouze jedno volání agregačního intervalu.

Pokud tato pravidla dodržujeme, znamená to, že po vyvolání události se žádný jiný kód agregačního intervalu nespustí, dokud se událost nezapíše do úložiště. Proto není možné pozorovat nekonzistence mezi verzí v paměti a verzí v úložišti. I když je to často přesně to, co chceme, má také určité potenciální nevýhody.

Potenciální nevýhody

  • Pokud je připojení ke vzdálenému clusteru nebo úložišti dočasně přerušeno, pak se agregační interval stane nedostupným: agregační interval nemůže v podstatě spustit žádný kód, zatímco čeká na potvrzení událostí, což může trvat neomezenou dobu (protokol konzistence protokolu se opakuje, dokud se připojení k úložišti neobnoví).

  • Při zpracování velkého množství aktualizací instance s jedním agregačním intervalem může být potvrzení, že jeden po druhém může být velmi neefektivní, například způsobuje nízkou propustnost.

Zpožděné potvrzení

Pokud chcete zlepšit dostupnost a propustnost v situacích uvedených výše, můžete se rozhodnout provést jednu nebo obě z těchto věcí:

  • Povolte metodám agregace vyvolání událostí bez čekání na potvrzení.
  • Povolte opakované zařazení, takže zrno může pokračovat ve zpracování nových volání, i když se předchozí volání zablokují a čekají na potvrzení.

To znamená, že se může spustit odstupňovaný kód, zatímco některé události jsou stále v procesu potvrzení. Rozhraní JournaledGrain<TGrainState,TEventBase> API obsahuje určitá ustanovení, která vývojářům umožňují přesnou kontrolu nad tím, jak řešit nestvrzené události, které jsou aktuálně spuštěné.

Následující vlastnost je možné prozkoumat a zjistit, které události jsou aktuálně nepotvrzené:

IEnumerable<EventType> UnconfirmedEvents { get; }

Vzhledem k tomu, že stav vrácený JournaledGrain<TGrainState,TEventBase>.State vlastností nezahrnuje účinek nepotvrzených událostí, existuje alternativní vlastnost.

StateType TentativeState { get; }

Který vrátí "nezávazný" stav získaný ze "State" použitím všech nepotvrzených událostí. Nezávazný stav je v podstatě "nejlepší odhad" toho, co se pravděpodobně stane dalším potvrzeným stavem po potvrzení všech nepotvrzených událostí. Neexistuje však žádná záruka, že skutečně bude, protože zrno může selhat, nebo protože události mohou závodit proti jiným událostem a ztrátě, což způsobí, že je zruší (pokud jsou podmíněné) nebo se objeví v pozdější pozici v pořadí, než se čekalo (pokud jsou nepodmíněné).

Záruky souběžnosti

Mějte na paměti, že Orleans plánování založené na spolupráci (souběžnost) vždy platí, i když používáte opakované nebo zpožděné potvrzení. To znamená, že i když může probíhat několik metod, může se aktivně spouštějí jenom jedna – všechny ostatní jsou zablokované na čekání, takže nikdy nejsou žádné skutečné rasy způsobené paralelními vlákny.

Zejména mějte na paměti, že:

Tyto záruky předpokládají, že uživatelský kód zůstává v doporučeném postupu týkajícím se úkolů a asynchronní/await (zejména nepoužívá úlohy fondu vláken, nebo je používá pouze pro kód, který nevolá odstupňované funkce a které jsou správně očekávány).