It is possible to achieve a multi-master replication scheme beginning with MySQL version 3.23. MySQL Cluster supports conflict detection and resolution between multiple masters since version 6.3 for true multi-master capability for the MySQL Server.
Используем в своём проекте, как и Redis.
Все как-то разом забыли историю СУБД и то, что реляционные хранилища (выражающий отношение; связанный с выражением отношений между чем либо) пришли на смену нереляционным.
История циклична и вправду.
Есть запрос к источнику данных, есть зависимость, которая определяет актуальность этих данных.
CacheDependency в моем понимании может быть чем угодно и реализуется программистом.
Например:
Storage.cache(dependency).get(criteria)
Если dependency не обновился с момента последнего сохранения результата в кеш, то кеш и возвращаем.
Может вы про случай, когда зависимость нетривиальна и определение актуальности информации действительно сложная задача? Приведите утрированный пример, пожалуйста.
Synchronized cache, синхронизированный кеш – клиент вместе с данными получается метку последнего изменения и может спросить у поставщика не изменились ли данные, чтобы повторно из не запрашивать. Такой тип кеширования позволяет всегда иметь свежие данные, но очень сложен в реализации.
Не понимаю. Мы про бекенд говорим или про фронтенд?
Если про бекенд, то не вижу никакой проблемы в вводе CacheDependency.
Если про фронтенд, то опять же нет никакой проблемы — опрашиваем сервер по таймеру или через постоянное соединение отправляем диффы/обьекты клиенту.
В восторге! Связался со своим Дедом Морозом, вот, готовлю упаковывать вязаные носки(девушка связала несколько пар на зиму), книгу(не по айти), одну интересную электронную примочку и фотку из Питера с открыткой.
Интересно, что же мне придет :) :)
PS: Деанонимизации не боюсь, адрес нигде не засвечен. Вот теперь гадайте — я ваш Дед мороз или нет!
Скрипт делает свое дело по вполне четкой схеме. Рефакторить там нечего.
Это неподдерживаемый, нетестируемый, избыточный код. Это сложно назвать процедурным подходом, так как вы не выделяете процедуры(кроме синтетической main(), которая не нужна).
Поддерживаю комментарии VolCh и fso чуть выше.
Мне кажется, что вы неадекватны.
Я потратил своё время на прочтение вашей статьи, пример более-менее вменяемой имплементации, а также на указание явных ошибок. Если вы с чем-то не согласны, давайте обсудим как программисты. Это будет как-минимум не бесполезно.
Вы же говорите не предметно о каких-то абстрактных сущностях вроде «тона» и «уважения».
Тезис 1 — вам не ведом мой тон
Тезис 2 — мне не за что вас уважать, но и неуважать тоже
К слову, я бы не назвал приведенный выше кусок кода хорошим. Он имеет ряд недостатков — жесткое внедрение зависимости, отсутствие проверки данных в массиви $data, отсутствие интерфейса, отсутствие исключений для обработки и многое другое. Но его хотя бы можно рефакторить.
Ваш же код это откровенная бурда из ветвлений, создания буферов вывода, отправок сообщений Игорю и записи в БД.
Вы же понимаете, что то, что если для вас этот пахучий кусочек какашки работает(у нас у всех такие бывают, чего греха таить) совершенно не означает, что сообществу(а не дай бог новичкам) он будет полезен? Вреден.
Погодите-погодите. Давайте разберемся с терминологией и смыслом.
Напомню, что разговор идет об этой вот интересной фразе:
Гигабит легитимного хттп траффика свалит что угодно
Тоесть пока мы говорим о трафике.
Однако, чуть ниже вы пишете.
К тому же 10 гигабит http запросов и 10 гигабит http закачек несколько разные вещи, согласитесь.
Вы каким-то образом разделяете закачки, которые происходят по http протоколу и сами запросы.
Тоесть вот такая-вот штука:
GET /testFile.pngi HTTP/1.0
Host: test.com
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)
Referer: http://habrahabr.ru/
Это http запрос. но вот http ответ, который идет на этот запрос уже не учавствует в нашем обсуждении, верно?
Или это не http траффик? Почему по-вашему в http траффик входят только заголовки клиента?
Вы имели ввиду ситуацию, когда у меня одних хедеров от клиентов 10 гигабит?
По-поводу решений, всё в общем-то просто. Не упираться в IO, балансировать нагрузку между серверами, мониторить, масштабировать по мере необходимости.
У меня работающий клиент, который выдерживал более 70000 одновременных запросов на Zend
70 тысяч запросов на Zend это что значит? 70k req/sec? 70k req/day?
Происходит более 60 запросов в секунду к скрипту с 12 запросами к БД.
60 запросов в секунду это не DDOS :)
к скрипту с 12 запросами к БД.
Сколько миллионов записей на таблицу, какой характер запросов — write/read? Какая репликация / может у вас шардинг?
Более чем уверен, тот же сайт но на Zend уже давно бы валялся.
Вы зря так уверены :) Вопрос ведь не в интерпритаторе php. Ну включили APC, не гоняет теперь байткод каждый раз. А вот к БД нужно открыть коннект, закрыть коннект, прочитать что-то, записать что-то.
Я не к тому, что фреймворк — «плохо, плохо, руки прочь», я к тому, что вы как-то уж больно много нагрузки вкладываете в роутинг и десяток классов фреймворка. Что ZF, что yii.
Не холивара ради, но вы исходники того же Mongo читали? Там тоже есть индексы, query cache, parser, query optimizer и еще много страшных слов :)
Используем в своём проекте, как и Redis.
Все как-то разом забыли историю СУБД и то, что реляционные хранилища (выражающий отношение; связанный с выражением отношений между чем либо) пришли на смену нереляционным.
История циклична и вправду.
CacheDependency в моем понимании может быть чем угодно и реализуется программистом.
Например:
Если dependency не обновился с момента последнего сохранения результата в кеш, то кеш и возвращаем.
Может вы про случай, когда зависимость нетривиальна и определение актуальности информации действительно сложная задача? Приведите утрированный пример, пожалуйста.
Не понимаю. Мы про бекенд говорим или про фронтенд?
Если про бекенд, то не вижу никакой проблемы в вводе CacheDependency.
Если про фронтенд, то опять же нет никакой проблемы — опрашиваем сервер по таймеру или через постоянное соединение отправляем диффы/обьекты клиенту.
Интересно, что же мне придет :) :)
PS: Деанонимизации не боюсь, адрес нигде не засвечен. Вот теперь гадайте — я ваш Дед мороз или нет!
Это неподдерживаемый, нетестируемый, избыточный код. Это сложно назвать процедурным подходом, так как вы не выделяете процедуры(кроме синтетической main(), которая не нужна).
Поддерживаю комментарии VolCh и fso чуть выше.
Я потратил своё время на прочтение вашей статьи, пример более-менее вменяемой имплементации, а также на указание явных ошибок. Если вы с чем-то не согласны, давайте обсудим как программисты. Это будет как-минимум не бесполезно.
Вы же говорите не предметно о каких-то абстрактных сущностях вроде «тона» и «уважения».
Тезис 1 — вам не ведом мой тон
Тезис 2 — мне не за что вас уважать, но и неуважать тоже
?
К слову, я бы не назвал приведенный выше кусок кода хорошим. Он имеет ряд недостатков — жесткое внедрение зависимости, отсутствие проверки данных в массиви $data, отсутствие интерфейса, отсутствие исключений для обработки и многое другое. Но его хотя бы можно рефакторить.
Ваш же код это откровенная бурда из ветвлений, создания буферов вывода, отправок сообщений Игорю и записи в БД.
Вы же понимаете, что то, что если для вас этот пахучий кусочек какашки работает(у нас у всех такие бывают, чего греха таить) совершенно не означает, что сообществу(а не дай бог новичкам) он будет полезен? Вреден.
Напомню, что разговор идет об этой вот интересной фразе:
Тоесть пока мы говорим о трафике.
Однако, чуть ниже вы пишете.
Вы каким-то образом разделяете закачки, которые происходят по http протоколу и сами запросы.
Тоесть вот такая-вот штука:
Это http запрос. но вот http ответ, который идет на этот запрос уже не учавствует в нашем обсуждении, верно?
Или это не http траффик? Почему по-вашему в http траффик входят только заголовки клиента?
Вы имели ввиду ситуацию, когда у меня одних хедеров от клиентов 10 гигабит?
По-поводу решений, всё в общем-то просто. Не упираться в IO, балансировать нагрузку между серверами, мониторить, масштабировать по мере необходимости.
10 Гигабит в пике вчера, что я делаю не так? :)
70 тысяч запросов на Zend это что значит? 70k req/sec? 70k req/day?
60 запросов в секунду это не DDOS :)
Сколько миллионов записей на таблицу, какой характер запросов — write/read? Какая репликация / может у вас шардинг?
Вы зря так уверены :) Вопрос ведь не в интерпритаторе php. Ну включили APC, не гоняет теперь байткод каждый раз. А вот к БД нужно открыть коннект, закрыть коннект, прочитать что-то, записать что-то.
Я не к тому, что фреймворк — «плохо, плохо, руки прочь», я к тому, что вы как-то уж больно много нагрузки вкладываете в роутинг и десяток классов фреймворка. Что ZF, что yii.
Врете вы всё. Вы реально упирались в производительность php в ваших веб-приложениях?