У нас миграции DB в большинстве случаев безопасные. Либо мы добавляем новое поле — и оно ничего не ломает, потому что еще нигде не используется. Либо удаляем поле — это делается уже после вычистки кода от использования этого поля. Вобщем миграции к выкладке почти не привязаны, ничего нетривиального в них нет и особых проблем с ними тоже нет.
мы обычно включаем новые услуги сначало в какой-то одной/нескольких странах. Смотрим статистику, реакцию юзера на новую фичу, дорабатываем, оптимизируем и постепенно добавляем страны. Выкатывать новую фичу сразу везде — безумие
Я привет гипотетический пример который может случиться. Возможно что его и можно решить на уровне приложения, но в условиях дедлайна мало кто будет писать _php_-код из расчета на то что php-процесс может умереть в любой момент.
PHP — не самый качественный язык. Иногда php-процессы падают в корку в самых разных местах (eacellerator, debug_backtrace, array_map, различные экстеншены не входящие в стандартный php)
У нас даже небольшой скрипт написали который собирает корки со всех машин и в веб-интерфейсе показывает trace из gdb :)
Но в целом согласен — это вопрос выбора.
backend-ы падают по-разному
Если backend не принимает запросы, то тут все просто — выбираем следующий backend
Если же backend принял запрос, но ответил ошибкой, то не факт что запрос можно отправить на следующий backend. Например backend принял запрос на отсылку сообщения пользователю, сохранил сообщение в базе, но потом по какой-то причине упал например в core dump уже после коммита в базу. Если такой запрос переадресовать на следующий бекенд — в базу сохраняться 2 сообщения.
И при падении этого сервера некоторый % пользователей 100% не смогут попасть на сайт пока балансер не выкинет упавший backend?
Я не пробовал этот метод на практике. Скорее всего да.
А вот по сессиям, хранящимся в репликации, интересный вопрос появляется, когда сервера находятся в разных датацентрах в разных странах и появляется неприятное отставание.
Если речь идет именно о сессии, то она нужно только в том датацентре, которым сейчас пользуется данный юзер. В других датацентрах она попросту не нужна. Бывают редкие случаи, когда юзера на средиректить в другой датацентр. В этом случае после редиректа можно запросить один раз сессию из старого датацентра и сохранить в новом. Запрос в другой датацентр — операция конечно медденная, но не смертельно. Тем более что ситуация такая возникает у малого кол-ва людей
На твои вопросы нет однозначных ответов. Есть варианты из которых надо выбирать
Например некоторые стартапы настраивают свои лоад-балансеры так чтобы один и тот же юзер всегда попадал на один и тот же сервер и сессии хранят прямо на этом сервере в памяти приложения (особенно это любят java/scala разработчики) > Как сервер, которому понадобилась информация о сессии, узнает к какому серверу сессии ему обращаться?
можно закодировать id сервера в session_id >Что будет если один из этих серверов упадет? Данные о сессиях потеряются или они дублируются в базе?Зависит от того что выберете и как напишите. Если сессии в памяти хрянились (мемкеш) — то юзерам прийдется заново авторизоваться. Если redis / mysql — то ждать пока они перезапустятся. В mysql можно настроить репликацию
Вобщем вариантов много
1. да, счетчик в базе
2. ну конечно же серверов можно (и нужно) ставить несколько. Например завести 5-10 серверов с memcache или redis или mysql handler socket или что-то похожее и рапределять все сессии между этими серверами.
highload — это на 90% масштабирование, то есть возможность ускорить приложение, добавив больше серверов.
Например есть у тебя сервер с тормозящей базой данных. Ты ставишь рядом вторую, переносишь часть данных (шардинг) или делаешь полную копию данных (репликация) на втором сервере — и твоя систем начинает работать быстрее.
Или например есть у тебя тормозящий сервер обрабатывающий HTTP-запросы юзеров — ставишь рядом второй такой же и пускаешь туда половину юзеров — и твоя система ускоряется.
В книге такое сложно описать потому что сложно придумать какую-то универсальную систему и дьявол скрывается в деталях
+ неплохая зарплата и бонусы
+ доступ к имеющейся библиотеке тех. литературы и возможность заказать необходимые книги
+ возможность поучаствовать в коференциях
+ уроки английского
Зачастую в фреймворках предусмотрены механизмы вызова пользовательского кода на различных стадиях, надо лишь копнуть чуть глубже. Например в питоне это стандартизировано и делается с помощью middleware. В пхп стандарта нет и каждый фреймворк делает по-своему.
pinba_script_name_set() _необязательно_ вызывать в самом начале, можно и в конце скрипта
это всё очень неочевидная магия которая будет работать далеко не всегда
Проще одну строчку кода добавить в то место где определяется, какой контроллер должен выполняться
Сразу как-то не понравилась зависимость от MySQLя, т.к. хотели хранить данные и иметь возможность мониторить работу в реальном времени. Не понял вот эту фразу. Вы хотели хранить все данные за все время?
Спасибо, подумаем.
Насчет качества и тестируемости кода. Недавно наш девелопер на www.itmozg.ru/high-performance-conference/ делал доклад о том как, мы расскладываем код. Частично эта тема затрагивает качество кода и тестируемость. Вроде бы в течение нескольких недель организаторы опубликуют видео докладов, так что следите за анонсами.
PHP — не самый качественный язык. Иногда php-процессы падают в корку в самых разных местах (eacellerator, debug_backtrace, array_map, различные экстеншены не входящие в стандартный php)
У нас даже небольшой скрипт написали который собирает корки со всех машин и в веб-интерфейсе показывает trace из gdb :)
Но в целом согласен — это вопрос выбора.
Если backend не принимает запросы, то тут все просто — выбираем следующий backend
Если же backend принял запрос, но ответил ошибкой, то не факт что запрос можно отправить на следующий backend. Например backend принял запрос на отсылку сообщения пользователю, сохранил сообщение в базе, но потом по какой-то причине упал например в core dump уже после коммита в базу. Если такой запрос переадресовать на следующий бекенд — в базу сохраняться 2 сообщения.
Если речь идет именно о сессии, то она нужно только в том датацентре, которым сейчас пользуется данный юзер. В других датацентрах она попросту не нужна. Бывают редкие случаи, когда юзера на средиректить в другой датацентр. В этом случае после редиректа можно запросить один раз сессию из старого датацентра и сохранить в новом. Запрос в другой датацентр — операция конечно медденная, но не смертельно. Тем более что ситуация такая возникает у малого кол-ва людей
Например некоторые стартапы настраивают свои лоад-балансеры так чтобы один и тот же юзер всегда попадал на один и тот же сервер и сессии хранят прямо на этом сервере в памяти приложения (особенно это любят java/scala разработчики)
> Как сервер, которому понадобилась информация о сессии, узнает к какому серверу сессии ему обращаться?
можно закодировать id сервера в session_id
>Что будет если один из этих серверов упадет? Данные о сессиях потеряются или они дублируются в базе?Зависит от того что выберете и как напишите. Если сессии в памяти хрянились (мемкеш) — то юзерам прийдется заново авторизоваться. Если redis / mysql — то ждать пока они перезапустятся. В mysql можно настроить репликацию
Вобщем вариантов много
2. ну конечно же серверов можно (и нужно) ставить несколько. Например завести 5-10 серверов с memcache или redis или mysql handler socket или что-то похожее и рапределять все сессии между этими серверами.
Например есть у тебя сервер с тормозящей базой данных. Ты ставишь рядом вторую, переносишь часть данных (шардинг) или делаешь полную копию данных (репликация) на втором сервере — и твоя систем начинает работать быстрее.
Или например есть у тебя тормозящий сервер обрабатывающий HTTP-запросы юзеров — ставишь рядом второй такой же и пускаешь туда половину юзеров — и твоя система ускоряется.
В книге такое сложно описать потому что сложно придумать какую-то универсальную систему и дьявол скрывается в деталях
+ доступ к имеющейся библиотеке тех. литературы и возможность заказать необходимые книги
+ возможность поучаствовать в коференциях
+ уроки английского
pinba_script_name_set() _необязательно_ вызывать в самом начале, можно и в конце скрипта
Проще одну строчку кода добавить в то место где определяется, какой контроллер должен выполняться
pinba ведь тоже это показывает. Или вы хотите агрегировать данные посекундно?
Храним там даннные отчетов за последние пол-года.
Судя по презентации проект интересный, но на практике не пробовали
Наверное просто по разному трактуем этот термин
Насчет качества и тестируемости кода. Недавно наш девелопер на www.itmozg.ru/high-performance-conference/ делал доклад о том как, мы расскладываем код. Частично эта тема затрагивает качество кода и тестируемость. Вроде бы в течение нескольких недель организаторы опубликуют видео докладов, так что следите за анонсами.