Комментарии 14
Магические методы ведь тормозят, нет?
Скажите, а зачем
1) вызывать метод 5 раз в надежде «вдруг заработает»? Почему нельзя обеспечить стабильную работу редиса?
2) Функцию handle_exception() должен выполнять глобальный обработчик исключений в приложении, а не класс-обертка интерфейса
3) Из-за пункта 2 вы польностью лишаетесь возможности обрабатывать ожидаемые исключения при вызове функции
1) вызывать метод 5 раз в надежде «вдруг заработает»? Почему нельзя обеспечить стабильную работу редиса?
2) Функцию handle_exception() должен выполнять глобальный обработчик исключений в приложении, а не класс-обертка интерфейса
3) Из-за пункта 2 вы польностью лишаетесь возможности обрабатывать ожидаемые исключения при вызове функции
1)При непосредственной работе с Redis'ом без прокси, ошибкой чаще всего является подвисание коннекта к редису, в данном случае после реконнекта команда успешно отправляется со второй попытки. 5 раз, возможно слишком для чистого Redisa, но при работе с прокси очень помогло в отладке.
2)В этом случае будет весьма проблематично сделать реконнект отправить снова те же данные и продолжить работу, занеся в лог инфу о исключении. А сейчас у меня абсолютно все вылеты происходят из-за зависания коннекта.
2)В этом случае будет весьма проблематично сделать реконнект отправить снова те же данные и продолжить работу, занеся в лог инфу о исключении. А сейчас у меня абсолютно все вылеты происходят из-за зависания коннекта.
Надо решать вопросы нестабильной работы прокси или вообще отказываться от него. Балансировщик по ключам можно сделать и на уровне приложения, это будет лучше, чем писать такой код под прокси.
Увы даже прямой коннект к редису изредка подвисает, потому сейчас вопрос не в прокси а Redis или phpredis.
Балансировщик на уровне приложения рассматривался, но был отброшен, ибо приложение работает в нескольких копиях на нескольких серверах, а редису периодически требуется проводить решардинг. В данном случае намного проще сообщить только прокси о новой «таблице маршрутизации», чем сообщать об этом куче серверов с кучей копий приложения. Особенно проблемно это в свете того, что в php довольно накладно сообщить работающему приложению о том что поменялась таблица маршрутизации.
Возможно, с выходом redis-cluster от прокси получится отказаться.
Балансировщик на уровне приложения рассматривался, но был отброшен, ибо приложение работает в нескольких копиях на нескольких серверах, а редису периодически требуется проводить решардинг. В данном случае намного проще сообщить только прокси о новой «таблице маршрутизации», чем сообщать об этом куче серверов с кучей копий приложения. Особенно проблемно это в свете того, что в php довольно накладно сообщить работающему приложению о том что поменялась таблица маршрутизации.
Возможно, с выходом redis-cluster от прокси получится отказаться.
— Я бы отлавливал исключение RedisException вместо простого Exception
— Есть смысл повторных запросов в цикле, но там нужно делать принудительную паузу в несколько микросекунд
— Все магические методы тормозят, правильнее — прописать все функции вручную. Их не так уж и много.
— Конструкцию «or die()» следует забыть как страшный сон, а от die() избавиться
— Вероятно, проще отнаследовать свой класс-обёртку от класса Redis
— Логи современные пацаны пишут через file_put_contents
— Даже однострочные условия следует выделять фигурными скобками :)
— Есть смысл повторных запросов в цикле, но там нужно делать принудительную паузу в несколько микросекунд
— Все магические методы тормозят, правильнее — прописать все функции вручную. Их не так уж и много.
— Конструкцию «or die()» следует забыть как страшный сон, а от die() избавиться
— Вероятно, проще отнаследовать свой класс-обёртку от класса Redis
— Логи современные пацаны пишут через file_put_contents
— Даже однострочные условия следует выделять фигурными скобками :)
— RedisException, хорошая мысль
— не вижу смысла в паузе, в данном случае повторная ошибка вероятнее всего говорит о том что коннект висит уже 10 секунд, к тому же был произведен реконнект к Редису
— возможно, будет время сравню __call и прямое прописывание пары методов по быстродействию, если выигрыш в скорости действительно будет того что стоить — перепишу.
— в моей программе невозможность соединиться с редисом означает невозможность работы, потому завершение считаю закономерным.
— Ну тут мне во-первых было стремно наследовать класс, который поставляется как расширение, во-вторых не вижу смысла ибо все равно вручную переписывать все методы.
— согласен, но уж так вышло
— Мне привычней и удобней не ставить скобок там, где можно обойтись без них
— не вижу смысла в паузе, в данном случае повторная ошибка вероятнее всего говорит о том что коннект висит уже 10 секунд, к тому же был произведен реконнект к Редису
— возможно, будет время сравню __call и прямое прописывание пары методов по быстродействию, если выигрыш в скорости действительно будет того что стоить — перепишу.
— в моей программе невозможность соединиться с редисом означает невозможность работы, потому завершение считаю закономерным.
— Ну тут мне во-первых было стремно наследовать класс, который поставляется как расширение, во-вторых не вижу смысла ибо все равно вручную переписывать все методы.
— согласен, но уж так вышло
— Мне привычней и удобней не ставить скобок там, где можно обойтись без них
А скажите, почему бы вам не сделать репликацию, и не коннектится к локальной машине? В таком случае пропадут все тормоза с удалёнными коннектами.
На то есть несколько причин:
1)Пока redis вмещается в оперативку одной машины, но в ближайшие пол-года выйдет за ее рамки.
2)Программы клиенты размещаются на нескольких машинах, а репликация это использование объема RAM умноженного на количество клиентских машин и, соответственно, много дополнительных трат.
1)Пока redis вмещается в оперативку одной машины, но в ближайшие пол-года выйдет за ее рамки.
2)Программы клиенты размещаются на нескольких машинах, а репликация это использование объема RAM умноженного на количество клиентских машин и, соответственно, много дополнительных трат.
НЛО прилетело и опубликовало эту надпись здесь
Использую ваш класс в одном очень нагруженном проекте > 200 запросов (к веб серверу, к кешу более 1000) в секунду, работает стабильно.
В остальных случаях Rediska, которая к сожалению перестала развиваться. В редиске правда раздражает баг — не делает реконнект к серверу после таймаута «can't read from socket» и на долгих крон-скриптах часто вываливается с эксепшеном.
В остальных случаях Rediska, которая к сожалению перестала развиваться. В редиске правда раздражает баг — не делает реконнект к серверу после таймаута «can't read from socket» и на долгих крон-скриптах часто вываливается с эксепшеном.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пишем обработчик ошибок для phpredis