Существуют всевозможные методы для высокопроизводительной обработки транзакций, и тот, что в статье Фаулера, является одним из многих на переднем крае. Вместо того, чтобы перечислять набор методов, которые могут или не могут быть применимы к чьей-либо ситуации, я думаю, что лучше обсудить основные принципы и то, как LMAX обращается с большим количеством из них.
Для крупномасштабной системы обработки транзакций вы хотите сделать как можно больше из следующих действий:
Минимизируйте время, затрачиваемое на самые медленные уровни хранения. От самого быстрого до самого медленного на современном сервере у вас есть: CPU / L1 -> L2 -> L3 -> RAM -> Disk / LAN -> WAN. Переход от даже самого быстрого современного магнитного диска к самой медленной оперативной памяти составляет более 1000x для последовательного доступа; произвольный доступ еще хуже.
Минимизируйте или исключите время, потраченное на ожидание . Это означает совместное использование как можно меньшего количества состояний, и, если состояние должно быть общим, по возможности избегая явных блокировок
Распределите рабочую нагрузку. Процессоры не получили гораздо быстрее , в последние несколько лет, но они уже получили меньше, и 8 ядер довольно часто встречаются на сервере. Помимо этого, вы можете даже распределить работу по нескольким машинам, что является подходом Google; Самое замечательное в этом то, что он масштабирует все, включая ввод / вывод.
По словам Фаулера, LMAX использует следующий подход к каждому из них:
Сохраняйте все состояния в памяти все время. Большинство движков баз данных на самом деле будут делать это в любом случае, если вся база данных может поместиться в памяти, но они не хотят ничего оставлять на волю случая, что понятно на торговой платформе в реальном времени. Чтобы справиться с этим, не прибегая к большому риску, им пришлось создать несколько облегченных инфраструктур резервного копирования и восстановления после сбоев.
Используйте очередь без блокировки («прерыватель») для потока входных событий. В отличие от традиционных долговременных очередей сообщений, которые окончательно не блокируются и фактически включают болезненно медленные распределенные транзакции .
Немного. LMAX выбрасывает его под шину на основании того, что рабочие нагрузки являются взаимозависимыми; результат одного меняет параметры для других. Это критическое предостережение, которое Фаулер явно призывает. Они делают некоторые используют параллелизм для того , чтобы обеспечить отказоустойчивости, но все бизнес - логики обрабатывается на одном потоке .
LMAX - не единственный подход к масштабному OLTP. И хотя он сам по себе довольно блестящий, вам не нужно использовать передовые методы, чтобы достичь такого уровня производительности.
Из всех вышеперечисленных принципов, # 3, вероятно, самый важный и самый эффективный, потому что, честно говоря, аппаратное обеспечение дешево. Если вы сможете правильно распределить рабочую нагрузку между полдюжиной ядер и несколькими десятками машин, то предел для традиционных методов параллельных вычислений - это предел . Вы будете удивлены тем, какую пропускную способность вы можете достичь, используя только несколько очередей сообщений и распределенный круговой распределитель. Очевидно, что он не так эффективен, как LMAX - на самом деле даже не близко - но пропускная способность, задержка и экономическая эффективность - это отдельные проблемы, и здесь мы говорим конкретно о пропускной способности.
Если у вас есть те же особые потребности, что и у LMAX - в частности, общее состояние, которое соответствует бизнес-реальности, а не поспешному выбору дизайна - тогда я бы предложил опробовать их компонент, потому что я не видел много иначе это соответствует этим требованиям. Но если мы просто говорим о высокой масштабируемости, то я бы посоветовал вам больше исследовать распределенные системы, потому что они являются каноническим подходом, используемым большинством организаций сегодня (Hadoop и смежные проекты, ESB и смежные архитектуры, CQRS, который Фаулер также упоминания и тд).
Твердотельные накопители также собираются изменить игру; возможно, они уже есть. Теперь у вас может быть постоянное хранилище с аналогичным временем доступа к ОЗУ, и, хотя твердотельные накопители серверного уровня по-прежнему ужасно дороги, они со временем снизятся в цене, как только число пользователей увеличится. Он был тщательно исследован, и его результаты ошеломляют и со временем будут только улучшаться, поэтому концепция «держать все в памяти» намного менее важна, чем раньше. Итак, еще раз, я постараюсь сосредоточиться на параллелизме, когда это возможно.