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

А теперь появляются вопросы: если у нас много рекламных кампаний, как их распределять между серверами? Каждый сервер хранит все кампании или у каждого сервера свой уникальный список кампаний? Как синхронизировать счётчики между серверами? Как работать с модулями? Получать всю информацию по объекту и обрабатывать её в ядре? Отсылать список кампаний в модуль и получать обратно модифицированный список? И т.д. и т.п.

Распределённое ядро

В чём вообще проблема? Проблема в синхронизации счётчиком между серверами. Если одна и та же кампания отдаётся с нескольких серверов, может возникнуть такая ситуация, когда будет осуществлено большее количество показов/переходов/действий, чем надо. Как синхронизировать счётчики таким образом, чтобы перекрутов не происходило?

Самый простой способ — это распределить кампании между серверами таким образом, чтобы ни одна кампания не была одновременно на двух (и более) серверах. Например, кампании можно разделить по формату, как правило, на один запрос отдаётся список кампаний определённого формата, а не нескольких. Это хороший вариант в том случае, если количество запросов по одному формату не превышает количества запросов, которое способен обработать сервер. А если у нас один формат и миллиард запросов в сутки? Такой вариан не подойдёт.

Простых вариантов в голову не пришло. То, что мне более-менее понравилось, выглядит следующим образом. Есть множество “алгоритмов” (демон, отвечающий на запрос), есть “менеджер” (демон, распределяющий кампании между алгоритмами). Алгоритмы ни чего не знают о количестве показов/переходов/действий, они оперируют только ограниченими (показал, уменьшил ограничение по показам и так до нуля). Менеджер делит ограничения для каждой кампании между алгоритмами. В самом простом случае, ограничения делятся поровну. В таком случае, перекрутов не будет. Минусом такого варианта является централизованное управление, чего хотелось бы избежать. Но, пока других варинатов в голову не пришло, считаю его оптимальным.

Добавляем модуль

Допустим, у нас всё замечательно работает и тут мы решили, что надо улучшать качество показов, а давайте сделаем поведенческий таргетинг. Всю информацию мы хотим хранить и анализировать на серверах. Можно конечно что-то хранить в куках, но это не наш вариант.

Теперь нам надо получать информацию о пользователе, модифицировать её. Если модификация будет требовать отправки, как правило, малого количества данных, то количество требуемых данных о пользователе, при выборе кампании, может быть большим. В этом случае видится несколько вариантов: расширять каналы между серверами, максимально упаковывать данные, передаваемые между серверами либо перенести функционал алгоритма поближе к пользовательским данным.

Первый вариант хорош в том случае, если передаваемые данные между алгоритмом и модулем можно хорошо упаковать, когда данные модуля позволяют некоторую латентность, т.е. не важно, когда обновлённые данные появятся в других алгоритмах: мгновенно или через минуту. Помимо этого, это будет единственный возможный варинат в случае, когда модулей будет несколько и все они будут требовать передачи большого количества данных, функционал алгоритма можно будет “приблизить” только к одному модулю, а не всем сразу.

Второй варинат позволит сократить количество передаваемых данных по сети и ускорить общение с модулем, но не подойдёт в случае, если таких модулей несколько. В таком случае наиболее трафико-генерирующий или наименее латентный (требующий минимальные задержки при обновлении данных) модуль распологается рядом с алгоритмом, а остальные модули работают по первому варианту.

Итого

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

