Учимся применять Semaphore и Worker Pool на Go

Не стоит изобретать новые велосипеды. Уже есть https://pkg.go.dev/golang.org/x/sync/errgroup

Отличная статья! Есть пример для семафора, к сожалению он не затрагивает воркер пул, но думаю тк статья про семафор, то имеет место быть. Плюс, если кто-то захочет найти еще примеры использования семафора, то может посмотреть исходники pgx (а точнее pgxpool).

Когда я писал тесты для слоя базы данных(тестировал без мока бд). То была проблема с тем, что тесты ломали друг друга. Решений было несколько:
1. Ограничить количество одновременных тестов до 1 (т.к у нас не только бд тесты, то их выполнение на 1 потоке занимает много времени)
2. Создавать отдельные схемы для каждого тесты (усложнение логики)
3. Запускать для каждого теста отдельный контейнер
4. Использовать семафор с размером 1 для лока 1 теста бд за раз (плюсы: простая логика. Минусы, при большом количество тестов для базы данных скорее всего это станет узким горлом).
Собственно 4 вариант и был выбран. К слову, если кто-то знает еще варианты решения этого вопроса, то буду рад узнать, как минимум для понимания того, что я мог упустить.

Также было бы интересно посмотреть использование паттернов fan-in и fan-out на практике.

Автору большое спасибо за примеры!

А зачем плодить миллион висящих горутин?

for _, v := range usrs {
  sem.Acquire()
  go func(usr users.User) {
    defer sem.Release()
    ...
  }
}

       select {
			case outputCh <- resultWithError{
				User: usr,
				Err:  err,
			}:
			case <-sgnlCh:
				return
		}

В этой конструкции sgnlCh должен идти первым в селекте, а не последним

Есть некое количество пользователей, например от 1 до 100 000, по каждому надо выполнить функцию Deactivate. Как правило, это происходит путём отправки одного запроса в сторонний API

Тогда ваша функция и этот внешний API должны принимать контекст и код обоих подходов будет выглядеть иначе.

Также смущают эти моменты:

1. Сомнительный дизайн у cемафора. Если вы его выделяете в отдельную сущность (а не просто работаете с каналом), то очевидно канал лучше сделать приватным и обернуть его создание в конструктор.

2. Вообще говоря подход с семафором и cancel-ом по первой ошибке реализован в golang.org/x/sync/errgroup и там это сделано почище — единственное чего там может не хватать recover-а паник внутри горутин (см. https://github.com/golang/go/issues/53757)

3. Во втором примере у вас утечка горутин. После return-а по ошибке в основной функции горутины будут вечно висеть на записи в outCh. Это легко отловить через условный go.uber.org/goleak

4. Тут уже мое имхо, но кажется, что лучше дожидаться завершения всех запущенных горутин в функции, даже если вы уверены, что они рано или поздно завершатся