Unieważnienie stosu przepełnienia, numeru Redis i pamięci podręcznej

Question

Teraz, gdy przepełnienie stosu używa redis, czy one obsługują unieważnianie pamięci podręcznej w ten sam sposób? tj. listę tożsamości przypisaną do ciągu zapytania + nazwy (domyślam się, że nazwa jest rodzajem celu lub nazwy typu obiektu).

Być może następnie pobierają pojedyncze pozycje, których brakuje w pamięci podręcznej bezpośrednio przez id (które pomijają kilka indeksów baz danych i zamiast tego używa bardziej wydajnego indeksu klastrowego). To byłoby mądre (rehydratacja, o której wspomina Jeff?).

W tej chwili staram się znaleźć sposób, aby to wszystko obrócić w zwięzły sposób. Czy są jakieś przykłady tego rodzaju rzeczy, które mógłbym wykorzystać, aby pomóc w wyjaśnieniu mojego myślenia przed dokonaniem pierwszego cięcia osobiście?

Zastanawiam się również, gdzie znajduje się granica między używaniem pamięci podręcznej .net (System.Runtime.Caching lub System.Web.Caching) a wyjściem i użyciem redis. A może Redis po prostu odkłada ręce szybciej?

Oto oryginalny SO pytanie z 2009 roku:

https://meta.stackexchange.com/questions/6435/how-does-stackoverflow-handle-cache-invalidation

Kilka innych linków:

https://meta.stackexchange.com/questions/69164/does-stackoverflow-use-caching-and-if-so-how/69172#69172

https://meta.stackexchange.com/questions/110320/stack-overflow-db-performance-and-redis-cache

Answer 1

Szczerze nie mogę zdecydować, czy jest to pytanie SO lub pytanie MSO, ale:

Przejście do innego systemu to nigdy nie jest szybsze niż wysyłanie zapytań do pamięci lokalnej (o ile jest pod kluczem); prosta odpowiedź: używamy obu! Więc używamy:

• pamięci lokalnej
• indziej Redis wyboru i zaktualizować lokalną pamięć
• inny pobrać ze źródła i zaktualizuj Redis i pamięć lokalna

To wtedy, jak mówisz, powoduje problem z unieważnieniem pamięci podręcznej - chociaż w większości miejsc to nie jest krytyczne. Ale do tego - zdarzenia redis (pub/sub) pozwalają na łatwy sposób nadawania kluczy, które zmieniają się we wszystkich węzłach, dzięki czemu mogą zrzucić swoją lokalną kopię - co oznacza: następnym razem, kiedy będzie potrzebna, wyślemy nową kopię z redis . Dlatego nadawane są nazwy kluczy, które zmieniają się pod nazwą jednego kanału zdarzeń.

Narzędzia: redis na serwerze Ubuntu; BookSleeve jako opakowanie redis; protobuf-net i GZipStream (włączane/wyłączane automatycznie w zależności od rozmiaru) dla danych opakowania.

Więc: pub Redis/sub zdarzenia są wykorzystywane do unieważnienia pamięci podręcznej dla danego klucza z jeden węzła (ten, który zna stan uległ zmianie) natychmiast (dość dużo) do wszystkich węzłów.

Odnośnie różnych procesów (z komentarzy, "czy używasz dowolnego modelu współużytkowanej pamięci dla wielu różnych procesów zasilających te same dane?"): Nie, nie robimy tego. Każda skrzynka warstwowa obsługuje tylko jeden proces (dowolnej warstwy), z wieloma dzierżawcami w ramach, więc w ramach tego samego procesu możemy mieć 70 witryn. Ze względu na starsze wersje (tj."działa i nie wymaga naprawy") używamy głównie pamięci podręcznej http z identyfikacją strony jako częścią klucza.

W przypadku kilku masywnie obciążających dane części systemu mamy mechanizmy utrzymujące się na dysku, dzięki czemu model w pamięci może być przekazywany między kolejnymi domenami aplikacji, ponieważ sieć naturalnie przetwarza (lub jest ponownie wdrażana) , ale to nie ma związku z redis.

Oto powiązanym przykładem, który pokazuje tylko, jak to może działać na szeroki smak - rozpędzają się liczbę wystąpień następujących czynności, a następnie wpisać kilka kluczowych nazwisk w:

static class Program 
{ 
    static void Main() 
    { 
     const string channelInvalidate = "cache/invalidate"; 
     using(var pub = new RedisConnection("127.0.0.1")) 
     using(var sub = new RedisSubscriberConnection("127.0.0.1")) 
     { 
      pub.Open(); 
      sub.Open(); 

      sub.Subscribe(channelInvalidate, (channel, data) => 
      { 
       string key = Encoding.UTF8.GetString(data); 
       Console.WriteLine("Invalidated {0}", key); 
      }); 
      Console.WriteLine(
        "Enter a key to invalidate, or an empty line to exit"); 
      string line; 
      do 
      { 
       line = Console.ReadLine(); 
       if(!string.IsNullOrEmpty(line)) 
       { 
        pub.Publish(channelInvalidate, line); 
       } 
      } while (!string.IsNullOrEmpty(line)); 
     } 
    } 
} 

co należy zobacz, że po wpisaniu nazwy klucza jest ona wyświetlana natychmiast we wszystkich działających instancjach, co spowoduje zrzucenie ich lokalnej kopii tego klucza. Oczywiście w prawdziwym użyciu te dwa połączenia musiałyby być gdzieś umieszczone i pozostawione otwarte, tak by były nie w instrukcjach . Używamy do tego prawie-singletonu.