sql.Open() возвращает у тебя в DB, в этот момент ты берешь database.DB и обращаешься к нему.

Это пока устраивает. А потом не будет устраивать, но забудется и придется искать причину ошибки. Так что лучше сразу нормально сделать.

go-database-sql.org/accessing.html Perhaps counter-intuitively, sql.Open() does not establish any connections to the database, nor does it validate driver connection parameters. Instead, it simply prepares the database abstraction for later use. 

ладно, забей

Правда пример такого софта я не могу привести) Но есть софт где локи много выедают.

Еще очень интересно как работает RWMutex. Допустим есть 1000 горутин, которые вызвали RLock() и в этот момент читают данные. Вызываем в другой рутине Lock(), она будет ждать пока эта 1000 дочитает, это предсказуемо. Но в тоже время, если у нас появятся еще 500 читателей, то они будут ждать пока первая 1000 дочитает, потом, когда запишется и только потом смогут получить свои данные и это мне показалось несколько странно. Потому, что за это время уже можно ответить на запросы из тех данных, что есть.

Смотри https://github.com/Supme/gonder/blob/master/models/config.go#L33 Это потом используется во всём приложении и для рассылки в тысячи потоков и для статистики и для апи. Если не ограничить коннекты к базе, то база будет через какое то время делать отлуп

Lock приоритетнее чем RLock

поднимать коннект в init, это шляпа

Lock будет ждать пока существующие RLock не разблокируются. И заблокирует все новые RLock.

Еще очень интересно как работает RWMutex. Допустим есть 1000 горутин, которые вызвали RLock() и в этот момент читают данные. Вызываем в другой рутине Lock(), она будет ждать пока эта 1000 дочитает, это предсказуемо. Но в тоже время, если у нас появятся еще 500 читателей, то они будут ждать пока первая 1000 дочитает, потом, когда запишется и только потом смогут получить свои данные и это мне показалось несколько странно. Потому, что за это время уже можно ответить на запросы из тех данных, что есть.

Да, ты же можешь изменить данные поэтому и остальные читатели ждут, потому что ты уведомил их что сейчас будешь что-то изменять.

Нормально работает, а тот селект 1 это проверка что не голая база

Вы прочитайте переменную и сделайте анлок. Либо атомики используйте.

Логично, а вы дочитали вторую часть моего длинного сообщения?)

Ой, всё) Вы такие внимательные)

Я не понимаю, что показалось странным.

=) это продуманное решение в пользу быстродействия. Задача была сэкономить такты на лочках при подмене одного кеша другим (кеш в сложной структуре с мапами, поэтому просто подменяем указатели). При этом какой кеш успел прочитать клиент - не принципиально, критична именно скорость ответа.

Вторые 500 читателей появились уже после того как я уведомил, что хочу изменить данные. Что в этом странного)

это случаем не с sync.Map вы имеете дело? Там как бы нету способа очистить мапу быстро

В том, что если вас устраивает, что они могут получить за время лока старые данные и это будет корректно - то они лочатся напрасно.

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

Юзайте пакет unsafe) Только осторожно)

какую именно возможность из него стоит изучить?

Ну, возможность у него одна - читать и записывать произвольную память. С тех времен как конкуретное чтение мапок стало алертить он спасает)

охох) нет, это не наш выбор. мы пошли намного более безопасным и быстрым путём в вопросе параллельной записи и чтения мап

Шардирование?

Нет. У нас задача как можно быстрее отдавать ответ, не меняя данные в процессе ответа. Поэтому мы имеем "кеш" в работе, который только читается и для всех новых клиентов подменяем указатель на новый прогретый кеш.

А если в момент подмены ещё и сборщик придёт?

Не понял вашего вопроса

И попортит данные предыдущие

А как вы заполняете второй кэш?

А если в момент подмены ещё и сборщик придёт?

Нет. У нас задача как можно быстрее отдавать ответ, не меняя данные в процессе ответа. Поэтому мы имеем "кеш" в работе, который только читается и для всех новых клиентов подменяем указатель на новый прогретый кеш.

Там все медленные процессы хождения в базу и подготовки данных

По порядку)

Магия, но быстрее решения не придумал

а bigcache пробовали? Я не уверен что он быстрее, но он очень интересно хранит данные в одной куче и по оффсетам достает. Должно быть очень быстро и конкуретно)

Магия, но быстрее решения не придумал

Есть вероятность, что все гоурутины встанут в ожидании, пока наполнитель кэша будет обрабатывать данные на пополнение кэша.

А какая нагрузка то?

Почему?

Потому что запись в канал блокирующая операция (в которой, кстати мютексы используются) и пока данные не изымут из канала горутина будет висеть. Либо делать буфер с запасом.

я подумал и над этим. хотите решение покажу?)

Покажите.

Можно шардить мапы, в каждой мапе есть RWMutex, сами сущности кеша через бинарный семафор и закрытый канал работают. Если канал закрыт, чтение мгновенное, отдаем значение. Если канал открыт, тогда за значением уже кто-то пришел, стоит очередь, и когда значение получено, канал закрывается и все получают свои значения. Т.о. чтение значения entity сопровождается чтением из канала в пустоту. Сами мапы можно и без RWMutex сделать на каналах. Но каналы по 100 нс выжирают. Это как раз ваш кейс, когда за одним значением пришло несколько горутин, все получат один и тот же ответ, полученный единоразово из базы или откуда-то.

В проде сейчас в среднем 800 запросов в секунду, но там пхп и тоже все оптимизированно, что даже на 10% проц не грузит.

вы на глаз определили? или как? конечно держать извечно прогретый кеш и подменять указатель будет быстрее, но по памяти - вряд ли.

к слову, в вашем кейсе вместо того чтобы копить очередь на открытом канале, можно отдавать oldValue, который создан перед тем как пойти за значением

С лочками и каналами медленнее, чем без лочек и каналов, вы не согласны?