Чистим main.go: предсказуемый старт и надежный Graceful Shutdown

Сталкивались ли вы с болью при управлении порядком запуска и остановки зависимостей в вашем Go-сервисе? Разработка больших сервисов неизбежно приводит к необходимости управлять множеством зависимостей. В этом контексте мы говорим о долгоживущих компонентах , чья работа обеспечивается отдельными горутинами: как правило, это блокирующий метод (например, Start ), внутри которого крутится цикл обработки. Примерный сценарий жизненного цикла сервиса выглядит так: При запуске критически важно, чтобы пул соединений с БД, кэш и очереди были полностью готовы до того, как HTTP-сервер откроет порт и начнет принимать входящий трафик. С graceful shutdown ситуация обратная: порядок должен быть строго зеркальным. Сначала нужно перестать принимать новые запросы, дождаться завершения текущих, остановить воркеры, и только потом разрывать соединения с инфраструктурой. Иначе мы получаем неприятные ошибки подключения и даже потерянные транзакции в момент деплоя. Если эти проблемы вам не знакомы, смело закрывайте вкладку. Скорее всего, эта статья не принесет вам пользы. Но если вы ищете способ автоматизировать эту рутину, сохранив код чистым - добро пожаловать под кат.

https://habr.com/ru/articles/976800/

#go #golang #graceful_shutdown #dag #Dependency_Injection #Uber_Fx #Микросервисы #Open_Source #Архитектура #lifecycle

DAG-классификация: как мы научили поиск определять нужную категорию ступенчатым образом

Одна из важнейших задач поиска — релевантная выдача. Простых универсальных решений здесь нет, а улучшение поиска — долгосрочный процесс, где крупные задачи приходится разбивать на небольшие, последовательные шаги. В этой статье делимся тем, как нам в «Магнит Маркете» удалось значительно улучшить качество поиска с помощью нетривиального подхода: ступенчатой классификации категории поискового запроса.

https://habr.com/ru/companies/magnit/articles/975980/

#ml #dag #поиск #ранжирование #релевантный_поиск #релевантность_поисковой_выдачи #data_science #dagмодель #оптимизация_поиска

I am thinking about an interesting problem right now.

Suppose I have a DAG of objects. Every object contains three data points:

* A list of parents (via Content-address hashes)
* A pointer to some content (almost irrelevant for this thought process)
* A version number (irrelevant for this thought process)

I have a limited but unknown number of peers that are allowed to "post" to that DAG. Once a peer discovers that another node has posted to the DAG, they either fast-foward or merge (which is trivial here) and go on.
All peers gossip all the time, so fast-forwarding is expected to be the "normal case" when all peers are online - but in case of network split there is no issue.

Now, suppose I want to allow "rewriting" the DAG.
That means, one node decides that deep down in the DAG, they want to change a node. That would change all other nodes that come after it.

How would the other peers know that the node was rewritten?

Two ideas:

* All peers keep track of "this other peer points to this hash right now". Once a peer rewrites their DAG, other peers can see that rather easily. That would involve some tricky logic, but I guess would be possible 🤔 The other peers can then update their stuff to that new DAG (and if needed even "rebase" changes that they have done between the rewrite and now, if there was a network split during that time)
* The second option would involve adding timestamps to the DAG nodes, so other nodes can see that a portion of the DAG was rewritten

The second option would add more fields to the DAG nodes, which I would like to not do, because they should be as light as possible.

What do you think?  

#algorithms #softwaredevelopment #dag #distributedsystems #graphdata #datatypes

This mysterious blob is evidence of a male sparrow caught brown beaked stealing hemp from the hemp weed mat I put on the Rimu.

I noticed last night it was shredded and now I’ve seen the culprit!

#bird #dag #wool