Умный брокер или глупый consumer?

В мире брокеров сообщений часто обсуждают концепцию "умный брокер, глупый consumer" и наоборот. Эта характеристика описывает архитектуру распределения задач между брокером сообщений и потребителями. Давайте разберемся, где в этом спектре находится Kafka.

📌 Умный брокер, глупый consumer
Примером таких систем является RabbitMQ. Брокер берет на себя всю сложность: управление очередями, маршрутизацию, подтверждения доставки и балансировку нагрузки. Потребители получают готовые сообщения, минимально участвуя в логике обработки.

📌 Глупый брокер, умный consumer
Теперь давайте разберем противоположную концепцию. Kafka ближе к этой модели. Брокер в Kafka работает как высокопроизводительное хранилище, которое просто сохраняет и отдает сообщения. Все сложные задачи — например, управление смещениями (*offsets*), распределение нагрузки и повторная обработка сообщений — возлагаются на потребителей.

🎯 Почему Kafka выбирает "глупый брокер"?
• Производительность. Упрощенный брокер может работать с огромными объемами данных, минимально вмешиваясь в обработку. Kafka поддерживает миллионы сообщений в секунду.
• Гибкость. Потребители полностью контролируют логику обработки: какой *offset* читать, как обрабатывать ошибки и в каком темпе работать. *(Offset — это позиция, с которой потребитель начинает читать сообщения в топике.)*
• Долговременное хранение. Kafka сохраняет данные в течение заданного времени, позволяя потребителям возвращаться к старым сообщениям.

Что произойдет, если перезапустить consumer во время обработки сообщения? 🤔

В системах, где используются брокеры сообщений, таких как Kafka, перезапуск consumer'а в момент обработки сообщения может привести к разным сценариям. Давайте разберем, как это работает👇

1️⃣ Сообщение будет считаться необработанным
В Kafka consumer сам отслеживает, какие сообщения он обработал, с помощью _offset_. Если consumer перезапускается, но не успел подтвердить (_commit_) обработку сообщения, брокер считает, что это сообщение не обработано. После перезапуска это сообщение будет снова отправлено потребителю.

2️⃣ Идемпотентность – ключ к правильной обработке
Если обработка сообщения не является идемпотентной (например, при внесении изменений в базу данных), то повторная обработка одного и того же сообщения может привести к дублированию действий. Поэтому важно проектировать обработку так, чтобы повторный запуск не создавал проблем. Например, использовать уникальные идентификаторы транзакций.

3️⃣ Автоматическая передача другому consumer'у
Если вы используете consumer group, то после перезапуска брокер может переназначить партиции другому consumer'у из той же группы. В этом случае сообщение начнет обрабатываться другим consumer'ом.

4️⃣ Настройка автокоммита
Если у вас включен автоматический коммит (_auto-commit_), есть вероятность, что _offset_ уже был зафиксирован, даже если сообщение фактически не обработано. Это может привести к пропуску сообщения. Чтобы этого избежать, лучше использовать ручной коммит после успешной обработки.

🔗 #SYSTEMDESIGN

Задача: Гарантированная доставка заказов в нестабильный брокер

Есть две системы: система А, в которой создаются заказы, и система Б, внешняя по отношению к системе А. Для интеграции требуется настроить процесс передачи заказов из системы А в брокер на стороне системы Б. Однако брокер системы Б работает нестабильно, что может приводить к сбоям при приёме сообщений. На стороне системы А также имеется собственный брокер сообщений, что добавляет возможности для реализации надёжной доставки. В системе А формируется до 2000 заказов в час. Как можно реализовать процесс таким образом, чтобы гарантировать доставку заказов в брокер системы Б, даже при его нестабильной работе? Какие доработки потребуются на стороне системы А, чтобы минимизировать риски потери данных и обеспечить устойчивую интеграцию?

Ответ:
Для гарантированной доставки заказов в брокер системы Б нужно настроить локальный брокер сообщений в системе А. При создании заказа сообщение о нём отправляется в локальный брокер. Локальный брокер отвечает за попытки доставки в брокер системы Б. В случае недоступности брокера системы Б сообщения остаются в локальном брокере и отправляются повторно до успешной доставки. Для недоставленных сообщений использовать dead-letter queue. Такой подход гарантирует надёжную и масштабируемую интеграцию, минимизируя риски потерь данных.

🛠 Контрольная сумма: зачем она нужна и как работает

Контрольная сумма – инструмент проверки целостности данных при их передаче. Она выявляет ошибки из-за помех, делая передачу надежнее. Однако алгоритмы её расчета сложны, особенно при ограниченных ресурсах, как в микроконтроллерах.

📌 Простейшие методы
Бит четности – базовый способ, проверяющий четность/нечетность единичных битов. Прост, но пропускает двойные ошибки.
8-битная сумма – складывает значения всех байтов данных. Уязвим, если изменения в байтах компенсируются.

📌 Продвинутые подходы
Для улучшения используют побитовое смешивание или умножение на «магические» числа. Например, алгоритмы CRC (Cyclic Redundancy Check) повышают надежность благодаря равномерному распределению изменений данных.

