Очереди – что сложного то?

Знание и понимание очередей очень важно для разработчика. Очереди обеспечивают распределение ресурсов, репликацию сообщений, отказоустойчивость, надёжность передачи, гарантию доставки и коммуникацию микросервисов.

Подождите, очередь – это когда с одной с стороны положили, а с другой стороны кто-то забрал? Почти, но всё немного сложнее. Особенно в распределённых системах, особенно когда сообщений десятки тысяч в секунду.

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

Начинается всё с базовых понятий, какие вообще бывают способы организации очередей: put/take, pub/sub, request/response.

Для применения очередей существует множество инструментов.
– Apache Kafka реплицируемый шардируемый лог сообщений для стриминга. Мы кафку очень любим, и о ней были отдельные посты (раз, два)
– RabbitMQ – традиционный pub/sub broker. В отличие от Kafka, у кролика нет ограничений на количество потребителей. Кролик часто используется как шина данных между сервисами
– NATS обеспечивает быстрый неперсистентный обмен сообщениями, высокую производительность и масштабируемость
– Tarantool – это in-memory db, которая может быть использована для организации очередей. Примечателен тем, что можно написать свою очередь на стероидах, со своим процессингом, логикой и приоритетами

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

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

Говоря о проблемах – они у очередей есть.
– на уровне алгоритма важно решить, что делать при отказе консьюмера, который уже взял сообщение. Best Effort – просто вернуть сообщение обратно. Но не во всех брокерах так можно. В таком случае можно настроить dead letter queue – отдельную очередь со своей логикой обработки таких сообщений.
– а ещё бывают проблемы приоритизации, когда из-за множества задач с высоким приоритетом консьюмер может никогда не добраться до задач с низким.
– на сетевом уровне существует undefined behavior, то есть сообщение отправлено, но мы не знаем, оно дошло и получено или потерялось
– помимо сети есть диск, который влияет на пропускную способность и задержку в обработке, которая может оказаться не предсказуемой

Чтобы обеспечить доступность (avalability) и надёжность (durability) применяются разные топологии:
– single instance – самый простой вариант. Один брокер, одна очередь, продюсер и консьюмер. Немасштабируемо, низкая доступность и надежность.
– multi instance – можно масштабировать и ставить столько очередей сколько нужно. С надежностью и доступностью получше, но если одна из очередей грохнется, то данные из нее потеряются.
– идём дальше и дублируем уже сами очереди
– автор не останавливается на этом и рассказывает о реплицировании, реплика-сетах, кворумах, кворумных очередях.

Познакомившись с различными сложностями понимаешь, что хорошо бы всё это мониторить. Существуют следующие метрики: размер очереди, время обработки сообщения, количество потерь и отказов.

И всегда нужно быть готовым к самому худшему – к падению. Для этого существуют политики отказа, например, можно отказаться от приёма новых сообщений. Если нельзя, то можно уничтожать старые сообщения и продолжать принимать новые. Как вариант, когда часть сообщений ещё живая, а часть старая, можно попробовать обрабатывать живые, а потом вернуться к старым.

Напоследок ценная мысель: если вы не знаете, как ваша система падает и поднимается, быстро вы её не поднимите.

#skills

Backup: февраль

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

Архитектура проекта и деплой
Design distributed cache
Стратегии деплоя
GitOps – все ли так классно?
За всё хорошее, против всего плохого

Важные инструменты
Практикуем Kubernetes
Как kafka хранит данные
Очереди – что сложного то?
Нестареющая классика, шпаргалка по SSH

Интересное по Python
Многопоточный Python на примерах: избавляемся от дедлоков
Мемоизация и каррирование в Python
Введение в logging на Python

Подготовка в собеседованиями
Правильная структура ответа на собеседовании
Как сдвинуть гору Фудзи
Подготовка к интервью в Тинькофф

PostgreSQL
Буфферный кеш в PostgreSQL
NULL в PostgreSQL