try { document.getElementById("_banner_").SetReturnValue( __flash__toXML(window.location.href.toString()) ); } catch (e) { document.getElementById("_banner_").SetReturnValue("“); }

Но это не код показа баннера, это код взаимодействия flash с JS. Дальнейшее изучение проблемы показало, что document.getElementById(”_banner_”) возвращает null.

Проблема, как оказалось, была в том, что объект flash не удалялся после удаления div-а, служащего контейнером для flash-баннера. Т.е. div вместе с object удалялся из DOM, но оставался в памяти браузера и продолжал отсылать сообщения, но, так как элемента document.getElementById(”_banner_”) больше не существовало, появлялась ошибка.

Решилась проблема небыстро, но решение оказалось простым. Надо было просто удалить object. Т.е. перед удалением контейнера надо удалить object и это решает проблему.

Потоки вместо процессов

В старой системе использовались процессы, по одному процессу на каждый воркер (воркер занимается разбором запроса и формированием ответа). Плюс такого подхода в том, что при падении одного из процессов, всегда есть ещё процесс/процессы, которые обработают запросы пока мастер (процесс, контролирующий работу воркеров, собирающий статистику и т.п.) не поднимет новый процесс взамен упавшему, т.е. мы потеряем только один запрос, на котором процесс упал. Минус в том, что для шаринга данных между процессами приходится пользоваться shared memory, а работа с ней не самое приятное занятие.

В новой системе используются потоки. При падении потока весь процесс валиться и, пока не будет поднят новый процесс, мы теряем все запросы. Плохо конечно, но, как показала практика, не критично. Падал демон всего несколько раз при тестировании, пока не были исправлены ошибки, приводящие к падению (а это критичные ошибки). Т.е., в реальной работе, плюс процессов не такой уж и плюс.

Зато как легко работать с общими данными. Достаточно легко удалось избежать использования всякого рода блокировок. Всё работает быстро и без головной боли.

Обновляем только обновлённые данные

В старой системе, по аналогии с прототипом (http://valuead.com/), функционал которого необходимо было повторить на 100%, данные из базы загружались с заданной периодичностью сразу все. Загружать ежеминутно по 5-10Мб данных — это норма.

В новой системе, в каждой из таблиц, данные из которой загружает демон, есть поле modified, в котором содержится дата последнего обновления объекта. При этом данное поле обновляется только в том случае, если изменённое значение/значения влияют на работу движка. Так как данные меняются достаточно редко, это позволяет, без особых нагрузок, проверять базу данных на обновления ежесекундно, что положительно сказывается на времени отклика системы.

Новая схема логирования/отчётности

В старой системе ежечасно собирались логи за текущие сутки, аггрегировались и формировалось несколько десятков всевозможных отчётов. В таком подходе я видел два минуса. Во-первых, обрабатывались логи не за последний час, а за всё время с полуночи, до текущего час. Т.е. каждый час повторно обрабатывались предыдущие часы, а это очень много лишней работы. Во-вторых, формировались десятки огромных отчётов, которыми либо вообще не пользовались, либо пользовались крайне редко (например, отчёт по баннерам-сайтам-городам, десятки баннеров помноженные на сотни сайтов и тысячи городов — это очень много).

В новой системе логи обрабатываются за предыдущий час один раз. По результатам обработки формируется одна таблица (баннер-сайт-час со счётчиками) из которой формируются другие таблицы с аггрегированием по тому или иному полю средствами базы данных (типа insert into … select from …). Так же формируются логи с аггрегацией по баннерам, по сайтам и по системе вцелом. В случае, если нам нужен произвольный отчёт, в интерфейсах формируется запрос на отчёт, система обрабатывает логи, аггрегирует данные и сохраняет результат в базу данных.

Плюса в новой схеме три. Во-первых, формируя отчёты из одной таблицы, мы исключаем возможность появления расхождений между разными отчётами, которая могла появиться в старой системе. Во-вторых, в базе данных не хранится куча ненужных отчётов. В-третьих, в любой момент мы можем придумать новый отчёт и получить его по прошедшим кампаниям, потому как все данные есть. Но есть и маленький минус. За 9 месяцев работы системы, с учётом архивирования прошедших кампаний, логи занимают порядка 140Гб. Но, с учётом того, какого размера современные винчестеры и сколько они стоят, это не такой уж и минус. Зато есть полная информация по каждому показу/клику/событию баннера.

Межпроцессное взаимодействие

В старой системе процессы общались через pipe. В новой системе потоки общаются через socketpair. Новый вариат мне показался более удобным, но есть один минус. Тестирование показало, что на моём ноутбуке, может быть выполнено не более 80 тыс. циклов запрос/ответ. Учитывая то, что каждый запрос сначала отправляется в воркер, потом в storage (сохранение данных в лог), это даёт не более 40 тыс. запрсов в секунду, и это без какой-либо другой работы, только обмен сообщениями. Для реальной системы нормально, но для перфекциониста, жевущему во мне, “Маловато будет” (с) Падал прошлогодний снег. В будущем придётся либо изобретать собственный велосипед (lock-free очереди для межпотокового взаимодействия), либо воспользоваться www.zeromq.org, что я быстрее всего и сделаю.

По новой системе пока никаких особых впечатлений кроме возможости поставить Google Chrom и другой нужный софт… А вот винт радует… Явное увеличение скорости загрузки приложений… В общем, я доволен

Во вторник его отвезли в больничку. Не смотря на то, что дорога была близкая, ехал он долго. Четырежды хозяин останавливался, остужал двигатель и доливал холодной воды в радиатор. А сегодня его забрали, здорового и бодренького. Заправили полный бак бензина и поехали кататься. Кататься просто так, а не по делам. Видимо хозяин соскучился, ведь старый диван всегда лучше новой табуретки

Поломав голову над парсером, я его родил и решил выложить доработанный скрипт для тех, кому не хочется мучаться самому

Скачать скрипт можно тут: ipgeobase.php.gz.

Для работы скрипта нужен файл cidr_ru_block.txt из архива db_files.tar.gz. Запускаться скрипт должен в том же каталоге, что и cidr_ru_block.txt. После работы скрипта появляются 3 файла: ipgeobase-states.dat, ipgeobase-cities.dat, ipgeobase-ips.dat.

В ipgeobase-states.dat храняться области в формате [идентификатор области]\t[название области].
В ipgeobase-cities.dat храняться города в формате [идентификатор города]\t[идентификатор области]\t[название города].
В ipgeobase-ips.dat храняться диапазоны ip-адресов в формате [IP от]\t[IP до]\t[идентификатор области]\t[идентификатор города].

При повторном запуске скрипт начитывает данные из ipgeobase-states.dat и ipgeobase-cities.dat (если они есть). Таким образом, при появлении новых городов или областей, идентификаторы “старых” записей не изменятся. IP храняться в виде беззнакового 32-битного числа.

Как-то так, надеюсь кому-то мой труд облегчит жизнь

P.S. Исправлена ошибка в скрипте, приводящая к появлению “левых” диапазонов, типа 774930432 774930431 92 658, спасибо Виталию (werzer) за наводку.

В одном месте на звонок не ответили, но перезвонили через 20 минут и, не представившись, спросили зачем звонили. Это было неожиданным, потому что на сайте был указан “многоканальный телефон”, а на деле оказался мобильный частного таксиста.

Вторым сайтом был www.500-50-50.ru. Вот эти ребята натурально удивили и порадовали. Приятная девушка приняла заказ. Секунд через 10 пришла SMS-ка о том, что заказ принят, с указанием куда и в какое время подать такси. Такси было заказано на 18:30. В районе 16:30 часов пришла SMS-ка с указанием модели машины, госномером, именем водителя и его мобильным телефоном. В 18:25 пришла SMS-ка о том, что такси ждёт у подъезда. Доехали без приключений. Через минуту после приезда пришла SMS-ка со “спасибками”, указанием стоимости поездки (290 рублей) и указанием что на накопительный счёт капнуло 14 рублей. В общем, молодцы, порадовали.

Основная идея, заложенная в реализацию — это использование пула выделенной памяти. Моя библиотека, реализующая пул памяти, не подразумевает повторное использование памяти, которая была освобождена всвязи с удалением элемента. Писать универсальную библиотеку, которая позволяла бы использовать память повторно, не посчитал целесообразным, потому как под разные данные выделяется память разного размера и контроль за свободными кусками снизит производительность пула. В случае со связными списками, мы имеем дело с кусками памяти одного размера, а потому проблем с контролем освобождённых кусков памяти нет.

В результате получилась библиотека со следующим набором функций:

cor_list_t *cor_list_init(int size);
int cor_list_pool_expand(cor_list_t *l);
void cor_list_destroy(cor_list_t *l);

cor_list_init — инициализация списка заданного размера (минимальный размер установлен в 16 элементов). Каждый раз, при добавлении нового элемента, когда не останеться свободных, пул будет расширятся на заданный размер. Размер стоит подобрать так, чтобы операции расширения были как можно более редкими.

cor_list_pool_expand — расширение списка. Эта функция вызывается при вставке новых элементов, если свободных нет. Принудительно вызывать эту функцию не требуется.

cor_list_destroy — освобождение памяти, занятой списком.

Остальные функции работы со списком написаны в виде макросов, для увеличения скорости работы:

#define cor_list_insert_head(_pv, _l)
#define cor_list_insert_tail(_pv, _l)
#define cor_list_insert_after(_pv1, _pv2, _l)
#define cor_list_insert_before(_pv1, _pv2, _l)
#define cor_list_delete(_pv, _l)
#define cor_list_move_head(_pv, _l)
#define cor_list_move_tail(_pv, _l)
#define cor_list_first(_pv, _l)
#define cor_list_last(_pv, _l)
#define cor_list_next(_pv)
#define cor_list_prev(_pv)
#define cor_list_value(_pv)

cor_list_insert_head — вставка новго элемента (_pv) в начало списка (_l). _pv — это указатель, который указывает на встравленный элемент.

cor_list_insert_tail — вставка нового элемента (_pv) в конец списка (_l).

cor_list_insert_after — вставка нового элемента (_pv1) после элемента (_pv2) в списке (_l).

cor_list_insert_before — вставка нового элемента (_pv1) перед элементом (_pv2) в списке (_l).

cor_list_delete — удаление элемента (_pv) из списка (_l).

cor_list_move_head — перемещение элемента (_pv) в начало списка (_l).

cor_list_move_tail — перемещение элемента (_pv) в конец списка (_l).

cor_list_first — получение в _pv первого элемента в списке (_l).

cor_list_last — получение в _pv последнего элемента в списке (_l).

cor_list_next — получение в _pv элемента, следующего за элементом _pv. Т.е. в _pv передаётся текущий элемент, и в него же сохраняется следующий. Если достигнут конец списка, возвращается NULL.

cor_list_prev — получение в _pv элемента, предыдущего, по отношению к элементу _pv.

cor_list_value — получение значения элемента _pv.

Исходники: cor_list.h, cor_list.c.

Если кому-то пригодится, буду рад