Приветствую всех участников сообщества! Хочу воплотить в реальность свое давнее желание: написать свой собственный сканнер коэффициентов букмекерских контор. Задача не из простых. Краткое пояснение для тех кто не знает что это. Сканнер букмекерских контор (он же "вилочный сканнер") - это парсер который ежесекундно парсит коэффициенты сотен событий на десятках букмекерских контор. Далее он "склеивает" все события и ищет между ними т.н. "арбитражные ситуации". Думаю - в целом задача понятна. И важный нюанс: речь идет о т.н. live-событиях. Т.е. события, которые идут прямо сейчас.
Думаю над правильной архитектурой такого сервиса. Какие пока мысли:
- Изначально отказаться от стандартных СУБД (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 ГБ оперативки. Конечно, это нужно делать на нескольких серверах.
Какие проблемы я вижу в данной архитектуре:
Насколько я понимаю - если использовать In Memory DB, то и весь процесс парсинга должен происходить в этой же оперативке. И сам вебсервер должен быть на этом сервере. И это конечно же мягко говоря - неудобно) С другой стороны - если процесс парсинга выносить на другие сервера - то как доставлять данные в оперативку, где концентрируются все данные. Это ведь все таки не MySQL. И если под вебсервер выделять отдельный физический сервер - то как он будет получать доступ к InMemory DB, которая крутится в оперативке другого сервера? Вобщем - InMemory DB генерирует как ряд преимуществ, так и ряд проблем)
Прошу у сообщества умных размышлений, советов и критики ))
Простой
Простой