Нетехнические навыки:
Моё разочарование в софте
The Lesson to Unlearn — Вредные уроки от Пола Грэма
Упрощаем жизнь руководителю

Необычное для нас: You Suck at Excel with Joel Spolsky

Если пропустили, то подборка за январь

#backup

Пятничное развлекательное

Почему я идиот. Чудесный клип Александра Пушного, созданный на основе интернет-запросов пользователей почти 10 лет назад.

Пушного я люблю за многое. И старая-добрая программа Галилео, и Апож. Кстати, забавный факт из интервью Пушного — руководители хотели убрать детей от Галилео, и Пушной добавил брутальности. А детям зашло, и программа стала очень популярной среди детей и взрослых. В пандемию Пушной записал приятные rock-титры к Галилео.

Пушной был камео в обзоре BadComedian, о чём есть тоже забавная история. А совсем в старые времена Пушной выступал в КВН в роли Стинга. Приходите в комменты с ностальгией :)

#fun

Постигаем gRPC

Классический вариант межсервисного взаимодействия – REST. Но есть альтернативы, например, gRPC.

В своём докладе ребята из Яндекса рассказывают об опыте применения gRPC. Сначала, конечно, о проблемах, которые хотелось бы решить. Не просто же так тащить новую технологию в прод.

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

Далее автор переходит непосредственно к gRPC и рассказывает, как именно эти хотелки удовлетворяются.
На практическом примере показывает реализацию unary call – классического запроса/ответа и streaming для длительного соединения. Если с unary call всё ясно, то streaming может быть полезен для скачивания и загрузки больших сообщений частями или для отправки серверных пушей.

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

Если первая статья больше концептуальная, то для любителей питона есть замечательное практическое руководство Python Microservices With gRPC. Можно брать и делать. Сначала рассматриваются теоретические вопросы микросервисов, gRPC, когда применять. Далее практика – реализация микросервиса, деплой и тестирование. В конце приводится набор практик, которые стоит применять при использовании gRPC.

#skills

Микросервисы. Очередное рассуждение

В последнее время активно исследую вопросы, связанные с микросервисной архитектурой. Наткнулся на статью-рассуждение Микросервисы и неизбежная боль?

Автор начинает с того, что сам термин "микросервис" неоднозначен и приводит разные определения. Я с ним согласен. Думаю, что чересчур много внимания уделяется микро. Мне же нравится обобщённое определение, что микросервисная архитектура – это стиль проектирования, который разбивает приложение на отдельные сервисы с разными функциями. И важно, что в нём ни слова о размере.

Далее по классике микросервисы сравниваются с service-oriented architecture (SOA) и монолитом. Тут нет ничего нового. Выделю отличия микросервисов от SOA:
– в SOA, как правило, сервис – это крупное монолитное приложение. Возможно, даже ставшее отдельным сервисом не по архитектурной задумке, а в силу исторических причин
– в SOA используется глобальная модель данных и общая БД
– в SOA для межсервисного взаимодействия используются умные и тяжеловесные протоколы вроде SOAP

Доходим наконец-то до боли, обозначенной в заголовке. Автор говорит о том, что часто видел:
– огромное количество разрозненных, отличающихся друг от друга репозиториев, созданных разными людьми
– большие усилия на поддержание обратной совместимости api, невозможность определить во всем зоопарке сервисов, кто это api использует и нужно ли оно вообще
– размывание технологического стека среди команд и сервисов, разные системы сборки и деплоя
– новые сервисы на каждый чих, дублирование кода

Что ж, у меня двоякое отношение к сказанному. Могу лишь сделать вывод, что любую архитектуру можно испортить. Ничего удивительного, микросервисы – не золотая пуля, они несут в себе набор проблем и ограничений. Важность перечисленных проблем в том, что о них нужно знать заранее, тщательно отслеживать и вовремя реагировать. Предупрежден – значит вооружён.

Возвращаясь к проблемам, для организации микросервисной архитектуры должны быть выстроены процессы и инженерная культура, созданы шаблонные сервисы, особое внимание должно уделяться CI/CD и observability.

