Odpowiedź.

Dla skalowalnego cache'owania w rozproszonych systemach IT warto używać rozproszonych cache'y (Redis Cluster, Memcached Cluster). Obsługują one sharding, replikację i mogą dynamicznie balansować obciążenie między węzłami.

Warstwa cache jest realizowana na neutralnym API klienta. Przy zmianie obciążenia w klastrze automatycznie dodawane lub usuwane są węzły (automatyczne skalowanie).

Przykład: dynamicznie dostosowujący się Redis Cluster z wykorzystaniem klienta, który automatycznie odkrywa nowe węzły.

import rediscluster
rc = rediscluster.RedisCluster(startup_nodes=[{"host": "127.0.0.1", "port": "7000"}])
rc.set('key', 'value')

Kluczowe cechy:

• Poziome skalowanie klastra bez przestojów
• Możliwość ustawienia TTL, usuwania i replikacji na poziomie cache
• Natywne wsparcie dla mechanizmów rozkładu (consistent hashing)

Pytania z podtekstem.

Czy Memcached w trybie klastra zapewnia odporność na awarię węzła z zachowaniem danych?

Nie. Memcached nie zachowuje danych przy restarcie lub awarii węzła. Dla persystencji lepiej używać Redis.

Czy można cachować dane, które zmieniają się bardzo często (na przykład, o czasie życia < 1 sekundy)?

To jest nieefektywne — zarządzanie starymi wersjami będzie trudniejsze, często lepiej w ogóle nie cachować takich obiektów.

Czy nieprawidłowy cache (stale cache) wpłynie na integralność danych?

Może wpłynąć. Należy zrealizować mechanizm wymuszającej unieważnienia (na przykład, przez pub/sub lub mechanizm zdarzeń), aby zmniejszyć ryzyko niesynchronizacji.