Назад | Перейти на главную страницу

Какая структура подходит для предоставления данных, которые обычно меняются за несколько секунд и оцениваются множеством людей (аналогично котировкам акций)?

Я знаком только с php и javascript, и полагаю, что php не подходит для обслуживания большого количества одновременных запросов. Я был бы признателен, если бы кто-нибудь мог познакомить меня с более подходящей структурой для этого, поскольку я пока действительно не знаю ключевое слово для Google. Большое спасибо.

Многоадресная рассылка и структура обмена сообщениями публикация / подписка (pub / sub), в зависимости от источника данных, вашей сети и местонахождения ваших слушателей.

На этот вопрос невозможно ответить - вы приходите со стороны «Я маленький веб-чувак» и задаете вопрос. Люди потратили миллионы, чтобы ответить.

Во-первых, что такое «похоже на котировку акций». Шутки в сторону. Я отслеживаю 5 обменов - все предложения CME Group. Я отслеживаю более четверти миллиона символов, большинство из которых неактивны. У активных есть СОТНИ обновлений в секунду (кстати, это те, которые меня действительно интересуют).

Во-вторых, что такое «много людей»? 100? 100 000?

Что доставить. Интранет? Интернет? Интранет, вы действительно хотите изучить что-то вроде Multicast. Интернет-многоадресной рассылки не существует.

Фреймворк? Ну, есть известная TIBCO. Цена реализации 7 знаков. Rithmic использует кое-что в разработанном хостинге, как и многие другие провайдеры в этой области.

Обновления? Что вы думаете о задержке доставки? То есть дома у меня 129 мс после обмена. Где это считается, я нахожусь в 1 мс от него. Это важно - поскольку вы не можете полагаться на «вытягивание», вы должны получать обновления.

ЭТО ДЕЙСТВИТЕЛЬНО тема Хью. Доступны привязки для ЛЮБОГО основного языка (C #, Java, C ++) и некоторых не столь распространенных. Бюджет и реальное использование начнут определять вашу матрицу решений.

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

Интенсивное кеширование с такими вещами, как Varnish + CDN и некоторое быстрое внутреннее хранилище (здесь много вариантов), очень поможет.

Что касается самого динамического бэкэнда, то было доказано, что Erlang поддерживает массовый параллелизм, и вы также получаете отличные результаты с Java / Scala.

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