Асинхронный транспорт Cassandra

Cassandra является основным хранилищем (мета)данных в Одноклассниках. Там развернуты сотни высоконагруженных кластеров из сотен узлов и тысяч клиентов, распределенных по нескольким дата-центрам. Они используют и активно развивают собственный форк Cassandra 2.x. Помимо фиксов множества багов и многочисленных оптимизаций, они реализовали глобальные индексы (которые работают), поддержали партиционированные транзакции (NewSQL), полностью автоматизировали эксплуатацию в production и многое другое. Но в этом докладе Вадим сконцентрируется на подходе FatClient, который используется в их системах повсеместно.

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

В докладе подробно рассматривается собственная реализация асинхронного транспорта Cassandra, которая позволила существенно сэкономить ресурсы и упростить жизнь разработчиков. Новый транспорт основан исключительно на Java SDK и лаконичной, но эффективной реализации Actor Model. Помимо устройства самого решения, Вадим расскажет про различные оптимизации, возникшие по пути проблемы, а также переключение на асинхронный транспорт нагруженных кластеров Cassandra в production.

Опыт и идеи, представленные в докладе, могут быть полезны как сетевым разработчикам, так и разработчикам высоконагруженных распределённых систем на Java.