Меня зовут Андрей Комягин, я СТО компании STM Labs. Мы занимаемся разработкой очень больших распределённых высоконагруженных систем для различных отраслей и в своей работе широко используем open-source решения, в том числе СУБД Redis. Недавно я подробно рассказывал об этой системе на конференции Saint HighLoad++, а теперь с удовольствием поделюсь основной информацией с читателями Хабра. Итак, поехали.
Tech lead
Настройка Git сервера с нуля
Любой начинающий DevOps начинает своё знакомство с Git. Этот инструмент стал неотъемлемой частью рабочего процесса разработчиков по всему миру. Во многих курсах и руководствах по DevOps описывается настройка серверов через популярные платформы, такие как GitLab, а иногда и Gitea. Однако мне стало интересно попробовать другой путь — использовать встроенный в Git инструмент GitWeb.
Оптимизация бэкенда приложения с примерами на Symfony. Часть 2
Всех приветствую!
Это продолжение серии статей, где мы рассмотрим еще несколько методов, которые помогут улучшить производительность приложения. Мы поговорим о том, как использовать entity manager, unit of work, bulk inserts и batching processing для более эффективной работы с базой данных.
Напомню, что я написал приложение, в котором специально допустил различные ошибки, чтобы по порядку найти и исправить их.
В предыдущей статье мы говорили о проблеме n+1, видах пагинации и индексах. Там же Вы можете найти описание приложения, репозиторий проекта и схему данных.
Redis на практических примерах
Redis — достаточно популярный инструмент, который из коробки поддерживает большое количество различных типов данных и методов работы с ними. Во многих проектах он используется в качестве кэшируещего слоя, но его возможности намного шире. Мы в ManyChat очень любим Redis и активно используем его в нашем продукте для решения огромного количества задач. Про некоторые интересные кейсы использования этой in-memory key-value базы данных я расскажу на примерах. Надеюсь, вам они будут полезны, и вы сможете применить что-то в своих проектах.
Рассмотрим следующие кейсы:
- Кэширование данных (да, банально и скучно, но это классный инструмент для кэширования и обойти стороной этот кейс, кажется будет не правильно)
- Работа с очередями на базе redis
- Организация блокировок (mutex)
- Делаем систему rate-limit
- Pubsub — делаем рассылки сообщений на клиенты
Буду работать с сырыми redis командами, чтобы не завязываться на какую-либо конкретную библиотеку, предоставляющую обертку над этими командами. Код буду писать на PHP с использованием ext-redis, но он здесь для наглядности, использовать представленные подходы можно в связке с любым другим языком программирования.
Базы данных в онлайн-играх. От Аллодов Онлайн до Skyforge
Меня зовут Андрей Фролов. Я ведущий программист Allods Team и работаю в команде сервера. Мой опыт разработки — почти 10 лет, но в игры я попал только в октябре 2009. В коллективе я уже больше трёх лет, с марта 2010. Начинал работу на Аллодах Онлайн, а сейчас на Skyforge. Занимаюсь всем, что так или иначе связано с сервером Skyforge и базами данных. В этой статье я расскажу о базах данных в онлайн-играх на примере Аллодов и Skyforge.
Безопасное взаимодействие в распределенных системах
Привет Хабр!
Меня зовут Алексей Солодкий, я PHP-разработчик в компании Badoo. И сегодня я поделюсь текстовой версией моего доклада для первого Badoo PHP Meetup. Видео этого и других докладов с митапа можно найти здесь.
Любая система, состоящая хотя бы из двух компонентов (а если у вас есть и PHP, и база данных, то это уже два компонента), сталкивается с целыми классами рисков во взаимодействии между этими компонентами.
Отдел платформы, в котором я работаю, интегрирует новые внутренние сервисы с нашим приложением. И решая эти задачи, мы накопили опыт, которым я и хочу поделиться.
Наш бэкенд — это PHP-монолит, взаимодействующий со множеством сервисов (самописных из них сейчас порядка пятидесяти). Между собой сервисы взаимодействуют редко. Но проблемы, о которых я говорю в статье, также актуальны для микросервисной архитектуры. Ведь в этом случае сервисы очень активно взаимодействуют друг с другом, а чем больше у вас взаимодействия, тем больше у вас проблем.
Рассмотрим, что делать, когда сервис падает или тупит, как организовать сбор метрик и что делать, когда всё вышесказанное вас не спасёт.
Миллион WebSocket и Go
Привет всем! Меня зовут Сергей Камардин, я программист команды Почты Mail.Ru.
Это статья о том, как мы разработали высоконагруженный WebSocket-сервер на Go.
Если тема WebSocket вам близка, но Go — не совсем, надеюсь, статья все равно покажется вам интересной с точки зрения идей и приемов оптимизации.
О языке С и производительности
Если программист хорошо знаком только с высокоуровневыми языками, например PHP, то ему не так просто освоить некоторые идеи, свойственные низкоуровневым языкам и критичные для понимания возможностей информационно-вычислительных процессов. По большей части причина в том, что в низко- и высокоуровневых языках мы решаем разные проблемы.
Но как можно считать себя профессионалом в каком-либо (высокоуровневом) языке, если даже не знаешь, как именно работает процессор, как он выполняет вычисления, эффективным ли способом? Сегодня автоматическое управление памятью становится главной проблемой в большинстве высокоуровневых языков, и многие программисты подходят к её решению без достаточной теоретической базы. Я уверен, что знание низкоуровневых процессов сильно помогает в разработке эффективных высокоуровневых программ.
Кэши для «чайников»
Кэш – это комплексная система. Соответственно, под разными углами результат может лежать как в действительной, так и в мнимой области. Очень важно понимать разницу между тем, что мы ждем и тем, что есть на самом деле.
Давайте прокрутим полный оборот ситуаций.
Tl;dr: добавляя в архитектуру кэш важно явно осознавать, что кэш может быть средством дестабилизации системы под нагрузкой. Смотрите конец статьи.
Как узнать, что ваш PHP сайт был взломан
Проверьте логи доступа
Что бы с чего-то начать, я бы хотел поделиться некоторыми записями из журнала доступа (access log) взломанного сайта моего друга.
IpreMOVED - - [01/Mar/2013:06:16:48 -0600] "POST /uploads/monthly_10_2012/view.php HTTP/1.1" 200 36 "-" "Mozilla/5.0"
IpreMOVED - - [01/Mar/2013:06:12:58 -0600] "POST /public/style_images/master/profile/blog.php HTTP/1.1" 200 36 "-" "Mozilla/5.0"
Необходимо часто проверять журналы доступа на сервере, однако если вы не будете осторожны, URL такие как выше, которые на первый взгляд выглядят безобидно, могут пройти прямо мимо вас.
Два файла выше это загруженные взломщиком скрипты, как они туда попали, большой роли не играет, так как код на любых двух серверах, вероятно, будет различным. Тем не менее, в данном конкретном примере, уязвимость в устаревшей версии IP.Board была использована, и атакующие смогли добавить свои собственные скрипты в директории доступные для записи, такие как пользовательский каталог загрузки и каталог, в котором IP.Board хранит кэшированные изображения темы оформления. Это общий вектор атаки, много людей изменяют права на эти каталоги на 777 или дают им доступ на запись, подробнее об этом чуть позже.
Рассмотрим подробнее приведенные выше строки журнала, ничего не цепляет вас?
Обратите внимание, что в журнале доступа POST запросы, а не GET запросы.
Скорее всего, злоумышленники хотели сделать журнал доступа более неприметным, так как большинство журналов не сохраняют post данные.
Установка связки Carbon + Graphite + Grafana + Nginx + MySQL для сбора и отображения метрик в Ubuntu
Хочу поделиться опытом установки и настройки сервиса для сбора и отображения метрик Graphite
+ Grafana
.
Искал долго, читал много, нашёл 2 статьи на английском, добавил своё, в итоге получилась данная статья.
Немного предыстории..
Graphite
— система для отображения метрик (числовых значений) для любых свойств сервера или домашнего ПК.
Carbon
— демон/бэкенд, в который пишутся метрики.
Grafana
— более красивая и удобная Web-морда для Graphite
.
И так, приступим.
Чат-помощник на сайт с помощью Telegram за 15 минут
Про чаты-помощники
Многие люди продают через интернет товары и услуги. Еще больше людей — покупает что-то через интернет.
Во время выбора покупок, часто возникают вопросы, которые можно решить позвонив и пообщавшись с менеджером.
Скорее всего я — не единственный человек на хабре, который общению с менеджерами по телефону предпочитает переписку.
И тут на помощь приходят всплывающие чаты-помощники, которые вроде-как повышают конверсию, но многих нервируют.
(Для тех, кто не в курсе: в углу сайта всплывает окошко, в котором можно он-лайн переписываться с консультантом).
Есть с десяток подобных сервисов и все они работают по принципу "пробная версия бесплатно, а дальше за деньги".
На хабре есть несколько статей, вот одна из них (http://habrahabr.ru/company/tuthost/blog/165365/), но, я уверен, аудитория Хабрахабра знает о чем речь.
Большинству людей подойдет бесплатный вариант любого такого сервиса: нужно всего-навсего зарегистрироваться и вставить на сайт кусок JS кода. Для тех у кого много менеджеров — придется платить: например Редхелпер на 10 операторов обойдется Вам:
Скорее всего — цена адекватная для тех, кто платит зарплату десяти менеджерам.
Но я решил изобрести бесплатный «велосипед» из подручных материалов.
Запуск у себя на сервере займет 15 минут. Всем, кому идея интересна — прошу под кат.
Проектирование в PostgreSQL документо-ориентированного API: Полнотекстовый поиск и сохранение многих документов(Часть 2)
Давайте сделаем это.
Как в Badoo генерируются изображения для «шаринга» в соцсетях
- свой профиль;
- чужой профиль (если его владелец это разрешил);
- свой рейтинг, отражающий популярность пользователя на сайте;
- награды, полученные пользователем за свои действия или действия других пользователей.
Чтобы пользователю хотелось делиться всем этим, мы генерируем специальные изображения, которые называем бейджами. Вот пример бейджа, который может получить пользователь:
Особенность бейджей состоит в том, что на них присутствуют фото самих пользователей, поэтому каждый видит и делится уникальными изображениями. В этой статье я расскажу, как мы генерируем такие изображения, с какими проблемами сталкивались и как их решали.
Разработка менеджера закачек на GO
http://loafter.github.io/godownloader/
https://github.com/Loafter/godownloader
Вступление
Давным-давно, в году этак 1998, для выхода в интернет я использовал модем на работе у отца. Он его включал вечером после работы и я мог наслаждаться просторами сети интернет на скорости аж 31.2 кбит/c. В то время не было истеричных блогеров, страницы не весили по мегабайту, а в новостных сайтах говорили только правду. Естественно основной интерес представляли ресурсы. Картинки, программы, всякие дополнения к играм, вроде машинок. Как сейчас помню качать через IE было сущим адом. Скачать файл весом больше 500 кб было просто невозможно, древний осел был намного упрямей.
19 советов по повседневной работе с Git
Если вы регулярно используете Git, то вам могут быть полезны практические советы из этой статьи. Если вы в этом пока новичок, то для начала вам лучше ознакомиться с Git Cheat Sheet. Скажем так, данная статья предназначена для тех, у кого есть опыт использования Git от трёх месяцев. Осторожно: траффик, большие картинки!
Содержание:
- Параметры для удобного просмотра лога
- Вывод актуальных изменений в файл
- Просмотр изменений в определённых строках файла
- Просмотр ещё не влитых в родительскую ветку изменений
- Извлечение файла из другой ветки
- Пара слов о ребейзе
- Сохранение структуры ветки после локального мержа
- Исправление последнего коммита вместо создания нового
- Три состояния в Git и переключение между ними
- Мягкая отмена коммитов
- Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
- Игнорирование пробелов
- Добавление определённых изменений из файла
- Поиск и удаление старых веток
- Откладывание изменений определённых файлов
- Хорошие примечания к коммиту
- Автодополнения команд Git
- Создание алиасов для часто используемых команд
- Быстрый поиск плохого коммита
Техобслуживание кода. Как «продать» рефакторинг бизнесу
Сегодня я постараюсь ответить на один из самых частых вопросов, которые я слышу, когда речь идёт о разработке систем с запредельным количеством legacy, и поделюсь своим взглядом на то, как «продать» бизнесу рефакторинг.
В этой статье я принципиально ограничиваюсь описанием взаимодействия с бизнесом и не касаюсь технических деталей (как именно рефакторинг проводить). Пост написан исключительно на личном успешном и не очень опыте «продажи» и «покупки» рефакторинга в разных командах и в разных компаниях.
SQL Insert Injection в одном интернет магазине
Давно на Хабре не звучали истории про SQL injection. А уж рассказов из жизни про SQL INSERT injection вообще очень мало. Поэтому расскажу свою.
Всё началось с моего желания купить себе нечто недешёвое в разборном виде в интернет-магазине A.B.ru фирмы B. После оформления, связи с менеджером по электронной почте, получения посылки и обзора её содержимого оказалось, что некоторых метизов очень не хватает. Полного перечня всего необходимого не было, лишь список болтов, гаек и шайб. Я начал сборку, дойдя до того места, где без отсутствующих болтов уже никак не обойтись. Поэтому мною было скурпулёзно составлено описание не найденных метизов и выслано электронным письмом той же девушке-менеджеру, с которой мы общались. К чести магазина стоит сказать, что практически всё необходимое было выслано второй посылкой. Поэтому я начал сборку, загоняя в дальний угол своего разума опасения о том, что может отсутствовать что-то ещё. Но, дойдя до финишной прямой, оказалось, что примерно 1/4-ой часть устройства не хватает в принципе, судя по фотографиям из руководства и здравому смыслу. Поэтому за первым письмом о недокомплекте последовало второе, куда более обширное, а сборка отложена.
Когда прошла вторая неделя ожидания, мне удалось убедить себя в том, что девушка-менеджер вышла в отпуск. Поэтому я переслал ей письмо двухнедельной давности ещё раз и перешёл к поиску других каналов электронной связи — очень уж не хотелось звонить в Москву. В первую очередь тоже самое письмо было отправлено на общий эл-адрес A@B.ru, на что был получен мгновенный ответ: почтовый сервер отказывается принимать письмо из-за переполненного ящика получателя <мужик>@B.ru. Тогда была найдена форма обратной связи на сайте — последняя ниточка соединяющая меня на текущий момент с интернет-магазином. В первую очередь я описал проблему переполненного почтового ящика и вставил сообщение об отказе доставить письмо, которое содержало в себе одинарные кавычки…
Начало
На попытку отправить отчёт об ошибке через форму обратной связи, на пару секунд на странице появилась ошибка, в которой угадывался голос MySQL. Поэтому я открыл консоль браузера, повторил запрос и заглянул в ответ сервера:
Определяем пользователей VPN (и их настройки!) и прокси со стороны сайта
We can save the day from dark, from bad
There's no one we need
Многие из вас используют VPN или прокси в повседневной жизни. Кто-то использует его постоянно, получая доступ к заблокированным на государственном или корпоративном уровне ресурсам, многие используют его изредка, для обхода ограничений по географическому положению. Как вы можете знать, крупные интернет-игроки в сфере стриминга видео, музыки и продажи игр никогда не любили пользователей, которые легко обходят географические ограничения, разблокируя недоступный в их стране контент, или совершая покупки заметно дешевле. За примерами не нужно далеко ходить: Netflix изменил свое соглашение об использовании, добавив пункт о блокировке VPN, всего 2 месяца назад; Hulu тоже грешил блокировкой пользователей, а Steam вообще подозрительно смотрит на не-русскоязычных пользователей из России. В последнее время, компании пытаются блокировать уже не конкретных пользователей, а сами IP-адреса VPN-сервисов, создавая определенные неудобства уже самому VPN-сервису и его пользователям. Похоже, они не используют никаких спецсредств, а блокируют выборочно и вручную. Хоть я и не поддерживаю какие-либо блокировки вообще, меня заинтересовала техническая часть вопроса: можно ли как-то определить использование прокси-серверов и VPN со стороны сервера, не прикладывая особых усилий?
Можно, при определенных условиях. И достаточно точно.
Захват пакетов в Linux на скорости десятки миллионов пакетов в секунду без использования сторонних библиотек
Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.
Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.
Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.
Также стоит отметить, что у нас на сервере обычно более 2х логических ядер. И данные могут прилететь на любое их них! А приложение, которое принимает данные силами pcap использует одно ядро. Вот тут у нас включаются блокировки на стороне ядра и кардинально замедляют процесс захвата — теперь мы занимаемся не только копированием памяти/обработкой пакетов, а ждем освобождения блокировок, занятых другими ядрами. Поверьте, на блокировки может зачастую уйти до 90% процессорных ресурсов всего сервера.
Хороший списочек проблем? Итак, мы их все геройски попробуем решить!
Information
- Rating
- Does not participate
- Location
- Москва, Москва и Московская обл., Россия
- Registered
- Activity