Список полезных идей для высоконагруженных сервисов

[MaZaAa]

Это самое важное. Для вас не должно существовать безусловных авторитетов. Если кто-либо говорит полную чушь, или говорит что-то, что противоречит вашей практике — не прислушивайтесь к таким советам, и не важно, насколько этот человек известный и уважаемый.

Золотые слова

[ferocactus]

Основа научного мировоззрения. С другой стороны признанный авторитет всё-таки с большей вероятностью говорит не чушь, чем признанный идиот. А проверять утверждения каждого авторитета и каждого идиота — жизнь коротка. Вопрос выбора жёсткости предубеждений, либо рискуешь наивно ошибаться, либо погрязнуть в проверках.

[youROCK]

Справедливо. Правда, пока что ни разу не видел людей, которые бы погрязли в проверках :). А вот чтобы безусловно доверяли авторитетам — постоянно наблюдаю.

[a-l-e-x]

Согласен.
Я бы ещё Google SRE книжку посоветовал посмотреть. Там тоже очень много хорошего. Применяется везде, а не только для их платформы.

[alexkrash]

Когда что-то важное упало — напишите постмортем

Как мне кажется, упущен пункт, что это знание должно быть расшарено с заинтересованными.

[a-l-e-x]

и буквально на днях пост был на эту тему:

Getting the most out of shared postmortems — CRE life lessons
goo.gl/ns5Ce2

[truezemez]

Спасибо за статью.

Есть разные способы, как можно достигать консистентности в таких случаях, но самым распространненым являются очереди — вы добавляете в одной транзакции данные и запись в отдельную таблицу — очередь на обновление сервиса. Поскольку это транзакция на одном сервере, то она либо пройдет целиком, либо не пройдет вовсе. Соответственно, даже если обновить данные в сервисе сразу не удалось, в конечном итоге данные будут согласованы.

Не уловил вашей мысли. Можете "на пальцах" объяснить?

[youROCK]

Представим себе, что у нас, скажем, MySQL. Мы хотим обновить данные в таблице accounts и в сфинксе. Можно попытаться их обновить просто последовательно — сначала в базе обновляем, потом в сфинкс идем и надеемся на то, что у нас получится и там тоже обновить. Но сфинкс может находиться где-то на другом сервере и вообще быть недоступен в этот момент. Тогда мы останемся у разбитого корыта — в мускуле одни данные, а в сфинксе другие.

Чтобы решить эту проблему, можно ввести очереди:
— BEGIN;
— update accounts…;
— insert into sphinx_queue values (account_id);
— COMMIT;

То есть, вместо обновления сфинкса мы пишем в той же транзакции еще в одну таблицу-очередь. Потом, в отдельном фоновом процессе, мы эту очередь разгребаем и обновляем сфинкс. Если обновить сфинкс не удалось, то мы просто оставляем запись в таблице и пробуем снова через какое-то время.

Более подробно об этом (и других проблемах шардинга) рассказывал Михаил Курмаев на хайлоаде: m.youtube.com/watch?v=Ygfwwd490mk

[truezemez]

Спасибо.

[Shersh]

А дайте ссылку на статью как делать свои continuation token'ы вместо offset и limit

[youROCK]

https://habrahabr.ru/post/217521/ — это один из способов смягчить проблему, но не устранить её
https://habrahabr.ru/post/44608/ — вот намного более старая статья, где есть намек на то, как можно решить проблему более правильно

[Shersh]

Там ведь нет про continuation token, но оптимизация интересная, спасибо

[youROCK]

Я чуток отредактировал комментарий, добавив туда ещё одну ссылку :).
Но идея не особо меняется — вы используете поле для сортировки, например, id, и в token вставляете последнее значение id, на котором остановились. Если поле не уникальное (например, timestamp в секундах), то в токен дополнительно засовываете значения id, которые вы уже видели с самым последним значением timestamp. Грубо говоря, если у вас строки в таблице идут вот так:

id timestamp
1 1
2 2
3 3
4 4
5 4 <- limit = 5, это последняя запись на текущей странице
6 4
7 5

То для следующей страницы мы должны в итоге получить запрос вида SELECT… WHERE timestamp >= 4 AND id NOT IN(4,5)

[ptrue]

Спасибо за статью
А вот что то практическое можете по этим пунктам посоветовать? =) про шардинг или вот про мониторинг, например?

[youROCK]

Про шардинг — https://youtube.com/watch?v=Ygfwwd490mk, доклад Михаила Курмаева. Про мониторинг — вопрос хороший, сходу хороших докладов не припомню. Если речь идет о просто мониторинге серверов и немножко бизнес метрик, то не сочтите за рекламу, но я бы рекомендовал начать с того, что делают ребята из okmeter, например.

[tru_pablo]

Привет, раз уж позвали — мы тут есть.

[DreaMinder]

интересно узнать мнение автора о постройке такой системы в облаке. Например если использовать БД вендора которая сама масштабируется и повлиять не это нельзя.
Понятно что оптимизация и тут понадобится, но я так понимаю уже с целью экономии денег?

[youROCK]

Ничего не могу посоветовать, ибо с облачными базами не работал. Но из того, что я слышал от людей, которые их использовали, это обычно получается дорого и неуправляемо (как раз из-за отсутствия возможности что-то настроить «под себя»). То есть, оно годится в условиях сильно ограниченных людских ресурсов и слабо ограниченных финансовых ресурсов (enterprise?), и обычно это с хайлоадом плохо сочетается. Но понимать, как система работает, всё равно очень желательно, как раз для того, чтобы не тратить лишних денег (на больших объемах уменьшение расходов даже на 1% может выливаться в месячную зарплату одного работника).

[amarao]

В целом разумно, но первый совет — очень спорный.

ов. Если кто-либо говорит полную чушь, или говорит что-то, что противоречит вашей практике — не прислушивайтесь к таким советам, и не важно, насколько этот человек известный и уважаемый.

Прислушиваться нужно. Проверять нужно. Часто бывает, что человек несёт полную чушь, потому что он думает уже не о «твоей маленькой проблеме», а больших последствиях твоего метода исправления маленькой проблемы.

Часто бывает, что «чушь» — это иная парадигма и иной комплект ценностей. Например, вам могут нести чушь про идемпотентность и вред неявных сайд-эффектов. Чушь? Чушь. Слушать? Ну..., как сказать, можно и не слушать.