По чем редис мем

Хочю оливье

Происхождение

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

Мем создал пользователь Владислав Быков, об этом он сам рассказал “Мемепедии”. По словам автора, картинку с Тайсоном Бекфордом он форсил еще в июне – вот доказательства.

17 июля на волне флешмоба, в рамках которого пользователи “Вконтакте” троллили техподдержку официальных сообществ, Владислав решил отправить картинку с негром в группу “Грузоперевозки Санки”, написав сверху “хочу оливье” – это и стало началом мема.

Дальнейшему форсу мема поспособствовал пользователь Саша Бажура, 19 июля он опубликовал в том же паблике подборку скринов с изображением темнокожего парня. Паблик подхватил идею и стал делать свои вариации, меняя сначала фразу, а потом и самого персонажа. Админ “бреда” Даниил Зельтен подтвердил “Мемепедии”, что распространение мема началось с их группы, когда они запустили вторичный мем “редиса килограмчик”.

Постепенно мем стал проникать в другие сообщества с абстрактным контентом. Пользователи стали делать похожие картинки, помещая на них негров и приписывая “хочю арбуз”, “хочю крыжовник” и т.д. К середине августа мем достиг пика и стал массовым.

Значение

Мем “хочю оливье”, как и многие другие абстрактные мемы, лишен смысла. Его используют в качестве троллинга тех, кто “не в теме”, или для набегов на официальные сообщества. Со временем форс перерос во флешмоб, суть которого заключается в перекидывании друг другу похожих картинок.

Шаблон

Галерея

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

Redis на практических примерах

Redis — достаточно популярный инструмент, который из коробки поддерживает большое количество различных типов данных и методов работы с ними. Во многих проектах он используется в качестве кэшируещего слоя, но его возможности намного шире. Мы в ManyChat очень любим Redis и активно используем его в нашем продукте для решения огромного количества задач. Про некоторые интересные кейсы использования этой in-memory key-value базы данных я расскажу на примерах. Надеюсь, вам они будут полезны, и вы сможете применить что-то в своих проектах.

Рассмотрим следующие кейсы:

Кэширование данных

Давайте начнем с самого простого, один из самых популярных кейсов использования Redis — кэширование данных. Будет полезно для тех, кто не работал с Redis. Для тех, кто уже давно пользуется этим инструментом — можно смело переходить к следующему кейсу. Для того, чтобы снизить нагрузку на БД, иметь возможность запрашивать часто используемые данные максимально быстро, используется кэш. Redis — это in-memory хранилище, то есть данные хранятся в оперативной памяти. Ещё это key-value хранилище, где доступ к данным по их ключу имеет сложность O(1) — поэтому данные мы получаем очень быстро.

Получение данных из хранилища выглядит следующим образом:

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

Таким образом, мы запишем данные в Redis и сможем их считать по тому же самому ключу в любой нужный нам момент. Но если мы будем все время писать в Redis, данные в нем будут занимать все больше и больше места в оперативной памяти. Нам нужно удалять нерелевантные данные, контролировать это вручную достаточно проблематично, поэтому пускай redis занимается этим самостоятельно. Добавим к нашему ключу TTL (время жизни ключа):

По истечении времени ttl (в секундах) данные по этому ключу будут автоматически удалены.

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

Также редис позволяет получить массив значений по списку ключей:

И соответственно массовое удаление данных по массиву ключей:

Очереди

Используя имеющиеся в Redis структуры данных, мы можем запросто реализовать стандартные очереди FIFO или LIFO. Для этого используем структуру List и методы по работе с ней. Работа с очередями состоит из двух основных действий: отправить задачу в очередь, и взять задачу из очереди. Отправлять задачи в очередь мы можем из любой части системы. Получением задачи из очереди и ее обработкой обычно занимается выделенный процесс, который называется консьюмером (consumer).

Итак, для того, чтобы отправить нашу задачу в очередь, нам достаточно использовать следующий метод:

Со стороны консьюмера нам необходимо обеспечить получение задач из очереди, это реализуется простой командой чтения из листа. Для реализации FIFO очереди мы используем чтение с обратной записи стороны (в нашем случае мы писали через RPUSH), то есть читать будем через LPOP:

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

