Записки программиста

Успешно ассимилировал очередную пачку литературы. В этот раз мой выбор пал на подозрительно большое количество книг о всяких там Cassandra, Kafka и прочих Couchbase’ах, а также парочку книг о современном С++. Другие мои рецензии на прочитанные книги вы найдете здесь: десятый десяток, девятый десяток, восьмой десяток, седьмой десяток.

Согласно официальному описанию, Finagle — это расширяемая RPC система для JVM, используемая для построения «сильно многопоточных» (high-concurrent, что бы это ни значило) сервисов. Finagle изначально был создан ребятами из Twitter, но сейчас успешно применяется и в Foursquare, Pinterest, SoundCloud, Tumblr, а также ряде других компаний. В этой заметке мы познакомимся с основами использования Finagle, создав с его помощью очень простой REST-сервис.

Вы, наверняка, знаете, как это бывает. Ой, у нас тут такие тяжелые вычисления / так долго тянутся данные из базы. А давайте просто прикрутим кэшик. Что может пойти не так? Так вот, опыт показывает, что пойти не так может очень и очень многое.

Пожалуй, основной областью применения Go на сегодня является написание серверных приложений. А их трудно представить в отрыве от какой-нибудь базы данных. В этой заметке я опишу создание простой телефонной книги с интерфейсом командной строки и PostgeSQL в качестве хранилища.

Клиенты нередко приходят в наш сервер сайд или вебчик через какие-то прокси, Nginx, HAProxy, Elastic Load Balancer и другие. Прокси эти очень полезны, так как обеспечивают сжатие и шифрование трафика, балансировку нагрузки и так далее. Проблема однако заключается в том, что прокси скрывают настоящий IP пользователя, из-за чего становится невозможно определить, например, из какой страны он пришел, и соответственно, интерфейс на каком языке ему отобразить. В случае с HTTP эта проблема давно решена путем проставления заголовков с IP пользователя. Но что делать при использовании других протоколов, вебсокетов там или просто чего-то самописного поверх TCP? Вот для решения именно этой проблемы разработчиками HAProxy и был придуман proxy protocol.

В этом выпуске: находим неиспользуемые jar’ники и прикручиваем таймауты к футурам, находим правильную IDE для Haskell, выбираем SaaS для агрегации логов, замораживаем Docker-контейнеры, а также другие интересные ссылки. Предыдущие выпуски: март 2015, февраль 2015, январь 2015, декабрь 2014.

Как вы можете помнить, в мире Java есть такая штука под названием type erasure. Мы сталкивались с ней, когда в первый раз пробовали работать с JSON в Scala. Суть проблемы заключается в том, что во время выполнения программы нельзя узнать точный тип генериков, так как информация о типах, которыми они были параметризованы, теряется на этапе компиляции. Вызвано это в основном историческими причинами, так как генерики появились только в Java 1.5, но в какой-то степени, наверное, это также можно считать и оптимизацией. К счастью, в Scala это ограничение можно легко обойти, воспользовавшись TypeTags.

Во многих серверных приложениях часто возникает необходимость кэшировать какие-то данные, так как количество тактов процессора ограничено, хождение в базу по сети занимает ощутимое время, да и пулы коннектов не резиновые. Сделали кэши, все хорошо. Но как только ваше приложение начинает работать более, чем на одном сервере, возникает проблема инвалидации кэшей. Когда пользователь пишет какие-то данные через один сервер, требуется обновлять или сбрасывать кэши на всех остальных серверах. Отчасти проблему позволяет решить Memcached, но с ним другие проблемы — (1) неизбежные накладные расходы на хождение по сети и (2) не всегда понятно, как сделать так, чтобы данные в кэше не разъехались в граничных случаях типа нетсплитов и поднятия новых кэш-серверов. Оказывается, что Akka Cluster из коробки предлагает довольно интересное решение озвученных проблем.

Я не мог не заметить, что читателей сего блога очень заинтересовала тема «нужно ли давать котикам играться с новыми клубочками». Поэтому хотелось бы поделиться еще кое-какими своими мыслями по связанной теме, в отношении языков Си и C++ и убьет ли их Rust. Тема, как вы сами понимаете, очень-очень холиварная, поэтому подумайте еще раз, хотите ли вы читать эту заметку дальше и тем более участвовать в «конструктивном обсуждении» поста при помощи комментариев.

ElastiCache — один из множества сервисов в Amazon, который дает облачные Memcached и Redis. Дает не просто так, а с автоматической заменой упавших нод, а также со специальным клиентом, который определяет состав созданного кластера и ходит на различные его узлы в зависимости от значения ключа. То есть, получается что-то вроде EC2 инстансов с поднятым Memcached или Redis на них в автоскейлинг группе за ELB, только с шардированием и уже готовое. В этой заметке мы научимся настраивать Amazon ElastiCache и ходить в него из кода на языке Scala.