очередь это все-таки список задач

Так его задача о юзере сообщить

а тут чот странное, типа есть база какая-то, надо по ней гулять и отправлять сообщения

и может быть что-то еще

Но в любом случае, я бы сделал канал из которого бы читал юзеров сразу и слал бы через что там хочется, а мапу бы не трогал

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

ну конечно иначе)

redis например )

подписываешь клиента на изменения и все, они автоматически получат инфу о новой записи

можно и самому реализовать

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

Именно

redis например )

Я бы не тащил редис. Можно взять каналы и гонять структуры

И будет ок

но ходить часами по структуре данных, это конеш не очень

redis - то еще дерьмо. эта фича у него, конечно, суперская, но недостатков полно. так, на всякий случай

Я бы не тащил редис. Можно взять каналы и гонять структуры

если речь идет о миллионах данных, я бы уже думал о сервисе

а почему в качестве решения выбрано посылать один месседж в секунду?

В секунду или в минуту, интервал потом подберу. Мне важно на нодах держать более-менее последнее состояние с информацией о юзерах. Устаревшее состояние тоже ок, если это единичные случаи. И если вдруг какая-то нода упала и поднялась, залить в неё постепенно это состояние.

redis - то еще дерьмо. эта фича у него, конечно, суперская, но недостатков полно. так, на всякий случай

А чем плох?

реди может просто хранить, если надо пижже транспорт -> rabbitMQ

а почему обходить надо в случайном порядке?

потомучто мапа по другому не умеет

ради одной этой проблемы городить редис, БД и прочее не вижу никакого смысла. Всё только на Go и в памяти.

В секунду или в минуту, интервал потом подберу. Мне важно на нодах держать более-менее последнее состояние с информацией о юзерах. Устаревшее состояние тоже ок, если это единичные случаи. И если вдруг какая-то нода упала и поднялась, залить в неё постепенно это состояние.

то есть - у вас сервис, который только что поднялся, может и не иметь полных данных?! не верю

В секунду или в минуту, интервал потом подберу. Мне важно на нодах держать более-менее последнее состояние с информацией о юзерах. Устаревшее состояние тоже ок, если это единичные случаи. И если вдруг какая-то нода упала и поднялась, залить в неё постепенно это состояние.

Ну так на каждое изменение ставь в очередь сообщение о нем

Очередь на каналах

Будет работать лучше чем обход мапы

Вот я очень не хотел, чтобы обсуждение съехало в сторону от исходного вопроса. А оно таки съехало.

ради одной этой проблемы городить редис, БД и прочее не вижу никакого смысла. Всё только на Go и в памяти.

в золотой фонд)

я бы хотел заметить, что 1М секунд - это больше 10 дней

Вот я очень не хотел, чтобы обсуждение съехало в сторону от исходного вопроса. А оно таки съехало.

тебе ответили по вопросу конкретно и ты даже благодарил. Дальше мы уже сами )

Ну значит пачками по 1000 юзеров.

Вот я очень не хотел, чтобы обсуждение съехало в сторону от исходного вопроса. А оно таки съехало.

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

никаких гарантий. отправилось - хорошо. не отправилось - не страшно, потом отправится.

Вот я очень не хотел, чтобы обсуждение съехало в сторону от исходного вопроса. А оно таки съехало.

а важно ли отправить всех юзеров?

никаких гарантий. отправилось - хорошо. не отправилось - не страшно, потом отправится.

А какая гарантия что это потом вообще наступит?

Ну значит пачками по 1000 юзеров.

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

а важно ли отправить всех юзеров?

важно, чтобы в пределе они все отправились. пусть не с первой итерации, но в и тоге отправились.

это ответ "не важно", как мы понимаем

А какая гарантия что это потом вообще наступит?

Нет никаких гарантий.

Что это за система такая..

недетерминированная! это, видимо, игра типа "найди и воспроизведи баг"

это ответ "не важно", как мы понимаем

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

Нет никаких гарантий.

Ну так значит обходя мапу все юзера могут никогда не отправится

недетерминированная! это, видимо, игра типа "найди и воспроизведи баг"