🔗 #SECURITY

🖥 Stateful vs Stateless: что выбрать?

В программной архитектуре stateful и stateless относятся к способу управления состоянием системы. Разберем их основные различия, преимущества и недостатки.

📌 Stateful (с сохранением состояния)
Системы сохраняют информацию о сеансах и запросах, что удобно для сложных приложений с длительными взаимодействиями.
Плюсы:
• Сохранение состояния между запросами.
• Упрощенная логика работы.
• Более простое восстановление после сбоев.
Минусы:
• Высокая нагрузка на сервер из-за хранения состояния.
• Сложность изменения состояния.
• Ограниченная отказоустойчивость.

📌 Stateless (без сохранения состояния)
Каждый запрос независим и не зависит от предыдущих. Типичный пример — RESTful веб-сервисы.
Плюсы:
• Отличная масштабируемость.
• Упрощенная разработка и тестирование.
• Высокая отказоустойчивость.
Минусы:
• Сложность работы с сеансами или сложными сценариями.
• Увеличение нагрузки из-за передачи полной информации в каждом запросе.

📌 Что выбрать?
Если вы планируете распределенное и отказоустойчивое приложение - смотрите в сторону stateless-архитектуры. Если же вы создаете MVP, ваше приложение не является критичным с точки зрения простоя, и горизонтальное масштабирование не предполагается - выбирайте stateful-архитектуру. Что касается меня, то мой выбор - stateless по-умолчанию. И только в случае обоснованной необходимости, принимая все потенциальные риски, я выбираю stateful.

🔗 #SYSTEMDESIGN

Добрый день👨‍💻

🌐 Curl: универсальный инструмент для работы с HTTP-запросами

Что такое Curl?
Curl (Client URL) — это мощная утилита командной строки для работы с HTTP-запросами и передачи данных по множеству протоколов. С её помощью вы можете выполнять GET и POST-запросы, загружать файлы, тестировать API и отлаживать веб-приложения.

🛠 Основные возможности Curl

📥 Скачивание файлов
Сохраните JSON-ответ в файл:

curl -o post.json https://jsonplaceholder.typicode.com/posts/1

📋 Получение заголовков HTTP
Проверьте информацию о типе контента и статусе ответа:

curl -I https://jsonplaceholder.typicode.com/posts/1

🔑 Аутентификация
Работа с защищёнными ресурсами:

curl -u username:password https://jsonplaceholder.typicode.com/posts

🔄 Следование редиректам
Позволяет автоматически перенаправлять запросы:

curl -L https://jsonplaceholder.typicode.com/posts/1

📤 Загрузка данных (POST-запрос)
Создайте JSON-файл и отправьте его на сервер:

echo {"title":"Test","body":"Example","userId":1} > newpost.json  
curl -X POST -H "Content-Type: application/json" -d @newpost.json https://jsonplaceholder.typicode.com/posts

🔍 Почему использовать Curl?
Curl выделяется своей универсальностью, поддержкой множества протоколов (HTTP, HTTPS, FTP и других) и простым синтаксисом.

📌 Поделитесь в комментариях, как вы используете Curl в своей работе!

🔗 #OTHER

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

📂 Основные виды систем контроля версий:
1️⃣ Copy-paste: Самый простой способ — вручную создавать копии файлов с разными названиями, например file_v1, file_v2. Но такой подход неудобен и приводит к ошибкам.
2️⃣ Локальные системы: Первые системы, как RCS, хранили изменения локально. Однако они не подходили для командной работы, так как все данные были на одном устройстве.
3️⃣ Централизованные системы: Например, Subversion (SVN). Все данные хранятся на одном сервере, и команды могут работать вместе. Но если сервер «падает», доступ к проекту теряется.
4️⃣ Распределенные системы: Такие, как Git. Здесь у каждого разработчика есть полная копия проекта. Это обеспечивает надежность — если один компьютер выходит из строя, данные остаются у других участников.

🖥 Почему Git стал лидером?
В 2005 году разработчики Linux создали Git как систему, которая объединяет скорость, децентрализацию и удобство. С тех пор он стал стандартом в IT и используется для работы над проектами любой сложности.

#SYSTEMDESIGN

Клиент всегда прав?

🔗 Что такое вебхук и зачем он нужен?

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

📌 Пример:
🛒 Клиент оформил заказ в интернет-магазине → 🖥 Система отправила вебхук → 📲 Владелец магазина получил уведомление в приложении.

🤔 В чем разница между вебхуком и API?
API: Клиент постоянно запрашивает сервер: «Есть новости?»
Вебхук: Сервер сам отправляет уведомление, когда появятся важные данные.

🛠 Где используются вебхуки?
• GitHub — для уведомлений о новых коммитах.
• CRM и интернет-магазины — для уведомлений о заказах.
• Коллтрекинг — для уведомлений о звонках и заявках.

🔒 Как сделать вебхуки безопасными?
• Использовать HTTPS для шифрования данных.
• Добавлять уникальные токены в URL вебхуков.
• Реализовать аутентификацию для подтверждения отправителя.

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

#INTEGRATION

