Sphagnum. Часть 1. Начало.
#sphagnum@eshu_coding

Начинаю новый пет-проект: свой брокер сообщений. Обозвал я его пока Sphagnum, проект планируется в качестве чисто образовательного, под лицензией MIT. Что я хочу получить на выходе:
1. По основному функционалу - клон RabbitMQ, возможно несколько урезанный.
2. Возможность встраивать брокер в другие приложения на .net для организации доступа к проходящим через брокер данным и уменьшению накладных расходов на передачу данных по сети.
3. Очень хочется кафкоподобное горизонтальное масштабирование.
4. Очень хочется возможность сохранения истории прошедших через брокер данных с вычиткой их с произвольного момента.
5. Очень хочется сделать шажочек в сторону работы с динамическими ip некоторых интстансов в системе.

В дальнейшем всё связанное с проектом будет публиковаться под тегами #sphagnum@eshu_coding или #sphagnum. В ближайшее время я буду читать всякое на смежные темы и выкладывать разные теоретические заметки. Код будет ориентировочно зимой.

Пока видится несколько этапов:
1. Отработка основных шаманств по передаче данных, скорее всего поверх сокетов.
2. Реализация хранения данных, думаю надо уметь как NATS - и на диск в самопальные файлики и в базу данных.
3. Админка, видимо в двух вариациях: через rest api и что-то интерактивное, с ui, на базе blazor как вариант.
4. Тесты и оптимизации, оптимизации и тесты. Если удастся догнать RabbitMQ - это будет отличным результатом.
5. Выкатывание проекта в открытый доступ: nuget пакет для установки, несколько образов на docker hub, клиентские библиотеки для основных языков программирования - c#, java, js, python, golang

#проекты

Sphagnum. Часть 2. Зачем, а главное нафига?
#sphagnum@eshu_coding

1. Саморазвитие. Читать умные книги это очень познавательно, но намного лучше я усваиваю информацию, когда решаю какую-то задачу, интересную мне. А тут ожидается и изучение существующих архитектурных решений, и выдавливание максимума производительности из c# кода.

2. Для встраиваемого брокера сообщений в экосистеме .Net вполне найдется место. Я вижу как минимум две ниши:
a) Организация сетевого взаимодействия в геймдеве на Unity или в мобильной разработке с использованием MAUI.

b) Онлайн анализ протекающих через брокер данных: например поиск ключевых слов в потоке логов/текстов, которые отправляются на архивирование. Можно конечно ответвить поток данных на отдельного потребителя, осуществляющего анализ. Но в случае цунами из данных, анализ может произойти слишком поздно. А со встроенным брокером - просто скопировать данные (или вообще ссылку на них) внутри процесса. Если бы я запускал #палантир@eshu_coding сейчас, я бы точно не отказался от такого инструмента.

Sphagnum. Часть 3. Техобзор, начало.
#sphagnum@eshu_coding

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

Прежде чем садиться писать код, нужно изучить некоторые моменты, чтобы потом не строить велосипеды из костылей. В науке эту часть работы называют "литобзор", а у меня пусть будет "техобзор" (далее под тегом #sphagnum_theory@eshu_coding)

Набросал примерный план для изучения:
1. Как организовано взаимодействие между инстансами (в т.ч. отказоустойчивость) в рамках одного replica set у следующих продуктов:
А. PostgreSQL
B. MongoDB
C. RabbitMQ
D. Kafka
E. Tarantool
F. NATS

2. Механизмы реализации (и отката, в т.ч. в нескольких инстансах, если их несколько) транзакций у:
A. PostgreSQL
B. RabbitMQ
C. Kafka
D. MongoDB

3. Механизмы шардирования у:
A. Tarantool
B. MongoDB
C. Kafka

4. Сделать обзор, что пишут известные люди в умных книжках по теме распределенных транзакций.

5. Обзор организации обмена сообщениями (Queue, Exchange, Topic etc.) в следующих брокерах сообщений:
1. RabbitMQ
2. Kafka
3. NATS