Интересный разбор для тех, кто пишет кэш в Go и думает, что проблема решается простым
sync.RWMutex.Автор прогнал 6 вариантов дизайна кэша и показал неприятную вещь: один общий lock быстро становится бутылочным горлышком. Чем больше горутин лезет в кэш, тем сильнее они начинают мешать друг другу.
Самый практичный вывод: шардируйте locks.
Вместо одной большой map под одним mutex кэш делится на несколько shard’ов. Каждый shard хранит свою часть данных и имеет свой lock. В итоге разные goroutine чаще работают с разными locks, меньше ждут друг друга и лучше используют CPU.
Отдельно интересно, что
sync.RWMutex не всегда спасает. На смешанной нагрузке с чтением и записью его накладные расходы могут оказаться заметнее, чем кажется. А sync.Map тоже не превращается в универсальную кнопку «сделать быстро».Хороший материал про то, почему производительность в Go часто ломается не на алгоритме, а на конкуренции за одну общую точку.
Статья: «Shard your locks: benchmarking 6 Go cache designs»
https://strebkov.dev/posts/shard-your-locks/