📌 Нотация C4: как визуализировать архитектуру системы понятным языком

Когда речь заходит о проектировании архитектуры программного обеспечения, важно не только понимать систему, но и уметь наглядно передавать информацию другим. Один из самых удобных способов для этого — C4-нотация, разработанная Саймоном Брауном.

🔹 Что такое C4?
C4 помогает моделировать архитектуру ПО на 4 уровнях:
📌 Context — показывает систему в общем контексте (пользователи, внешние сервисы).
📌 Container — определяет основные компоненты (приложения, базы данных).
📌 Component — детализирует структуру внутри контейнеров.
📌 Code — описывает реализацию на уровне классов и модулей (используется редко).

Этот подход позволяет гибко визуализировать систему, адаптируя уровень детализации под конкретную аудиторию: от бизнес-аналитиков до разработчиков.

🔹 Примеры использования
📌 На этапе проектирования: для утверждения архитектуры с командой.
📌 При разработке: чтобы упростить взаимодействие между командами.
📌 Во взаимодействии с заказчиком: помогает объяснить структуру проекта простыми схемами.
📌 В документации: делает систему прозрачной для новых сотрудников.

🔹 Как создавать диаграммы C4?
📌 Draw.io — удобный инструмент для графического создания диаграмм.
📌 Structurizr — генерация C4-схем через код, удобно для автоматизации.
📌 Miro, Lucidchart — подойдут для совместной работы с командой.

#ARCHITECTURE

🛠 Postman для тестировщиков: основы и автоматизация

Postman — это удобный инструмент для работы с API, который позволяет тестировщикам 📌 отправлять запросы, проверять ответы, автоматизировать тестирование и интегрировать проверки в CI/CD. Он поддерживает REST, SOAP, GraphQL, работает на всех ОС и позволяет легко управлять переменными и окружениями.

🔍 Основные возможности
✅ Отправка запросов и анализ ответов
✅ Использование коллекций и переменных
✅ Автоматизация тестирования с Collection Runner
✅ Запуск тестов по расписанию ⏳
✅ Интеграция с CI/CD через Newman

📜 Создание тестов
Вкладка Tests позволяет автоматически проверять ответы сервера. Например, проверка статуса ответа:

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

Или проверка содержимого ответа:

pm.test("Response contains campaign name", function () {
    pm.expect(pm.response.text()).to.include("Campaign TEST");
});

🔄 Использование переменных
Переменные помогают передавать данные между запросами 🔗. Например, сохранить auth-токен для последующего использования:

var jsonData = pm.response.json();
pm.environment.set("authToken", jsonData.token);

Также можно передавать ID созданного объекта:

pm.environment.set("campaignID", jsonData.id);

Переменные бывают глобальные, окружения, локальные и из файлов (CSV, JSON) 📂.

🚀 Автоматизация с Collection Runner
📌 Можно запускать коллекции запросов в нужном порядке, задавать количество итераций и запускать тесты по расписанию.

🤖 ChatGPT vs DeepSeek: Битва AI-титанов для системных аналитиков

Сегодня разберем, какая нейросеть лучше справится с вашими задачами: OpenAI ChatGPT или китайский DeepSeek. Мы устроили им экзамен — от математики до философии.

🔍 Ключевые отличия моделей
1. DeepSeek-R1
- Локальное развертывание Ollama — полный контроль над данными.
- Фишки: Может «мыслить» на китайском (даже в русских ответах), но требует мощного железа (например, NVIDIA A100).
- Пример: Лучше справилась с неочевидными задачами (например, генетикой: дала ответ 12.5%, хотя правильный — 25%).

2. ChatGPT (4o и o1)
- Скорость: Быстрее генерирует ответы.
- Креатив: Сильнее в творческих заданиях (например, стихи про Тирекса).
- Ограничение: Только облачная версия.

🚀 Практические выводы для системных аналитиков
- Для работы с конфиденциальными данными выбирайте DeepSeek-R1 (локальный запуск через Ollama).
- Для быстрых ответов и креатива — ChatGPT 4o.
- Для анализа требований и документов обе модели справляются, но DeepSeek лучше сохраняет контекст.

💡 ТОП-3 примера из интервью
1. Математика:
- Вопрос: 2 + 2 * 2 = ?
- ChatGPT 4o: 6 (с пояснением).
- DeepSeek-R1: 6 (с юмором: «Если бы не правила, было бы 8»).

2. Химия:
- Вопрос: Константа гидролиза NH4NO2.
- ChatGPT o1: 3.9×10⁻² (близко к истине).
- DeepSeek-R1: 1.2×10⁻⁶ (правильный ответ — 1.23×10⁻⁶).

3. Креатив:
- Задание: Рассказ-утопия только на буквы Г, Р, К.
- ChatGPT o1: Мини-роман про экогород.
- DeepSeek-R1: «Город Радость. Граждане растили розы...» 🌹

📌 Итоги
- DeepSeek выигрывает в безопасности и кастомизации.
- ChatGPT — для скорости и творчества.
- Совет: Тестируйте обе модели на своих кейсах (например, парсинг требований или генерация документации).

#AI