Зачем Redis?

Нет балда, когда у тебя слишком много экземпляров приложения и для них нужно несколько машин. Выгодно взять кучу дохлых нод и подключать-отключать их в зависимости от нагрузки, чем платить 24/7 за одну жирную ноду которая тащит нагрузку в час пик

Секунду-секунду... это что ж получается за система? Бизнес-логика на интерпретаторе, интерпретатор дергает по сети центральную БД и кэширует в локальной редиске? Я могу понять аргумент мастера костылей про то, что такая архитектура прокатывает для наследия, но лепить «это» с нуля? Когда есть куча NoSQL и NewSQL СУБД с бесконечным масштабированием и разными механизмами резервирования из коробки?

Макакин, ты сегодня без борща. Или расскажи как обеспечить когерентность кеша у 200 тыс. клиентов?

Я сегодня суши обожрался, аж поплохело.

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

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

у php уже приличное время есть всякие swoole для кунг-фу в стиле голанга.

другое дело, что его используют практически никогда, предпочитая коробочные вротпрессы/битриксы/whatever установленные на дефолтный LAMP…

у php уже приличное время есть всякие swoole для кунг-фу в стиле голанга

Там до голанга как до киева раком. Swoole — это скорее multiprocessing с общим кодом бинарных либ, но отдельной памятью у каждого интерпретатора. В каком-то смысле это близко к форкнутым процессам. Ты можешь указать на Swoole Tables, но я возражу, что это весьма куцое подобие реляционной таблицы, причем, как и у других подобных внешних решений, у этого есть проблема интеграции с языком: в ячейки таблицы можно сувать только строго определенные примитивные типы. То есть, сложные объекты и их связи отправляются лесом. Таким образом это больше всего похоже на какой-нибудь in-memory SQLite, который вполне себе есть в том же питоне.

другое дело, что его используют практически никогда, предпочитая коробочные вротпрессы/битриксы/whatever установленные на дефолтный LAMP

Можешь назвать причину, почему кто-то должен хотеть использовать Swoole? Адаптировать код под него все равно придется, а там уже возникнет вопрос «не проще ли нам переписать всё на Go?».

Там снизу@сверху, какой-то аноним тоже задался этим вопросом, относительно когерентности кэша, но в изначальном сообщении о ней не идет речи, а напротив говорится о том что это будет стендалон решение, так что общего кэша или состояния не будет. Ну а так, да, все зависит от того что это за кэш, что в нем хранится, как оно хранится, как будет производится выборка из него и есть ли какое-то общее состояние и связность. Ему пойдет локальный кэш, в принципе он ему даже пойдет и с состоянием, просто состояние надо оставить с серверной стороны, запросы станут менее жирными и их станет меньше.

Когда есть куча NoSQL и NewSQL СУБД

Реальной альтернативой являются распределённые БД, где клиент является частью этого распределения. А не вот эти все костыли.

Реальной альтернативой являются распределённые БД, где клиент является частью этого распределения. А не вот эти все костыли

NewSQL к этому и идет, только «клиент» там пишется на своем языке.

Можешь назвать причину, почему кто-то должен хотеть использовать Swoole?

вопрос области «cms vs mvc-framework», т.к. оба популярнеших фрэймворка умеют свулиться, никаких дополнительных телодвижений при разработке проекта не требуется.

почему люди продолжают выбирать cms? хз, видимо считают что так итоговая стоимость владения проектом будет ниже.

вопрос области «cms vs mvc-framework», т.к. оба популярнеших фрэймворка умеют свулиться, никаких дополнительных телодвижений при разработке проекта не требуется

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

Не буду задавать напрашивающийся вопрос, на*уа такие языки :))

Как то никогда не использовал redis поэтому мне ни тепло ни холодно от него. А вот php нужен конкретно.

Зачем нужен Redis если можно просто создать внутренний кэш в приложении

Two girls one cup. Приложения в одном инстансе существуют только на десктопе и ноуте разработчика

Вообще-то можно. Даже для работы в fastcgi.

Каким образом?

Не суть какая великая проблема

Зависит от того, как этот кэш наполняется. Всё может быть очень тяжело.

никогда не использовал redis

да ты в соседней теме с пдо и скуляйтом не справился, куда уж тебе до редиса...

да и нафига особенно учитывая что у beget один redis на всех. Я вообще твой код не видел ушастый.

при чем тут бегет, сынок?

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

нутк, шли бинарь в бейс62 и распаковывай.

мне пока не нужен redis еще понадобится, не беспокойся

который может выместиться другими запросами.

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