Рассуждая о золотой середине, автор даёт, как мне кажется, вредные советы. Всё сводится к тому, что делаем условно монолитно, но, когда понадобится, легко сможем разбить на микросервисы. Предлагается использовать единый репозиторий с делением на директории посервисно, одну базу данных без связей между таблицами разных сервисов.

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

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

#skills

ngrok

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

Для этого есть замечательная утилита ngrok. Одна команда и готово.

У ребят всё сделано по-человечески – можно поднять в докере и настроить end-to-end шифрование. На этом возможности не заканчиваются. Есть качественная документация, можно узнать, как воплотить в жизнь самые разные хотелки.

Не пугайтесь раздела pricing на сайте. Для подобного базового использования – всё бесплатно.

А чтобы объединить разные устройства на хозяйстве в одну сеть и иметь отовсюду к ним доступ, пользуюсь еще одной замечательной утилитой tailscale. Примечательно, что у ребят тоже хорошая документация и блог, где они описывают различные хитрые сценарии применения. Например, как кодить на айпаде в vscode.

#tools

Следим за Postgres

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

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

Для отслеживания размера БД автор приводит запросы для получения:
– размера табличных пространств
– размера базы данных
– размера схем в базе данных
– размера таблиц

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

Для отслеживания блокировок автор приводит запрос для получения заблокированных запросов и снятия блокировок.

Для отслеживания эффективности можно узнать:
– коэффициент кеширования, показывающий долю чтения из кеша по сравнению с общим количеством операций чтения как с диска, так и из кеша
– процент времени использования индексов по сравнению с чтением данных без индексов и, таким образом, найти кандидатов на добавление индекса
– наоборот, неиспользуемые индексы
– величину раздувания базы. Это когда дисковое пространство использовалось таблицей или индексом, доступно для повторного использования, но не было освобождено. Для решения этой проблемы есть команда VACUUM.
Также среди полезных запросов автор приводит получение:
– количества открытых подключений
– выполняющихся запросов и их длительность

Рекомендуем также заглянуть в комментарии, там делятся интересным опытом. Например, запрос для отладки блокировок. Или совсем специфичное – запрос, который позволит прикинуть сколько занимает одна запись на диске.

#skills #database

Teamlead roadmap

В разработке нужны не только разработчики. В зависимости от размера, для проекта могут требоваться тимлид, CTO, PM и ещё десяток разных аббревиатур. Чёткого деления по задачам нет, и в разных компаниях разное видение ответственности каждого из работников. И один человек может брать одновременно тимлидом и CTO.

В итоге тимлиды в команде часто выполняют достаточно уникальный набор задач, являющийся миксом из множества ролей. В предлагаемом роадмапе детализированы личные навыки тимлида и различные управленческие роли:
– administrator, ответственный за управление циклом разработки проекта
– integrator, понимающий потребности бизнеса и его долгосрочной стратегии, способный донести эти потребности до команды
– people manager, занимающийся людьми, организацией работы команды в самом широком смысле включая найм, мотивацию, поддержку процесса работы и увольнения
– product owner, способный стратегически мыслить в рамках продукта
– technical lead, стратегически отвечающий за техническую часть

Каждое из направлений состоит из множества навыков. По большинству навыков есть подробное описание и дополнительные материалы для изучения, статьи и книги. Например, мы обсуждали code review из роли technical lead.

Топовый роадмап для разработчиков был раньше.

#edu

Пятничное развлекательное

Есть такое хобби – экстраполировать. В шуточной статье Python 3.14 Will be Faster than C++ демонстрируется результат бенчмарка производительности питона от версии 3.5 до версии 3.11. Изложение приправлено изрядной долей юмора, have fun.

#fun

Работаем с аудиторией на выступлении – TEDx

Вы уверены, что лучше всего использовать технологию А, но команда планирует использовать технологию Б. Сможете ли вы донести свою мысль до коллектива?

