Sync.Map wykorzystuje architekturę podwójnej mapy, aby zminimalizować kontencję między czytelnikami a pisarzami dzięki starannej separacji operacji bez blokad i blokowanych. Struktura utrzymuje atomowy wskaźnik do mapy tylko do odczytu (read), która przechowuje wpisy jako atomowe wskaźniki do struktur entry, co umożliwia bezblokowe wyszukiwania, gdy klucze istnieją w tej warstwie. W przypadku zapisów lub nieudanych wyszukiwań w mapie do odczytu, następuje powrót do mapy dirty, chronionej przez mutex, która zawiera superset kluczy, w tym ostatnie zapisy. Krytyczna heurystyka promocyjna reguluje przejście między tymi warstwami: kiedy atomowy licznik misses (śledzący nieudane wyszukiwania w read) przekracza długość mapy dirty, runtime atomowo promuje całą brudną mapę na nową mapę do odczytu.
Wewnętrzna implementacja używa wyspecjalizowanych struktur, aby umożliwić te atomowe operacje:
type readOnly struct { m map[any]*entry amended bool // prawda, jeśli brudna zawiera klucze, które nie są w odczycie } type entry struct { p atomic.Pointer[any] // rzeczywista wartość lub nil, jeśli usunięta }
Te struktury pozwalają runtime'owi atomowo wymieniać mapy, zachowując bezpieczny dostęp dla równoległych goroutines, a próg promocyjny zapewnia, że koszt podwójnych wyszukiwań pozostaje amortyzowany na przestrzeni wielu dostępów.
Nasz zespół systemów rozproszonych napotkał poważne szczyty opóźnień w usłudze metadanych o wysokiej przepustowości obsługującej ponad 100k QPS. Usługa buforowała obiekty konfiguracji indeksowane według UUID, z 95% ruchu trafiającego na 5% gorących kluczy, podczas gdy tła goroutines nieustannie dodawały nowe konfiguracje dla nowo wdrożonych usług.
Rozwiązanie 1: sync.RWMutex z mapą
Początkowa implementacja wykorzystywała standardową mapę chronioną przez sync.RWMutex. Chociaż koncepcyjnie prosta, to podejście cierpiało z powodu ciężkiej kontencji pod dużym obciążeniem, ponieważ wszystkie goroutines czytające konkurowały o linie pamięci w słowie stanu wewnętrznego mutexu. Kiedy tła pisarze przejmowali blokadę do zapisu, aby dodać nowe konfiguracje, wszyscy czytelnicy byli blokowani, co powodowało skoki p99 latencji przekraczające 500 ms podczas cykli odświeżania pamięci podręcznej.
Rozwiązanie 2: Podejście z zadaniami mutex
Następnie zaprojektowaliśmy prototypowane mapy z zadaniami, używając 256 instancji sync.RWMutex z rozkładem kluczy opartym na hash. Ten projekt zredukował kontencję, rozprzestrzeniając obciążenie na różne linie pamięci i oddzielne mutexy. Jednak wprowadził znaczną złożoność w utrzymaniu spójnego haszowania podczas zmiany rozmiaru, a nieuchronne gorące klucze stworzyły niezrównoważone fragmenty, które nadal cierpiały na szczyty latencji ogonowej.
Rozwiązanie 3: sync.Map
Ostatecznie przyjęliśmy sync.Map po profilowaniu, które potwierdziło różne wzorce dostępu: odczyty dotyczyły stabilnych, długoterminowych kluczy, podczas gdy zapisy wprowadzały efemeryczne nowe klucze. Atomowe ładowania bez blokad na ścieżce do odczytu całkowicie wyeliminowały zalania liniami pamięci, a automatyczna heurystyka promocyjna była zoptymalizowana dla naszych konkretnych charakterystyk obciążenia roboczego. Chociaż jednowątkowa przepustowość była około 20% niższa niż w zwykłej mapie, eliminacja kontencji mutexu zredukowała latencję p99 do poniżej 5 ms podczas dużych impulsów zapisu.
Wdrożenie przyniosło 100x poprawę stabilności latencji ogonowej i całkowicie wyeliminowało zatory goroutine podczas odświeżania konfiguracji. Dostępność usługi wzrosła z 99,9% do 99,99% w okresach szczytowego ruchu, a my nie zaobserwowaliśmy żadnych wycieków pamięci przez okres miesięczny.
*Dlaczego sync.Map przechowuje wartości jako wskaźniki entry, a nie jako bezpośrednie wartości interface{}, i jak to umożliwia usuwanie bez blokad?
Mapa read przechowuje struktury *entry, a nie surowe wartości interface{}, aby umożliwić usuwanie bez blokad bez modyfikacji struktury mapy. Gdy usuwany jest klucz, sync.Map atomowo wymienia wewnętrzny wskaźnik wpisu na nil za pomocą atomowych operacji porównania i zamiany, oznaczając slot jako pusty, pozostawiając jednocześnie wpis w mapie nienaruszonym. Ta niezmienność struktury mapy tylko do odczytu podczas usuwania pozwala równoległym czytelnikom działać bez blokad, chociaż oznacza to, że usunięte klucze zużywają pamięć do czasu, gdy następny cykl promocyjny je usunie.
Jak sync.Map określa, kiedy promować brudną mapę na odczyt, i dlaczego ten konkretne próg jest istotny dla wydajności?
Promocja ma miejsce, gdy atomowy licznik misses, inkrementowany podczas nieudanych wyszukiwań w mapie tylko do odczytu, przekracza długość mapy dirty. Ten próg zapewnia, że koszt kar za podwójne wyszukiwania przewyższa koszt skopiowania całej mapy dirty do atomowego wskaźnika read. Po aktywacji brudna mapa jest atomowo promowana do odczytu, brudna mapa jest ustawiana na nil, a missy są resetowane na zero, efektywnie amortyzując koszt promocji na wielu nieudanych wyszukiwaniach.
Jaki mechanizm pozwala równoległym czytelnikom kontynuować działanie podczas atomowej promocji brudnej mapy do odczytu, nie obserwując częściowo zaktualizowanych stanów mapy?
Podczas promocji kod wykonuje atomowe wymiany wskaźnika pola read, aby wskazywał na wcześniejszą mapę dirty, co model pamięci Go gwarantuje, że widoczne jest atomowo dla wszystkich goroutines. Równolegli czytelnicy obserwują albo starą mapę read, albo nową promowaną mapę, ale nigdy nie widzą nieprawidłowego lub częściowo skonstruowanego stanu, ponieważ przypisania mapy zostały zakończone przed wymianą wskaźnika. Stara mapa read pozostaje osiągalna dla czytelników w trakcie, dzięki zbieraczowi śmieci Go, który przejmie ją dopiero po usunięciu wszystkich odniesień, co pokazuje, jak sync.Map wykorzystuje zbieranie śmieci do bezblokowych przejść strukturalnych.