Во-во. От этом я и писал.

И ты ещё получишь замечательную задачу - следить за тем кто отправился

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

ооооох. не, делайте, как хотите. результат будет поразительный

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

одной ноды достаточно для работы.

и никаких Бд с их репликациями, бэкапами...

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

именно эту задачу решают БД с их репликациями и бекапами

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

Где конечное время измеряется минутами

уже пришли к моему решению или еще подождать сотню коментов?)

"базы данных это сложно, поэтому я решил сделать свою базу данных без базы данных"

лол)

уже пришли к моему решению или еще подождать сотню коментов?)

лист для юзеров и отдельная очередь для отправки?

Отчего же минутами. Упал канал у провайдера. Там и дни могут быть, как вот Битрикс страдал недавно...

и никаких Бд с их репликациями, бэкапами...

А чем твое решение отличается от бд?

лист для юзеров и отдельная очередь для отправки?

конеш. либо все в одном редиска + подписки

Кроме того что никогда не гарантирует консистентность

ну это по идее самое очевидное решение и логичное

ну так о чем и речь

Кроме того что никогда не гарантирует консистентность

которая мне желанна, но не необходима.

лист для юзеров и отдельная очередь для отправки?

Ему уже говорили

обход ляма объектов это не правильно

и секунда пади еще задержка на отправку ?))

откуда эта секунда

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

Посмотрите distributed databases. В крайнем случае блокчейн ?

ERROR: S client not available

секунда это бесконечность )

Блохчейн - это свежая мысль. Ага.

Думал прикрутить ещё машин лёнинг.

и пусть он решает, как мэпу обойти.

да на этом можно степень защитить

все так делают!

@MichaelMonashev так чем плохо решение с очередью изменений отдельной от мапы?

будь как все!

@MichaelMonashev так чем плохо решение с очередью изменений отдельной от мапы?

дай угодаю. Сложная реализация

и не очередь! прекрати ее так называть

@MichaelMonashev так чем плохо решение с очередью изменений отдельной от мапы?

упала нода. на неё надо залить не только изменения, но и все другие данные тоже.

сё, я пас

так можно для этого научить ноду когда она поднимация запрашивать весь стейт

упала нода. на неё надо залить не только изменения, но и все другие данные тоже.

ну так в таком случаи ты обходишь всю мапы (1М элементов это мало кстати), и ставишь все данные в очередь на отправку. Проблема в чем?

и не очередь! прекрати ее так называть

я не прекращу называть очередь очередью )

это вариант конечно.

засранец!

упала нода. на неё надо залить не только изменения, но и все другие данные тоже.

https://medium.com/@mycoralhealth/code-your-own-blockchain-in-less-than-200-lines-of-go-e296282bcffc

https://medium.com/@mycoralhealth/code-your-own-blockchain-in-less-than-200-lines-of-go-e296282bcffc

жирнота!

я вот подумал, а можно ли for k,v:=range map{ обложить локом и анлоком?

а нахрен?

я вот подумал, а можно ли for k,v:=range map{ обложить локом и анлоком?

Можно, в мьютексе есть RLock и RUnlock

т.е. что-то вроде users.RLock() for user, props:=range users.map { users.RUnlock() // тут что-то делаем time.Sleep(time.Minute) users.RLock() } users.RUnlock()

юзай в юзере sync.RWmutex

т.е. что-то вроде users.RLock() for user, props:=range users.map { users.RUnlock() // тут что-то делаем time.Sleep(time.Minute) users.RLock() } users.RUnlock()

sync.Map

это позволит итерироваться с паузами не по снэпшоту (как в sync.Map), а по текущему map-у

это позволит итерироваться с паузами не по снэпшоту (как в sync.Map), а по текущему map-у

а как вариант почему не снять снапшот и не итерироваться по нему? Если это надо

потому что в снэпшоте старые данные.

потому что в снэпшоте старые данные.

тебе же не важна консистентность

я не вижу смысла отправлять старые данные, если можно придумать, как отправлять свежие.

давайте прикрутим к map MVCC и транзакции

и всё ещё будем говорить, что базы данных сложные