Каким образом?

Разделяемая память? Не, не слышал.

Разделяемая память?

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

когда у тебя пхп живёт один запрос

Ну ты хоть погугли, чтоли.

но так в этой среде не принято

Это в твоей среде так не принято, где даже про shared mem не в курсе. Как там у вас в 90-х, отопление-то есть?

Ну ты хоть погугли, чтоли.

Да в курсе я, что на нём можно хоть асинхронщину делать с евентлупом.

Это в твоей среде так не принято

Я вообще пхп не использую. А те кто его использует, в основном так же и пишут, как в 90-х.

где нужна атомарность данных

Она везде и всегда нужна. Но не всегда её можно себе позволить.

Я вообще пхп не использую

Сомневаюсь что ты вообще что-то используешь, кроме веществ. Т.к. даже не отдуплил о чём идёт речь.

не везде и не всегда, например, не важно что при запросе страницы с N-ного бекенда каким-то клиентом, бекенд обратился к одному из слейвов базы и тот отдал список новостей без одной, еще не отсинкавшейся на этот слейв новости, ведь в следующий раз этот клиент, попав на тот же или не тот бекенд и тот же или не тот слейв, эту новость уже получит и просто примет как факт, что новость опубликовали.

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

так, мне кааца ты сьехал от ответа, а мне интересно, какой же кейс требует атомарности?

Т.к. даже не отдуплил о чём идёт речь.

Если ты про вот эту хрень, то это даже не смешно. Из такого можно слепить только жалкое породие на нормальный монолит.

Т.к. даже не отдуплил о чём идёт речь.

Если ты про вот эту хрень, то это даже не смешно. Из такого можно слепить только жалкое породие на нормальный монолит

Мне люто бесит, когда вместо тезисного информативного ответа, пусть даже и не развернутого, начинают играть в «угадай о чем я думаю». У меня склонность считать это способом слиться из спора. Полагаю, он сам догадывается, что в пыхе развитых средств межинтерпретаторного взаимодействия нет. В питоне их пытались сделать в multiprocessing, но получилось тормознутое и забагованное говнище, которым в итоге мало кто пользуется.

Да он какой-то нервный сегодня. Подумаешь, закидали любимый ЯП дерьмом, первый раз как будто так происходит.

1. Чтобы горизонтально масштабировать большой кеш на несколько инстансов Redis.

2. Чтобы горизонтальное масштабировать приложение. Для ноды особенно актуально так как она однопоточная и в некоторых ситуациях может иметь смысл запустить несколько инстансов приложения даже на одном сервере.

3. Некоторые технологии разработки приложений не позволят кешировать данные в самом приложении. Например, на PHP это будет проблематично. Redis опять же поможет.

4. Чтобы кеш сохранялся при рестарте приложения.

5. Чтобы не велосипедить самому thread-safe высокопроизводительные словари с автопротуханием записей.

Надо понимать также, что пока приложение маленькое, пункты 1 и 2 могут быть не актуальны. Но если их предусмотреть заранее, то при росте приложения можно будет просто запустить больше инстансов redis. А если нет, то в панике переписывать пол-приложения, когда оно упадёт от нагрузки.

Если ты уверен на 146%, что твоему приложению не светит нагрузка при которой потребуется масштабировать бекэнд или кеш, другие пункты тебе тоже кажутся не важными, то можешь использовать кеширование на стороне приложения и расслабиться.

для ноды особенно актуально так как она однопоточная

Уже нет, приделали worker'ы.

Мне люто бесит, когда вместо тезисного информативного ответа

Какое слово в «разделяемая память» тебе непонятно? Что ты делаешь в профессии если тебе что-то в этой фразе непонятно?

Если ты про вот

Не прошло и пол-года, ты наконец-то загуглил. Это один из вариантов. Есть и другие альтернативы, в т.ч. готовые кэши.

жалкое породие на нормальный монолит

ЛУЛ, а по существу претензии будут? Ну и «нормальный монолит» звучит как «деревянное железо».

ЛУЛ, а по существу претензии будут?

shmop_read ( Shmop $shmop , int $offset , int $size ) : string

С такой сигнатурой не может быть ни претензий, ни вопросов. Такое только в помойку, проще юзать файлы в tmp. Если ты не видишь проблем, то не понятно, что ты делаешь в этой профессии:)

Давай разберем сказанное тобой по частям. Вопрос был:

Зачем нужен Redis если можно просто создать внутренний кэш в приложении? Ладно, если это кэш для нескольких приложений одновременно, но для одного-то зачем?

