Это перевод первой части статьи. Статья была написана в 2008 году. Спустя 10 лет почти не потеряла актуальности.

Детерминированное освобождение ресурсов — необходимость

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

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

Угадайте какой рекомендации не следует рантайм .NET, и как следствие все языки на его базе?

В рамках рабочих задач недавно мною было проведено небольшое исследование на тему целесообразности использования опции prefetchCount при работе с брокером сообщений RabbitMQ.
Хочу поделиться этим материалом в виде слайдов и комментариев к ним.

Тесты проводились на конкретном проекте, но в целом они справедливы для большинства случаев, где обработка сообщений (выполнение задач) занимает хоть сколько-то существенное время (при обработке менее 1000 сообщений в секунду).

* на слайдах вместо слова «подписчик» используется «консумер», в комментариях для единообразия тоже
* рассматривается отдельно взятая очередь с пятью консумерами (C1..C5)

Идеальные условия

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

Однако, как только у нас появляется отдельная система для хранения очереди сообщений (мы используем RabbitMQ), сразу возникают проблемы с транзакционностью. Например, если мы хотим сохранить в БД отметку о том, что мы отправили сообщение в Rabbit, не так уж и просто гарантировать, чтобы отметка была сохранена только в случае успешной отправки сообщения. О том, как мы справлялись с этой проблемой читайте под катом.

Впервые я услышал о библиотеке MassTransit (MT) около года назад от экс-коллеги, зашедшего в наш офис для обмена опытом. Компания, в которую он устроился, использовала MT для уменьшения связности между модулями разрабатываемого ими сервиса и, поскольку высокая связность начала превращаться в проблему и для нас, чужой опыт оказался нам очень кстати. Помимо уменьшения связности путем перехода на событийную модель взаимодействия между модулями, MT пригодился нам и для распределения ресурсоемких задач между несколькими процессами.

Знакомимся с RabbitMQ

Переводы на хабре:
RabbitMQ tutorial 1 — Hello World
RabbitMQ tutorial 2 — Очередь задач
RabbitMQ tutorial 3 — Публикация/Подписка

Сразу дополню некоторые недочеты. И кратко повторю основные термины.

Принцип работы архитектуры использующей rabbitMq

Почти в самом начале создания платформы (некоего фундамента, фреймворка на котором базируются все прикладные решения) нашего облачного веб-приложения СБИС мы поняли, что без инструмента, позволяющего сообщить пользователю о каком-либо событии с сервера, жить будет довольно-таки трудно. Все мы хотим мгновенно видеть новое сообщение от коллеги (которому лень пройти 10 метров), поднимающую корпоративный дух новость от руководства, очень важную задачу от отдела тестирования или получение поощрения (особенно денежного). Но путь становления был тернист, поэтому расскажем немного про трудности, которые мы встретили при взрослении от 5.0e3 до 1.0e6 одновременных подключений от пользователей.

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

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

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

После авторизации и создания ПИН-кода, аутентификацию пользователя можно переложить на плечи Windows Hello. Общая последовательность необходимых действий выглядит следующим образом:

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

Давайте рассмотрим каждый шаг подробнее на примерах кода.

Обработка событий — одна из самых распространенных задач в области бессерверных технологий. Сегодня расскажем о том, как создать надежный обработчик сообщений, который сведет к нулю их потерю. Кстати, примеры написаны на C# с использованием библиотеки Polly, но показанные подходы будут работать с любыми языками (если не указано обратное).

Представьте ситуацию. Субботний вечер. Вы — администратор PostgreSQL, после тяжелой трудовой недели уехали на дачу за 200 км от любимой работы и чувствуете себя прекрасно… Пока Ваш покой не нарушает смс от системы мониторинга Zabbix. Произошел сбой на сервере СУБД, база данных с текущего момента недоступна. На решение проблемы отводится короткое время. И Вам ничего не остается, как с тяжелым сердцем оседлать служебный гироскутер и мчаться на работу. Увы!


А ведь могло быть по-другому. Вам приходит смс от системы мониторинга, что произошел сбой на одном из серверов. Но СУБД продолжает работать, поскольку отказоустойчивый кластер PostgreSQL отработал потерю одного узла и продолжает функционировать. Нет надобности срочно ехать на работу и восстанавливать сервер БД. Выяснение причин сбоя и работы по восстановлению спокойно переносятся на рабочий понедельник.

Как бы то ни было, стоит подумать о технологиях отказоустойчивы кластеров с СУБД PostgreSQL. Мы расскажем о построении отказоустойчивого кластера СУБД PostgreSQL с помощью программного обеспечения Pacemaker&Corosync.

Шестая встреча Sync.NET-комьюнити уже ждет вас, друзья! А вместе с ней и крутые доклады, общительные и опытные спикеры, подарки и подарки-поступки, а также бесконечный запас вкуснейшего кофе и угощений :).

