Правильная архитектура сканнера арбитражных ситуаций?

Приветствую всех участников сообщества! Хочу воплотить в реальность свое давнее желание: написать свой собственный сканнер коэффициентов букмекерских контор. Задача не из простых. Краткое пояснение для тех кто не знает что это. Сканнер букмекерских контор (он же "вилочный сканнер") - это парсер который ежесекундно парсит коэффициенты сотен событий на десятках букмекерских контор. Далее он "склеивает" все события и ищет между ними т.н. "арбитражные ситуации". Думаю - в целом задача понятна. И важный нюанс: речь идет о т.н. live-событиях. Т.е. события, которые идут прямо сейчас.

Думаю над правильной архитектурой такого сервиса. Какие пока мысли:

  1. Изначально отказаться от стандартных СУБД (like MySQL), ибо в базу ежесекундно (а то и чащще!) нужно скидывать текущие значения коэффициентов с тысяч событий. (К примеру - в субботний вечер в час пик на разных конторах транслируется 200 событий на разные виды спорта. Нужно например парсить 30 контор. 200*30 = 6 000 трансляций. А контор, необходимых для сканирования - гораздо больше 20). Конечно же коэффициенты обновляются не каждую секунду. Но на динамичных видах спорта - очень часто. И нужно рассчитывать на то что в такую базу будет прилетать 6000 запросов обновления в секунду.

  2. Продолжение п.1: вместо стандартной БД использовать "In memory DB", т.е. что то, что висит в оперативке и обновляет данные максимально быстро. Сохранность данных здесь вообще не важна, ибо через 3 секунды актуальность данных уже пропадает.

  3. С одной стороны в эту базу будут писать данные парсеры, с другой стороны ежесекундно к этой базе ежесекундно будет обращаться функция построения итоговой таблицы тех самых арбитражных ситуаций. И уже к этой итоговой таблице будет обращаться вебсервер и по выбранным фильтрам пользователя будет показывать ему таблицу интересующих его вилок/валуев (тех самых арбитражных ситуаций). Кстати - у пользователя будет открыта страница, которая будет рефрешиться тоже раз в секунду. А учитывая что пользователей может быть тысяча - то и таких запросов тоже будет прилетать 1 000 в секунду.

  4. Что касается самого парсинга. Раньше каждую контору парсили по своему: какая то контора обновляла данные через сокеты, какие то - обычными http-запросами. И все существующие подобные сканеры посылали свои запросы через сокеты, или формировали свои http запросы. Но сегодня это все уже работает плохо, ибо конторы защищаются от парсинга разными методами. И самый простой и самый универсальный способ парсить данные - это парсинг браузером. Т.е. вы просто открываете в браузере страницу события и парсите ее. Но конечно же - за такую универсальность придется заплатить ресурсами. Каждая такая страница будет занимать мегабайты в оперативке. Предположим одна страница в среднем занимае 20 МБ оперативки. Тогда предполагаемые 6 000 открытых страниц займут 6 000 * 20 МБ = 120 000 МБ = 120 ГБ оперативки. Конечно, это нужно делать на нескольких серверах.



Какие проблемы я вижу в данной архитектуре:

Насколько я понимаю - если использовать In Memory DB, то и весь процесс парсинга должен происходить в этой же оперативке. И сам вебсервер должен быть на этом сервере. И это конечно же мягко говоря - неудобно) С другой стороны - если процесс парсинга выносить на другие сервера - то как доставлять данные в оперативку, где концентрируются все данные. Это ведь все таки не MySQL. И если под вебсервер выделять отдельный физический сервер - то как он будет получать доступ к InMemory DB, которая крутится в оперативке другого сервера? Вобщем - InMemory DB генерирует как ряд преимуществ, так и ряд проблем)

Прошу у сообщества умных размышлений, советов и критики ))
  • Вопрос задан
  • 293 просмотра
Пригласить эксперта
Ответы на вопрос 1
firedragon
@firedragon
Senior .NET developer
Теория без практики это отстой

Изначально отказаться от стандартных СУБД (like MySQL), ибо в базу ежесекундно (а то и чащще!) нужно скидывать текущие значения коэффициентов с тысяч событий. (К примеру - в субботний вечер в час пик на разных конторах транслируется 200 событий на разные виды спорта. Нужно например парсить 30 контор. 200*30 = 6 000 трансляций. А контор, необходимых для сканирования - гораздо больше 20). Конечно же коэффициенты обновляются не каждую секунду. Но на динамичных видах спорта - очень часто. И нужно рассчитывать на то что в такую базу будет прилетать 6000 запросов обновления в секунду.

Это вообще не нагрузка для сервера.

Продолжение п.1: вместо стандартной БД использовать "In memory DB", т.е. что то, что висит в оперативке и обновляет данные максимально быстро. Сохранность данных здесь вообще не важна, ибо через 3 секунды актуальность данных уже пропадает.


Да это разгрузит немного, но опять же нужно вовремя сбрасывать данные и греть кэш

С одной стороны в эту базу будут писать данные парсеры, с другой стороны ежесекундно к этой базе ежесекундно будет обращаться функция построения итоговой таблицы тех самых арбитражных ситуаций. И уже к этой итоговой таблице будет обращаться вебсервер и по выбранным фильтрам пользователя будет показывать ему таблицу интересующих его вилок/валуев (тех самых арбитражных ситуаций). Кстати - у пользователя будет открыта страница, которая будет рефрешиться тоже раз в секунду. А учитывая что пользователей может быть тысяча - то и таких запросов тоже будет прилетать 1 000 в секунду.


денормализуйте базу, уберите лишние индексы, создайте ноды только для чтения

Что касается самого парсинга. Раньше каждую контору парсили по своему: какая то контора обновляла данные через сокеты, какие то - обычными http-запросами. И все существующие подобные сканеры посылали свои запросы через сокеты, или формировали свои http запросы. Но сегодня это все уже работает плохо, ибо конторы защищаются от парсинга разными методами. И самый простой и самый универсальный способ парсить данные - это парсинг браузером. Т.е. вы просто открываете в браузере страницу события и парсите ее. Но конечно же - за такую универсальность придется заплатить ресурсами. Каждая такая страница будет занимать мегабайты в оперативке. Предположим одна страница в среднем занимае 20 МБ оперативки. Тогда предполагаемые 6 000 открытых страниц займут 6 000 * 20 МБ = 120 000 МБ = 120 ГБ оперативки. Конечно, это нужно делать на


Договаривайтесь, вместо что бы насиловать их сервера просто заплатите за api
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы