3. 99% нагрузки на систему составляет именно эти клики/переходы. подобрать наиболее правильную/выгодную продажу основная задача такой системы. с учетом того, что параметров продажи/покупки около 15 и продавцов/покупателей около 20000, то масштабы вы себе представляете.
Насколько трудоёмкий этот выбор? Как его можно оптимизировать? Сколько можно выиграть, если позволять там себе разные допущения: неоптимальность цены клика в среднем порядка 10%, не очень четкая зависимость от времени суток, и т.д.? Можно ли запаздывать с показом статистики минут на дцать?
Если удастся сократить выбор ссылки до очень маленького времени, то можно поднять вот такой демон -
http://www.chabotc.com/phpsocketdaemon/. Будучи урезанным до функционала отдачи статичной строки при приеме подобной же, оно на моей домашней тачке (одноядерный athlon 3200+), выступая одновременно в качестве и сервера, и клиента, обслуживает само себя со скоростью 7000 запросов в секунду
Если у тебя будет парсинг заголовков http-запроса, это упадет где-то до 1000, что все равно довольно вкусная цифра. Но, поскольку все это выполняется в одном процессе и в одном треде, то там не должно быть никаких тяжелых и блокирующих операций, в том числе сложной логики подбора ссылки для отдачи.
Сама регистрация клика делается после того, как все отдалось клиенту, причем базу при этом трогать явно не рекомендуется. Пиши в локальные файлы. (если все-таки будешь это делать на fastcgi+fpm -
http://php-fpm.anight.org/extra_features.html#fastcgi_finish_request )
Обработка и агрегация логов делается исключительно в оффлайне. Если ты _смелый_, можешь попробовать решать ее с помощью какого-нибудь MapReduce framework'а типа Hadoop (
http://www.insight-it.ru/tag/mapreduce/ - для ознакомления). Но это уже другая история .-)
4. вот и надо сделать так что б система была масштабируемой и при выходе одной ноды не валилось все к чертям и меня не дергали в 3 часа ночи из за падения одного сервера из 20.
5. как разбалансить сам траф по http-нодам я умею, а вот как сделать отказоустойчивую MySQL базу пока не очень. Кластер мне очень нравится т.к. именно в нем отказ одной ноды не ведет к краху системы.
Под "одной нодой" понимется ndb management server?
Для HA есть неплохое решение на основе репликации -
http://code.google.com/p/mysql-master-master/ . Вкратце, в минимальной конфигурации: поднимается 2 сервера mysql, master-slave и одна машина с MMM, который следит за теми mysql-машинками. Как только mysql-master выходит из строя, его роль и ip берет на себя slave. Когда бывший мастер поднимается обратно, он становится слейвом для текущего мастера. И т.д.
-~{}~ 26.08.08 13:16:
вообще, кстати...
некоторое время назад я пришел к выводу, что отдельные части подобных систем нужно пытаться описать в рамках требуемых для них throughput, latency и объемов данных.
агрегация логов (формирование статистики) - по большей части - (большие?) объемы данных, high throughput и 15 minutes latency;
отдача ссылки - low latency;
отдача готовой статистики - medium latency;
и т.д.
Лично мне в таких терминах потом думается куда легче, потому что разные практики и готовые решения для решаемых задач тоже можно так описать:
мультиплексирование, memcache, ... - это обычно нужно для low latency;
mapreduce, hadoop - throughput;
всякие DFS, hybertable, hbase - объемы данных;
А mysql с этой точки зрения, наверное, ни рыба, ни мясо
Надеюсь, кому-нибудь эти мои размышления покажутся полезными.
не стоит оперировать общими терминами в применении к частным технологиям (таким как MySQL Cluster и MySQL Replication) =)
