Sync.Mapは、ロックフリーとロックされた操作の適切な分離を通じて、リーダーとライター間の競合を最小限に抑えるために設計されたデュアルマップアーキテクチャを採用しています。この構造は、エントリをentry構造体への原子的なポインタとして格納する読み取り専用マップ（read）への原子的なポインタを保持しており、これはこのレイヤーにキーが存在する場合のロックフリー検索を可能にします。読み取りマップでの書き込みやキャッシュミスの場合、最近の書き込みを含むスーパーセットのキーを持つミューテックス保護されたdirtyマップにフォールバックします。これらのレイヤー間の遷移を管理する重要な昇格ヒューリスティックは、原子的なmissesカウンタ（read内の失敗した検索を追跡）がdirtyマップの長さを超えたときに発動し、ランタイムは全体のダーティマップを新しい読み取りマップとして原子的に昇格させます。
内部実装は、これらの原子的な操作を可能にするための特化した構造を使用しています：
type readOnly struct { m map[any]*entry amended bool // 読み取りにないキーがダーティに含まれている場合はtrue } type entry struct { p atomic.Pointer[any] // 実際の値、または削除された場合はnil }
これらの構造は、ランタイムがマップを原子的にスワップすることを可能にし、同時にアクセスを安全に保ちながら、昇格の閾値は二重検索のコストが多くのアクセスにわたって分散されることを保証します。
私たちの分散システムチームは、100k+ QPSを処理する高スループットのメタデータサービスで深刻なレイテンシスパイクに直面しました。このサービスは、UUIDでキー付けされた構成オブジェクトをキャッシュしており、95%のトラフィックがホットキーの5%にヒットし、バックグラウンドのゴルーチンが新規デプロイされたサービス用の新しい構成を継続的に追加しました。
ソリューション 1: sync.RWMutexを使用したマップ
最初の実装では、sync.RWMutexで保護された標準のマップを使用しました。概念的には単純ですが、このアプローチは高い同時実行性の下では深刻な競合に悩まされました。すべてのリーダーゴルーチンがミューテックスの内部状態ワードのキャッシュラインを競っていたからです。バックグラウンドのライターが新しい構成を追加するために書き込みロックを取得すると、すべてのリーダーがブロックされ、キャッシュ更新サイクル中に500msを超えるp99レイテンシスパイクを引き起こしました。
ソリューション 2: シャーディングミューテックスアプローチ
その後、ハッシュベースのキー分配を用いた256のsync.RWMutexインスタンスを使用したシャーディングマップのプロトタイプを作成しました。この設計は、異なるキャッシュラインと別々のミューテックスに負荷を分散させることにより競合を減らしました。しかし、リサイズ中の一貫したハッシュを維持する際に大きな複雑さをもたらし、避けられないホットキーが不均衡なシャードを生み出し、依然としてテールレイテンシスパイクの影響を受けました。
ソリューション 3: sync.Map
最終的に、プロファイリングにより特定のアクセスパターンが確認された後、私たちはsync.Mapを採用しました：読み取りは安定した長寿命のキーをターゲットにし、書き込みは一時的な新しいキーを導入しました。読み取りパスのロックフリー原子的ロードはキャッシュラインのバウンスを完全に排除し、自動昇格ヒューリスティックは特定のワークロード特性に最適化されました。シングルスレッドのスループットは通常のマップに比べて約20%低かったものの、ミューテックスの競合の排除により、高速な書き込みバースト中にp99レイテンシを5ms未満に削減しました。
デプロイメントによりテールレイテンシの安定性が100倍向上し、構成のリフレッシュ中にゴルーチンのスタックアップを完全に排除しました。サービスの可用性はピークトラフィック期間中に99.9%から99.99%に増加し、月単位の運用期間中にメモリリークはゼロでした。
なぜsync.Mapは値を*entryポインタとして保存するのか、そしてこれがロックフリーの削除をどのように可能にするのか？
readマップは、ロックフリーの削除を可能にするために、生のinterface{}値ではなく*entry構造体を格納します。キーを削除する際、sync.Mapはエントリの内部ポインタを原子的にnilと交換し、スロットを空にしながらマップエントリをそのままにしておきます。この読み取り専用マップ構造の不変性により、削除中に同時に動作しているリーダーがロックなしで操作できるようになりますが、削除されたキーは次の昇格サイクルでクリアされるまでメモリを消費し続けます。
sync.Mapはいつダーティマップを読み取りに昇格させるか、そしてこの特定の閾値がパフォーマンスにとって重要な理由は何ですか？
昇格は、読み取り専用マップ内の失敗した検索中に増加する原子的なmissesカウンタがdirtyマップの長さを超えたときに発生します。この閾値は、二重検索のペナルティのコストが全体のdirtyマップをread原子ポインタにコピーするコストを上回ることを保証します。一度トリガーされると、dirtyマップは原子的にreadに昇格され、dirtyマップはnilに設定され、ミスはゼロにリセットされ、効果的に多くの失敗した検索全体にわたって昇格コストを分散させます。
ダーティから読み取りへの原子的な昇格中に、並行リーダーが部分的に更新されたマップ状態を観測せずに操作を続けることを可能にするメカニズムは何ですか？
昇格中、コードはreadフィールドの原子的なポインタスワップを実行して前のdirtyマップを指し、Goのメモリモデルはこの状態がすべてのゴルーチンに原子的に見えることを保証します。並行リーダーは、古いreadマップまたは新しく昇格されたマップのいずれかを観測しますが、無効または部分的に構築された状態を観測することはありません。なぜなら、マップの割り当てはポインタスワップの前に完了するからです。古いreadマップは、すべての参照がドロップされて初めて回収されるGoのガーベジコレクタによって、流入中のリーダーにとって到達可能なままです。これは、sync.Mapがロックフリーの構造的遷移のためにガーベジコレクションを活用する方法を示しています。