Twoje obciążenie Redis przerosło możliwości pojedynczego węzła. Musisz skalować horyzontalnie i nadal wykonywać operacje na wielu kluczach, takie jak MGET, na powiązanych kluczach (na przykład, koszyk i użytkownik dla tego samego klienta). Co powinieneś zrobić?

Prawidłowa odpowiedź to utworzenie klastra Azure Cache for Redis z wieloma shardami i użycie hashtagów w nazwach kluczy. Klastrowanie Redis pozwala na horyzontalne skalowanie, rozdzielając dane między wiele shardów. Hashtagi (np. {123}) zapewniają, że powiązane klucze (np. cart:{123} i user:{123}) są przechowywane w tym samym slocie haszującym, co umożliwia wykonywanie operacji na wielu kluczach (takich jak MGET) atomowo w ramach jednego sharda. Skalowanie w górę (większa pamięć podręczna bez klastra) nie rozwiązuje problemu przekroczenia możliwości pojedynczego węzła i nie zapewnia horyzontalnego skalowania. Rozdzielanie kluczy w trybie round-robin między wiele połączeń klienta w pamięci podręcznej bez klastra nie pozwala na wykonywanie operacji na wielu kluczach, ponieważ klucze mogą znajdować się na różnych serwerach. Replikacja geograficzna Premium służy do odzyskiwania po awarii i globalnej dystrybucji danych, a nie do horyzontalnego skalowania pojedynczego obciążenia w ramach jednego regionu, ani nie rozwiązuje problemu operacji na wielu kluczach.