Тем самым мы вычитываем по одному сообщению из очереди. В случае если листа не существует (он пустой), то мы получим NULL. Каркас консьюмера мог бы выглядеть так:

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

Мы рассмотрели базовую реализацию простых очередей, но Redis позволяет строить более сложные очереди. Например, мы хотим знать о времени последней активности наших пользователей на сайте. Нам не важно знать это с точностью вплоть до секунды, приемлемая погрешность — 3 минуты. Мы можем обновлять поле last_visit пользователя при каждом запросе на наш бэкенд от этого пользователя. Но если этих пользователей большое количество в онлайне — 10,000 или 100,000? А если у нас еще и SPA, которое отправляет много асинхронных запросов? Если на каждый такой запрос обновлять поле в бд, мы получим большое количество тупых запросов к нашей БД. Эту задачу можно решать разными способами, один из вариантов — это сделать некую отложенную очередь, в рамках которой мы будем схлопывать одинаковые задачи в одну в определенном промежутке времени. Здесь на помощь нам придет такая структура, как Sorted SET. Это взвешенное множество, каждый элемент которого имеет свой вес (score). А что если в качестве score мы будем использовать timestamp добавления элемента в этот sorted set? Тогда мы сможем организовать очередь, в которой можно будет откладывать некоторые события на определенное время. Для этого используем следующую функцию:

Теперь возникает вопрос о том, как читать эту очередь. Если методы LPOP и RPOP для листа читают значение и удаляют его из листа атомарно (это значит, что одно и тоже значение не может быть взято несколькими консьюмерами), то sorted set такого метода из коробки не имеет. Мы можем сделать чтение и удаление элемента только двумя последовательными командами. Но мы можем выполнить эти команды атомарно, используя простой LUA скрипт!

В этом LUA скрипте мы пытаемся получить первое значение с весом в диапазоне от 0 до текущего timestamp в переменную val с помощью команды ZRANGEBYSCORE, если нам удалось получить это значение, то удаляем его из sorted set командой ZREM и возвращаем само значение val. Все эти операции выполняются атомарно. Таким образом мы можем вычитывать нашу очередь в консьюмере, аналогично с примером очереди построенной на структуре LIST.

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

Блокировки (Mutex)

Mutex (блокировка) — это механизм синхронизации доступа к shared ресурсу нескольких процессов, тем самым гарантируя, что только один процесс будет взаимодействовать с этим ресурсом в единицу времени. Этот механизм часто применяется в биллинге и других системах, где важно соблюдать потоковую безопасность (thread safety).

Для реализации mutex на базе Redis прекрасно подойдет стандартный метод SET с дополнительными параметрами:

где параметрами для установки mutex являются:

Чаще всего, когда мы пишем код, который пытается работать с shared ресурсом, который заблокирован, мы хотим дождаться его разблокировки и продолжить работу с этим ресурсом. Для этого можем реализовать простой метод для ожидания освободившегося ресурса:

Мы разобрались как ставить блокировку, теперь нам нужно научиться ее снимать. Для того, чтобы гарантировать снятие блокировки тем процессом, который ее установил, нам понадобится перед удалением значения из хранилища Redis, сверить хранимый хэш по этому ключу. Для того, чтобы сделать это атомарно, воспользуемся LUA скриптом:

Rate limiter

Достаточно частая задача, когда мы хотим ограничить количество запросов к нашему апи. Например на один API endpoint от одного аккаунта мы хотим принимать не более 100 запросов в минуту. Эта задача легко решается с помощью нашего любимого Redis:

Таким простым методом мы можем лимитировать количество запросов к нашему API, базовый каркас нашего контроллера мог бы выглядеть следующим образом:

Pub/sub

