Když předplatitel (spotřebitel) zemře, váš seznam se bude dále rozrůstat, dokud se klient nevrátí. Váš výrobce by mohl seznam zkrátit (z obou stran), jakmile dosáhne určitého limitu, ale to je něco, co byste museli zvládnout na úrovni aplikace. Pokud do každé zprávy zahrnete časové razítko, váš spotřebitel pak může jednat podle stáří zprávy za předpokladu, že máte aplikační logiku, kterou chcete prosadit na stáří zprávy.
Nejsem si jistý, jak by se chybná zpráva dostala do systému, protože připojení k Redis je obvykle TCP s jeho zárukami integrity. Ale pokud k tomu dojde, možná kvůli chybě v kódování zpráv na vrstvě producenta, můžete poskytnout obecný mechanismus pro zpracování chyb tím, že budete udržovat frontu na producenta, který přijímal zprávy o výjimkách spotřebitele.
Zásady opakování budou do značné míry záviset na potřebách vaší aplikace. Pokud potřebujete 100% jistotu, že zpráva byla přijata a zpracována, měli byste zvážit použití transakcí Redis (MULTI/EXEC) k zabalení práce provedené spotřebitelem, abyste mohli zajistit, že klient zprávu neodstraní, pokud dokončilo své dílo. Pokud potřebujete explicitní potvrzení, můžete použít explicitní zprávu ACK ve frontě vyhrazené pro proces(y) producenta.
Bez znalosti potřeb vaší aplikace je těžké vědět, jak si vybrat moudře. Obecně platí, že pokud vaše zprávy vyžadují plnou ACID ochranu, pak pravděpodobně také budete muset použít transakce redis. Pokud jsou vaše zprávy smysluplné pouze tehdy, když jsou včasné, transakce nemusí být potřeba. Zní to, jako byste nemohli tolerovat vynechané zprávy, takže váš přístup k používání seznamu je dobrý. Pokud potřebujete implementovat prioritní frontu pro své zprávy, můžete použít seřazenou sadu (příkazy Z) k uložení zpráv, přičemž jejich prioritu použijete jako hodnotu skóre spolu se spotřebitelem dotazování.