Разработчики ставят тикеты на альтер и следят когда они будут выполнены. Как я сказал есть в общем случае 3 этапа. Задача разработчика не допустить их пересечение.
Давайте я попытаюсь ответить сразу на все вопросы.
Любой ALTER делается в несколько этапов:
1 подготавливается код (если надо)
2 делается ALTER
3 удаляется код (если надо)
Каждый из этих пунктов может занимать время, главное чтобы они не пересекались.
Например добавление таблицы или колонки обычно не требует пункта 1, удаление — не требует пункта 3.
В основном все изменения делаются простым альтером в оффпик. Там, где альтер долгий делается через pt-online-schema-change
Мы хорошо относимся ко всему что может облегчить нам жизнь, но TiDB мы пока не пробовали. Возможно в будущем мы найдем задачи в которых сможем его попробовать, но заменять работающее решение на что-то другое только что бы посмотреть как оно работает мы не планируем.
Сейчас все проблемы синхронизации решаются через очереди. Атомарное изменение в двух шардах практически никогда не нужно. Если пользователь увидит подарок который ему подарили через секунду после того как его подарили ничего страшного не случится.
С мемкешом у нас все просто. У нас стоит N серверов ключи по которым раскидываются равномерно по определенному хешу. В случае выпадения одного из мемкешей мы просто теряем 1/N кеша и получаем небольшой прирост запросов на базы, что вообщем то не критично.
ClickHouse у нас используется для обсчета статистики. Подробнее про него я попрошу ответить ребят из BI.
Вы правы в A-Team действительно некоторые задачи решаются на Go, в основном это узкоспециализированые сервисы, которые решают конкретную задачу.
Сильно уменьшать или увеличивать его долю не планируем. Мы стараемся использовать те инструменты которые лучше подходят для задачи не разводя при этом зоопарка.
Если я правильно понял вопрос, то вопрос о том, как считаются агригации по данным, которые расшардены по большому количеству сереров.
В целом схема такая: у нас есть специализированые сишные сервисы, которые хранят все нужные данные в памяти и умеют быстро считать что-то по нужным срезам. Для синхранизации этих данных с данными в шардах мы используем очереди. Когда интересующие нас данные меняются в шардах мы кидаем событие, все эти события приходят в общую очередь и апдейтят данные в сервисе. Сервис раз в какое то время перестраивает индексы. Таким образом задержка между реальными данными и «счетчиками» составляет несколько минут
API демонов обычно довольно простые, и каких либо проблем с тем что где то сделали так, что пользоваться невозможно у нас не возникало. Единственное что у нас более менее унифицированно — это отдача статистики самом сервисом. И сделано это для того что бы не писать каждый раз сбор метрик.
Песочница это просто папка с репозиторием в хоуме у разработчика на devel сервере.
Нас это пока вполне устраивает, до докера в данном месте мы пока не дошли, возможно в будущем докер окажется удобнее.
Да, у каждого разработчика есть своя «песочница» на специальным devel кластере.
Мы стараемся поддеживать на нем такую же инфраструктуру как и на продакшене. Там так же есть эмуляция нескольких ДЦ и все сервисы которые есть в боевом окружении. Мы внимательно следим за devel площадкой и даже мониторинг работает примерно так же.
Все тесты запусаются так же в этом окружении и для ускорения времени их выполнения (прогон всех 75тысяч юнит тестов занимает около минуты) мы запускаем тесты паралельно на специальном кластере машин.
Привет!
1. Довольно большая часть нашего кода — это обертки над сервисами и базами, API для работы с очередями или фотографиями и тому подобное. Все это используется другими отделами и поэтому не может быть отдельным приложением. Практически весь PHP код находится в общем репозитории и использует некоторые общие куски кода. Поэтому, наверно можно сказать, что все оформлено как мегоприложение.
2. Мы стараемся планировать работы по техдолгу в общем пуле задач. Каких то конкретных критериев нет. Просто в какой то момент понемаем, что сейчас можно заняться задачами из беклога и тратим на них n человеко-недель.
Давайте я попытаюсь ответить сразу на все вопросы.
Любой ALTER делается в несколько этапов:
1 подготавливается код (если надо)
2 делается ALTER
3 удаляется код (если надо)
Каждый из этих пунктов может занимать время, главное чтобы они не пересекались.
Например добавление таблицы или колонки обычно не требует пункта 1, удаление — не требует пункта 3.
В основном все изменения делаются простым альтером в оффпик. Там, где альтер долгий делается через pt-online-schema-change
Мы хорошо относимся ко всему что может облегчить нам жизнь, но TiDB мы пока не пробовали. Возможно в будущем мы найдем задачи в которых сможем его попробовать, но заменять работающее решение на что-то другое только что бы посмотреть как оно работает мы не планируем.
Сейчас все проблемы синхронизации решаются через очереди. Атомарное изменение в двух шардах практически никогда не нужно. Если пользователь увидит подарок который ему подарили через секунду после того как его подарили ничего страшного не случится.
С мемкешом у нас все просто. У нас стоит N серверов ключи по которым раскидываются равномерно по определенному хешу. В случае выпадения одного из мемкешей мы просто теряем 1/N кеша и получаем небольшой прирост запросов на базы, что вообщем то не критично.
ClickHouse у нас используется для обсчета статистики. Подробнее про него я попрошу ответить ребят из BI.
Вы правы в A-Team действительно некоторые задачи решаются на Go, в основном это узкоспециализированые сервисы, которые решают конкретную задачу.
Сильно уменьшать или увеличивать его долю не планируем. Мы стараемся использовать те инструменты которые лучше подходят для задачи не разводя при этом зоопарка.
Если я правильно понял вопрос, то вопрос о том, как считаются агригации по данным, которые расшардены по большому количеству сереров.
В целом схема такая: у нас есть специализированые сишные сервисы, которые хранят все нужные данные в памяти и умеют быстро считать что-то по нужным срезам. Для синхранизации этих данных с данными в шардах мы используем очереди. Когда интересующие нас данные меняются в шардах мы кидаем событие, все эти события приходят в общую очередь и апдейтят данные в сервисе. Сервис раз в какое то время перестраивает индексы. Таким образом задержка между реальными данными и «счетчиками» составляет несколько минут
Нас это пока вполне устраивает, до докера в данном месте мы пока не дошли, возможно в будущем докер окажется удобнее.
Под локальным я имею ввиду зайти по SSH на devel машину и запустить там тест.
demiurg@www1.d3:~/badoo $ phpunit UTests/_packages/Platform/PlatformEnvironmentTest.php
PHPUnit 5.3.2-a by Sebastian Bergmann and contributors.
............ 12 / 12 (100%)
Time: 667 ms, Memory: 32.00MB
OK (12 tests, 147 assertions)
Настроить окружение на своем ноутбуке и писать код без доступа к devel площадке — задача нетривиальная.
Мы стараемся поддеживать на нем такую же инфраструктуру как и на продакшене. Там так же есть эмуляция нескольких ДЦ и все сервисы которые есть в боевом окружении. Мы внимательно следим за devel площадкой и даже мониторинг работает примерно так же.
Все тесты запусаются так же в этом окружении и для ускорения времени их выполнения (прогон всех 75тысяч юнит тестов занимает около минуты) мы запускаем тесты паралельно на специальном кластере машин.
1. Довольно большая часть нашего кода — это обертки над сервисами и базами, API для работы с очередями или фотографиями и тому подобное. Все это используется другими отделами и поэтому не может быть отдельным приложением. Практически весь PHP код находится в общем репозитории и использует некоторые общие куски кода. Поэтому, наверно можно сказать, что все оформлено как мегоприложение.
2. Мы стараемся планировать работы по техдолгу в общем пуле задач. Каких то конкретных критериев нет. Просто в какой то момент понемаем, что сейчас можно заняться задачами из беклога и тратим на них n человеко-недель.