Я думаю, что вы должны сосредоточиться на своем архитектурном проекте, прежде чем выбирать технологии с акцентом на масштабируемость и расширяемость. Создав архитектурный проект, вы можете посмотреть, что доступно и что вам нужно построить, и все это должно быть довольно очевидным.
Хотя это не совсем сопоставимо, рассмотрим, как Google, eBay и YouTube решают проблемы масштабируемости, с которыми они сталкиваются. Хотя у торговой системы не будет проблем, с которыми эти парни сталкиваются с огромным количеством пользователей, у вас будут аналогичные проблемы с объемами данных и возможностью своевременной обработки ценовых тиков.
У LSE есть 3000 имен, умножьте это на 10 или около того популярных бирж по всему миру, и у вас будет много данных, которые постоянно обновляются в течение периода, когда открыт каждый рынок. Чтобы дать вам представление о том, что входит в сбор данных с одного обмена, взгляните на http://kx.com/.
С точки зрения базы данных вам понадобится что-то промышленное, что позволяет кластеризоваться и иметь надежную репликацию - для меня это означает Oracle. Вы также хотите взглянуть на Дизайн базы данных временных рядов , который, по моему опыту, является наилучшим способом построения такого рода системы.
Те же требования к масштабированию и надежности будут применяться к вашим серверам приложений, при этом логичным выбором будет JBoss, хотя я бы также рассмотрел OSGi Spring Server (http://www.springsource.com/products/dmserver), так как его облегченный характер может сделать его быстрее.
Вам также понадобятся серверы Apache для балансировки нагрузки и для обслуживания статического контента - быстрый Google найдет стеки информации об этом, поэтому я не буду повторять это здесь.
Также забудьте опрос, он не масштабируется. Обратите внимание на использование процессов обмена сообщениями и потребителей для межпроцессного взаимодействия, событий и рабочих потоков для взаимодействия в процессе. Оба метода достигают естественного эффекта балансировки нагрузки, который можно настроить, увеличивая количество пользовательских процессов или рабочих потоков по мере необходимости.
Также статический интерфейс не собирается резать горчицу, ИМХО. Взгляните на то, что уже есть на рынке - у рынков с ЧПУ, индекса IG и т. Д. Есть довольно впечатляющие торговые приложения в реальном времени.
Кроме того, если предположить, что это коммерческий проект, а не ставить под угрозу все цели, такие компании, как CNC Markets, IG Index и т. Д., Зарабатывают деньги на торговых сборах, а программное обеспечение является средством для достижения цели, к которому вы получаете доступ бесплатно, просто имея учетную запись. Другая цель для программного обеспечения для торговли - коммерческие учреждения, такие как банки, инвестиционные менеджеры и т. Д. Я хотел бы получить довольно непроницаемый план того, как я собираюсь проникнуть на любой из этих рынков, прежде чем тратить слишком много времени и усилий.