Друзья, чуть больше месяца назад завершился коммитфест и стало понятно, какими новыми возможностями нас порадует осенний релиз PostgreSQL. Мы уже начали рассказывать об INCLUDE-индексах, встроенном веб-поиске, улучшениях в кастинге.

И теперь совместно с компанией «Райффайзенбанк», мигрировавшей на PostgreSQL ряд систем, мы решили провести открытый митап по новым фичам в PostgeSQL 11.

Ждем вас 23 мая в 18.00 в Нагатинском офисе Райффайзенбанка по адресу Москва, проспект Андропова 18, корпус 2.

Вход бесплатный. Регистрация на сайте.

Сообщество .Net разработчиков Райффайзенбанка приглашает на первый открытый митап, который пройдет 7 июня на территории московского офиса в Нагатино.

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


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

Примерно такие же эмоции я и мои коллеги испытывали, когда начинали работать с Docker. В подавляющем большинстве случаев это происходило от недостатка понимания основных механизмов, поэтому его поведение казалось нам непредсказуемым. Сейчас страсти поутихли и вспышки ненависти происходят все реже и все слабее. Более того, постепенно мы на практике оцениваем его достоинства и он начинает нам нравиться… Чтобы снизить степень первичного отторжения и добиться максимального эффекта от использования, нужно обязательно заглянуть на кухню Docker'a и хорошенько там осмотреться.

На момент появления в Apache Software Foundation проекта Ignite он позиционировался как чистое in-memory-решение: распределенный кэш, поднимающий в память данные из традиционной СУБД, чтобы выиграть во времени доступа. Но уже в релизе 2.1 появился модуль встроенной персистентности (Native Persistence), который позволяет классифицировать Ignite как полноценную распределенную базу данных. С тех пор Ignite перестал зависеть от внешних систем обеспечения персистентного хранения данных, и вязанка граблей конфигурации и администрирования, на которые не раз наступали пользователи, исчезла.

Однако persistent-режим порождает свои сценарии и новые вопросы. Как предотвратить неразрешимые конфликты данных в ситуации split-brain? Можем ли мы отказаться от перебалансировки партиций, если выход узла теперь не означает, что данные на нем потеряны? Как автоматизировать дополнительные действия вроде активации кластера? BaselineTopology нам в помощь.

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

В этой статье мы рассмотрим, каким образом можно наблюдать за работой продукта и его боевым окружением, научимся собирать жизненно необходимые метрики и представлять их в удобоваримом виде. Узнаем, что такое Time Series и как они могут помочь нашим и сторонним приложениям в процессе диагностики. Подробно познакомимся с лидерами рынка инструментов для мониторинга, специализированным хранилищем InfluxDB и системой визуализации данных Grafana.

Прототипом статьи является доклад Анатолия Кулакова на DotNext 2017 Moscow. Анатолий получал образование специалиста по информационной безопасности, затем зарабатывал как суровый C++ разработчик под Linux. Когда надоело кодировать и захотелось творить, перешёл на C#. Пишет на .NET с первых его версий. Занимается проектированием и построением бизнес-приложений, распределённых и отказоустойчивых систем. Отдыхает с ES, CQRS и DDD.

Перед просмотром можно загрузить слайды в формате PDF.

Осторожно, трафик! В этом посте присутствует огромное количество картинок — слайдов и скриншотов с видео в формате 720p. На слайдах присутствует важный для понимания статьи код.

В основе этой статьи доклад Дениса Иванова (@DenisIvanov) на РИТ++ 2017, в котором он поделился опытом разработки и запуска в продакшен REST-сервиса на ASP.NET Core на Kubernetes. На текущий момент это сделать уже можно без особенных проблем и бояться использовать .NET Core, судя по опыту 2ГИС, не стоит.

Конфигурация: ASP.NetCore на Linux позволила не только использовать существующую on-premise платформу, но и принесла еще несколько дополнительных плюсов, в частности, в виде полноценных Docker и Kubernetes, которые сильно упрощают жизнь.

О сервисе

С 1 апреля 2017 года в продуктах 2ГИС появилась иконка, на которую можно нажать и начнет проигрываться видео. Рекламодатели, которые размещаются в справочнике, теперь могут купить новый способ размещения рекламы, а все продукты нашей компании (мобильные, онлайн, API), ходят на сервис, про который я буду сегодня рассказывать.

Топология этого сервиса примерно представлена на картинке ниже. Сервис помечен облачком в центре, он, по сути дела, является бэкендом для продуктов. Когда продукт приходит и говорит: «Дай мне для этого рекламодателя всю информацию о видеорекламе», сервис ему послушно ее отдает. Это информация такого плана: такая-то обложка лежит на таком-то CDN, такой-то видеофайл в таких-то разрешениях лежит там-то и там-то, само видео длится такое количество времени и прочее.


Осторожно: много информации и кода.