Выступить даже на митапе для несколько человек непросто. А от качества выступления зависит степень донесения мыслей. Недостаточно быть просто правым, надо хорошо донести мысль и увлечь людей за собой. Если посмотреть шире, то площадки бывают разные:
– люди на конференциях делятся результатами, технологиями и опытом
– бизнес презентует что-то новое, можно вспомнить WWDC от Apple
– преподаватель на лекциях доносит знания

Для создания хорошего выступления нужен опыт, и с этим всё сложно. Мы не встречали годного материала про выступления. Поделимся своими мыслями. Как обычно, следует тянуться за лучшими практиками.

TED (technology, entertainment, design) – это известный организатор крутых конференций, и у него есть дочерний проект TEDx. TEDx создаёт локальные конференции в стиле TED.

В коротком видео How to use one paper towel докладчик рассказывает о важности экономии бумажных полотенец для сохранения деревьев. Предлагается простая схема – 12 раз стряхнуть влагу с рук (shake), после чего сложить полотенце вдвое (fold) и вытереть руки им. Очень круто поставлено взаимодействие с аудиторией – половина зала по указанию выступающего повторяет shake, вторая половина fold.

Выступление построено классически:
– формулировка проблемы
– презентация решения, обоснование и сравнение результатов
– связь результатов с проблемой

Внутри презентации решения много интересного:
– оценка результата "даже с одним полотенцем руки сухие"
– рассмотрение вариантов на примере "почему именно 12"
– шутки для повышения внимания к докладу
– технические внутренности "interstitial suspension" для демонстрации важности складывания полотенца вдвое
– пример из жизни "получить половинку полотенца из автоматического диспенсера"

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

У вас есть любимые TEDx-выступления?

#edu

Проектируем БД в DB Designer

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

Для себя давно нашел такой инструмент – DB Designer.

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

Если пользуетесь чем-то подобным – делитесь в комментариях.

#tools

Делай нейминг как сеньор

Все мы знаем, что нужно правильно и понятно именовать переменные. Правильно, понятно – а это как?

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

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

Неправильно именование приводит к неправильному пониманию, а дальше – к некорректному использованию.

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

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

Заканчивается статья набором конкретных практических советов, которые можно брать и применять.

#procode

Пятничное развлекательное

Захватывающее пятничное чтиво INSIDE PORNHUB о внутренней кухне от лица бывшего сотрудника.

Быстрый рост компании, конфликты внутри индустрии. Проблемы, с которыми сталкивались и как решали. Особое внимание уделяется тому, как модерировался контент.

Почитайте, очень любопытно :)

#fun

Итерируем всякое

Статья с кликбейтным названием – 10 итераторов, о которых вы могли не знать и реально интересным содержанием.

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

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

Из действительно любопытного отметим:
– iter может принимать два аргумента. Второй аргумент – элемент, на котором будет сгенерировано исключение StopIteration
– можно итерироваться по стандартному потоку ввода. Объект stdin итерируемый
– можно итерироваться по содержимому каталога. В модуле pathlib есть итератор iterdir
– можно итерироваться по строкам csv-файла, применив функцию iter к объекту csv_reader

Итераторы окружают питонистов. Даже если постоянно используете Python в профессиональной деятельности, найдете что-то интересное. Статья исключительно практическая. Бери и используй.

#python

Где бы ещё сохранить данные?

Greenplum – распределённая база данных на основе postgres с открытым исходным кодом.

Статья Introduction To Greenplum Architecture будет отличным введением для понимания, что это за зверь такой.

Автор начинает с довольно скучного введения, так что сразу переходите к разделу Greenplum Overall Architecture.

По сути, Greenplum – это кластер баз данных, состоящий из отдельных Postgres. Кластер состоит из:
– master-ноды, которая является входной точкой для всей БД и обеспечивает единый интерфейс для взаимодействия с кластером
– standby-ноды – резервного мастера для обеспечения высокой доступности
– нескольких segment-нод – рабочих лошадок, где хранятся и обрабатываются данные