Pub/sub — интересный механизм, который позволяет, с одной стороны, подписаться на канал и получать сообщения из него, с другой стороны — отправлять в этот канал сообщение, которое будет получено всеми подписчиками. Наверное у многих, кто работал с вебсокетами, возникла аналогия с этим механизмом, они действительно очень похожи. Механизм pub/sub не гарантирует доставки сообщений, он не гарантирует консистентности, поэтому не стоит его использовать в системах, для которых важны эти критерии. Однако рассмотрим этот механизм на практическом примере. Предположим, что у нас есть большое количество демонизированных команд, которыми мы хотим централизованно управлять. При инициализации нашей команды мы подписываемся на канал, через который будем получать сообщения с инструкциями. С другой стороны у нас есть управляющий скрипт, который отправляет сообщения с инструкциям в указанный канал. К сожалению, стандартный PHP работает в одном блокирующем потоке; для того, чтобы реализовать задуманное, используем ReactPHP и реализованный под него клиент Redis.

Отправка сообщения в канал — более простое действие, мы можем сделать это абсолютно из любого места системы одной командой:

В результате такой отправки сообщения в канал, все клиенты, которые подписаны на данный канал, получат это сообщение.

Источник

По чем редис мем

Происхождение

Первым мемом из этой категории был «Хочю оливье» с изображением модели Тайсона Бекфорда. За основу было взято его фото, где он лежит, опираясь локтем о поверхность, а другой рукой держит голову.

Мем создал пользователь Владислав Быков, об этом он сам рассказал «Мемепедии». По словам автора, картинку с Тайсоном Бекфордом он форсил еще в июне — вот доказательства.

17 июля на волне флешмоба, в рамках которого пользователи «Вконтакте» троллили техподдержку официальных сообществ, Владислав решил отправить картинку с негром в группу «Грузоперевозки Санки», написав сверху «хочу оливье» — это и стало началом мема.

Дальнейшему форсу мема поспособствовал пользователь Саша Бажура, 19 июля он опубликовал в том же паблике подборку скринов с изображением темнокожего парня. Паблик подхватил идею и стал делать свои вариации, меняя сначала фразу, а потом и самого персонажа. Админ «бреда» Даниил Зельтен подтвердил «Мемепедии», что распространение мема началось с их группы, когда они запустили вторичный мем «редиса килограмчик».

Постепенно мем стал проникать в другие сообщества с абстрактным контентом. Пользователи стали делать похожие картинки, помещая на них негров и приписывая «хочю арбуз», «хочю крыжовник» и т.д. К середине августа мем достиг пика и стал массовым.

Значение

Мем «хочю оливье», как и многие другие абстрактные мемы, лишен смысла. Его используют в качестве троллинга тех, кто «не в теме», или для набегов на официальные сообщества. Со временем форс перерос во флешмоб, суть которого заключается в перекидывании друг другу похожих картинок.

Шаблон

Галерея

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Ориентирована на достижение максимальной производительности на атомарных операциях (заявляется о приблизительно 100 тыс. SET- и GET-запросов в секунду на Linux-сервере начального уровня [5] ). Написана на Си, интерфейсы доступа созданы для большинства основных языков программирования.

Содержание

Дизайн [ править | править код ]

Хранит базу данных в оперативной памяти, снабжена механизмами снимков и журналирования для обеспечения постоянного хранения (на дисках, твердотельных накопителях). Также предоставляет операции для реализации механизма обмена сообщениями в шаблоне «издатель-подписчик»: с его помощью приложения могут создавать каналы, подписываться на них и помещать в каналы сообщения, которые будут получены всеми подписчиками (как IRC-чат). Поддерживает репликацию данных с основных узлов на несколько подчинённых (англ. master — slave replication ). Также поддерживает транзакции и пакетную обработку команд (выполнение пакета команд, получение пакета результатов).

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

Модели данных [ править | править код ]

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

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

Восстановление данных и репликация [ править | править код ]

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

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

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

Система репликации Redis сама по себе не поддерживает автоматическую отказоустойчивость: если ведущий узел выходит из строя, необходимо вручную выбрать нового ведущего среди ведомых узлов; но имеется система Redis Sentinel, обеспечивающая мониторинг и автоматическое переключение.

Redis Sentinel [ править | править код ]

Redis Sentinel — специализированная система управления узлами Redis, выполняющая следующие задачи:

Redis Sentinel входит в состав Redis начиная с версии 2.6 (Sentinel 1 — устарел). Начиная с версии Redis 2.8 поставляется текущая версия — Sentinel 2.

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

Источник