Чтобы горизонтально масштабировать большой кеш на несколько инстансов Redis
Чтобы кеш сохранялся при рестарте приложения

Большой кэш, особенно если нужна персистентность — это уже база данных.

Чтобы горизонтальное масштабировать приложение. Для ноды особенно актуально так как она однопоточная и в некоторых ситуациях может иметь смысл запустить несколько инстансов приложения даже на одном сервере

Как здесь помогает Redis?

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

Как ни странно, в случае PHP Swoole выручит.

Чтобы не велосипедить самому thread-safe высокопроизводительные словари с автопротуханием записей

А вот тут я задумался. Пожалуй, это основное назначение Redis, которое он хорошо выполняет и которое нельзя просто так заменить чем-то другим. По крайней мере, пока элементы кэша достаточно просты.

Надо понимать также, что пока приложение маленькое, пункты 1 и 2 могут быть не актуальны. Но если их предусмотреть заранее, то при росте приложения можно будет просто запустить больше инстансов redis. А если нет, то в панике переписывать пол-приложения, когда оно упадёт от нагрузки

Ты забываешь, что можно обосраться еще в десятке мест, если неэффективно спроектировать приложение, и таким образом тебе не поможет даже десяток машин, на которые смасштабированы твои редисы с приложениями. Особенно такой подход обожают облачные провайдеры, которые расскажут, как беспроблемно ты сможешь смасштабировать свое приложение, но не расскажут, сколько сотен тыщ долларов придет тебе в счетах.

Если ты уверен на 146%, что твоему приложению не светит нагрузка при которой потребуется масштабировать бекэнд или кеш, другие пункты тебе тоже кажутся не важными, то можешь использовать кеширование на стороне приложения и расслабиться

В этой логике непонятно, почему бы не расслабиться и не использовать кэш на клиенте сразу? Каналы-то не резиновые, хоть и достаточно широкие нынче.

ну почему нет? вот тот самый шмем, он и есть IPC.

файлы в тмп? а слабо в файл записать класс без сериализации?

Спасибо. Вот пункт 5 я уже прочувствовал. Да и 3 в Ноде не так уж и беспечален - чтобы данные были доступны из всех модулей, надо хранить этот кэш в global… и что-то мне этот вариант не нравится.

ну почему нет? вот тот самый шмем, он и есть IPC

Redis тоже является IPC. И текстовой файл. Только всё это — неюзабельный и ненадежный мусор, настолько, что проще уже на Си писать сервер, чем с этими штуками, но на пыхе. Потому-то вместо них используют серверы очередей и redis/memchached.

файлы в тмп? а слабо в файл записать класс без сериализации?

Давай, расскажи мне, как ты будешь через любое пыховое IPC пересылать класс без сериализации.

а слабо в файл записать класс без сериализации?

Допустим нет. Но что с ним делать дальше? Зачем нужен кэш на уровне приложения, где нельзя держать никаких структур в нормальном виде. Вот в классе дерево, туда добавляют 1 элемент и весь класс уходит в кэш, а потом обратно. Кэш на стороне приложения нужен, чтобы не дрочить sql/eav на операциях, в которых они не сильны. Этот шаред - как редис для бедных, которым говнохостер его не даёт.

Только всё это — неюзабельный и ненадежный мусор

так и запишем - SysV шаредмем это мусор.

а у пыха два вида шмема )) один обычный, а второй спец пыховый, не знал?

Падажи, не пали контору, путь ещё немного погуглят…

Допустим нет

т.е. не слабо на пыхе записать в файл класс пыха не сериализуя этот класс? покажи!

Этот шаред - как редис для бедных, которым говнохостер его не даёт

а редис случаем шмем не использует?

почему люди продолжают выбирать cms?

Вероятно потому, что там из коробки уже есть редактор контента. То есть за 1-2 дня можно запустить пустой сайт с натянутым дизайном и передать его контент-менеджерам для заполнения.

Только всё это — неюзабельный и ненадежный мусор

так и запишем - SysV шаредмем это мусор

Ну так я о том и пишу: в таких раскладах проще писать веб сервер на Си, чем на пыхе.

ну, пустой сайт с блогом и каталогом за 1-2 дня и на фрэйморке делается, не обязательно даже в php упарываться

Главное в CMS, как я уже сказал: админка для контент-менеджеров с rich text editor и загрузкой картинок по аналогии с вордпрессом, битриксом и т.д. Не упарываясь, даже готовую Admin panel не прикрутишь, а если упарываться, то всё равно будет велосипед.

Где ж проще то?