Статья расскажет, как это всё вместе взаимодействует. Затрагиваются вопросы:
– физической организации хранения данных
– порядка и способов взаимодействия всех участников кластера
– выполнения запросов с различными джоинами
– обеспечения атомарности и изоляции
– механизма двухфазного коммита для подтверждения распределённых транзакций

Вводная статья, конечно, не расскажет о практическом применении гринплама и не подсветит проблемные места. Чтобы изучить, как эта махарайка применяется на практике, рекомендуем прочитать статью Как мы используем Greenplum в платформе данных Тинькофф

#skills #database

Как ускорить приложение на FastAPI

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

Отличная практическая статья, показывающая, как можно ускорить своё приложение. Примеры из статьи выложены на github, поэтому можно потрогать ручками.

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

Рассматриваются:
– многопоточность
– асинхронность
– redis для кеширования

А в качестве бонуса – статья о KeyDB, интересной альтернативе привычному всем редису, на которую стоит посмотреть.

#python

Пятничное развлекательное

Уже давно существует тренд на механические клавиатуры. Приятный звук, тактильные ощущения. Хочется стукать по ней всеми пальчиками. Но, даже если механической клавиатуры нет, в интернете всегда есть кто-то неправый и хочется побыстрее ему объяснить.

monkeytype – замечательный сервис, с отличным дизайном где можно позалипать и потренировать слепую печать.

#fun

Реверс инжиниринг для самых маленьких на практике

Не ограничиваем область своих интересов только разработкой, поэтому совместно с нашим хорошим другом и подписчиком подготовили статью на тему реверса.

В статье мы берём все наши скромные знания, дизассемблер, несложную задачку и идём в бой.

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

Если посматривали на реверс, но не знали с чего начать – велкам.

#devfm

Комментарии в маркдауне

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

На нашей практике часто приходится работать с маркдаун-файлами. И, порой, тоже хочется оставить комментарий, чтобы это не влияло на внешний вид документа.

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

<!-- Этого текста в режиме просмотра не будет видно. --> – проверено в gitlab, github и pycharm.

Конечно, вводить каждый раз вручную эту конструкцию не нужно, везде есть горячие клавиши.

В ворде удобно итерироваться по комментариям, а так как конструкция для <!-- достаточно уникальная, то можно просто ввести её в поиске и также итерироваться по найденным совпадениям.

Оказалось очень удобно, когда ревьюили статью на хабр по реверсу.

#edu

Airflow или что-то ещё?

Если у вас есть много разных обработчиков данных со сложной логикой, каждый из которых надо периодически запускать и мониторить, то удобным средством оркестрации этого зоопарка будет Apache Airflow.

Airflow — это такой cron на ультра-стероидах.

Статья Как мы оркестрируем процессы обработки данных с помощью Apache Airflow и доклад Как решить проблемы оркестрации сотен задач по обработке данных с помощью Apache Airflow будут отличным введением в тему. Помимо знакомства с технологией и её основными концепциями, ещё можно узнать, для чего её применяют на практике и с какими проблемами сталкиваются.

Несмотря на то, что airflow — достаточно разухабистая штука, её можно развернуть у себя локально и попробовать разные сценарии использования, руководствуясь туториалом в документации и примерами.

У себя на проекте мы прорабатываем вопрос использования чего-то подобного. Рассматриваем airflow и prefect. Конечно, ещё есть соблазн написать свой велосипедик, но, думаю, сможем удержаться.

Кто что использовал? Для каких задач? Помимо комментариев к постами у нас есть чат канала – залетайте.

#skills

Пятничное развлекательное

Казалось бы, скроллбар и скроллбар, что в нём такого. Нашли прикольный сайт Evolution of the Scrollbar, где продемонстрирована история развития этой незамысловатой штуки.

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

И на всякий случай: горизонтально скроллить можно с помощью shift+колёсико мышки.

#fun