Відвідав тренінг http://sonetica.ru/highload.html. Відповідно кілька нотаток з цього приводу.

Основна думка, яку намагався донести автор тренінгу - у високо навантажених проектах виникає новий клас специфічних проблем, з якими тяжко зіткнутися при розробці, наприклад, корпоративного програмного забезпечення.

Деякі з розглянутих проблем:

• Не атомарність операцій доступу до ресурсів при високо конкурентному доступі. І, як єдина можливість ви рішення цієї проблеми, блокування та розблокування ресурсів. При цьому їх вчасне розблоковування може стати окремою великою проблемою (наприклад, якщо процес, який заблокував доступ до ресурсу не зміг успішно завершитися і зняти блок). Типовою помилкою є вважати транзакції  засобом подолання проблем конкурентного доступу. 
• Потрібно усіляко мінімізовувати використання дискових операції. У цьому допомагають усілякі кеші та використання асинхронного підходу до операції створення і модифікації об'єктів (наприклад з використанням черги).
• Високо навантажена система має складатися з якомога менш зв'язаних підсистем, які взаємодіють через спільну чергу повідомлень.
• Різноманітні черги допомагають запобігати втраті даних при відмові (в результаті аварії чи високого навантаження в даний момент), наприклад, sql сервера. Не проблема, якщо користувач фейсбука не побачить своє повідомлення на власній стіні відразу після натискування кновки пост - проблема, якщо воно там взагалі ніколи не з'явиться.
• Для того, щоб витримати різке збільшення навантаження, проект має масштабуватися лінійно. Для цього потрібна специфічна архітектура організації і збереження даних. Важливу роль відіграє правильне розбиття даних. No-sql підхід і тотальна денормалізація дозволяє побудувати систему, яка відповідає цим вимогам. Традиційні підходи (наприклад r/w split) мають обмеження (масштабуються логарифмічно) і при досягненні певно порогу навантаження перестають працювати.
• Бажано організовувати доступ до даних за первинним ключем.
• Дані доменну потрібно розбивати на шарди однакового розміру (наприклад по 1000 записів), для швидкого доступу потрібно зберігати метаінформацію про шард - наприклад, перший і останній id теми форума, реальна кількість тем у форумі (без врахування видалених тем); дата, автор, айді, і тема останнього повідомлення у форумі тощо.

Весь час звучала завуальвана реклама memcached/memcachedb/memcacheq, nginx, php-fpm, pinba. І усі ці інструменти дійсно варті найпильнішої уваги до себе.

Злегка була затронута тема моніторингу навантаження.

В цілому враження від тренінгу самі позитивні.