Если вы использовали Redis, давайте сначала поговорим об этих сценариях.
Кэш строк
//举例
$redis->set();
$redis->get();
$redis->hset();
$redis->hget();
скопировать код
очередь
//举例
$redis->rpush();
$redis->lpop();
$redis->lrange();
скопировать код
опубликовать подписаться
//举例
$redis->publish();
$redis->subscribe();
скопировать код
прилавок
//举例
$redis->set();
$redis->incr();
скопировать код
Таблица лидеров
//举例
$redis->zadd();
$redis->zrevrange();
$redis->zrange();
скопировать код
Межколлекторные операции
//举例
$redis->sadd();
$redis->spop();
$redis->sinter();
$redis->sunion();
$redis->sdiff();
скопировать код
пессимистический замок
Объяснение: Пессимистическая блокировка, как следует из названия, очень пессимистична.
Каждый раз, когда я иду за данными, я думаю, что другие изменят их, поэтому каждый раз, когда я получаю данные, они блокируются.
Сценарий: Если в проекте используется кэш и для кэша задано время ожидания.
Когда объем параллелизма относительно велик, если нет механизма блокировки, момент истечения срока действия кеша
Большое количество одновременных запросов будет напрямую запрашивать базу данных через кеш, вызывая лавинный эффект.
/**
* 获取锁
* @param String $key 锁标识
* @param Int $expire 锁过期时间
* @return Boolean
*/
public function lock($key = '', $expire = 5) {
$is_lock = $this->_redis->setnx($key, time()+$expire);
//不能获取锁
if(!$is_lock){
//判断锁是否过期
$lock_time = $this->_redis->get($key);
//锁已过期,删除锁,重新获取
if (time() > $lock_time) {
unlock($key);
$is_lock = $this->_redis->setnx($key, time() + $expire);
}
}
return $is_lock? true : false;
}
/**
* 释放锁
* @param String $key 锁标识
* @return Boolean
*/
public function unlock($key = ''){
return $this->_redis->del($key);
}
// 定义锁标识
$key = 'test_lock';
// 获取锁
$is_lock = lock($key, 10);
if ($is_lock) {
echo 'get lock success<br>';
echo 'do sth..<br>';
sleep(5);
echo 'success<br>';
unlock($key);
} else { //获取锁失败
echo 'request too frequently<br>';
}
скопировать код
оптимистическая блокировка
Объяснение: Optimistic Lock, как следует из названия, очень оптимистичен.
Каждый раз, когда я иду получать данные, я думаю, что другие не будут их модифицировать, поэтому они не будут заблокированы.
Команда watch будет отслеживать заданный ключ.При выполнении, если отслеживаемый ключ изменился после вызова watch, вся транзакция завершится ошибкой.
Вы также можете вызывать watch несколько раз, чтобы отслеживать несколько ключей. Таким образом, к указанному ключу можно добавить оптимистическую блокировку.
Обратите внимание, что ключ наблюдения действителен для всего соединения, как и транзакция.
Если связь потеряна, и часы, и транзакция автоматически очищаются.
Конечно, команды exec, discard и unwatch удалят весь мониторинг соединения.
$strKey = 'test_age';
$redis->set($strKey,10);
$age = $redis->get($strKey);
echo "---- Current Age:{$age} ---- <br/><br/>";
$redis->watch($strKey);
// 开启事务
$redis->multi();
//在这个时候新开了一个新会话执行
$redis->set($strKey,30); //新会话
echo "---- Current Age:{$age} ---- <br/><br/>"; //30
$redis->set($strKey,20);
$redis->exec();
$age = $redis->get($strKey);
echo "---- Current Age:{$age} ---- <br/><br/>"; //30
//当exec时候如果监视的key从调用watch后发生过变化,则整个事务会失败
скопировать код
Было использовано большинство описанных выше сценариев, но файл Rdb не упоминался.
«Правильно, использовал Redis, но не знал Rdb-файл, вас подстрелили?»
Что такое файл RDB и что он делает
Как незаменимое постоянное оружие в разработке интернет-продуктов, Redis обладает высокой производительностью, богатой структурой данных и прост в использовании.Однако он также слишком прост в использовании.Идя к концу, последняя проблема заключается в том, что использование памяти Redis продолжает расти, но я не знаю, полезны ли данные в нем, и можно ли их разделить и очистить.Самое ужасное, что после того, как сервер выйдет из строя, все данные в базе данных Redis будут храниться , Все потеряно.
Например, когда память увеличивается, а производительность снижается, при настройке производительности мы хотим знать:
-
Какие клавиши занимают много памяти?
-
Хотите знать пространство, занимаемое каждым ключом?
-
Хотите знать, для чего хранятся ключи, занимающие много места?
-
Хотите знать важность ключей, которые занимают много места, можете ли вы удалить их сразу, когда производительность низкая?
-
Я хотел бы знать, какая сторона бизнеса и какой разработчик создали эти ключи? Так вы сможете с ним общаться.
попробуй решить проблему
1. Сначала передайте команду keys *, чтобы получить все ключи, а затем получите все содержимое по ключу.
-
Преимущества: Прямая сетевая передача без использования жесткого диска машины Redis.
-
Недостатки: если ключевых данных слишком много, команда keys может напрямую привести к зависанию Redis, что повлияет на использование бизнеса или сделает слишком много запросов к Redis, потребляет много ресурсов и слишком медленно перемещает данные.
2. Откройте aof и получите все данные через файл aof.
-
Преимущества: не нужно влиять на сервис Redis, полностью автономная работа, достаточно безопасно.
-
Недостатки: некоторые экземпляры Redis часто пишутся, поэтому они не подходят для включения AOF, и их универсальность не является сильной; файлы AOF могут быть очень большими, а передача и парсинг слишком медленными и неэффективными.
3. Используйте bgsave для получения файла rdb и получения данных после синтаксического анализа.
-
Преимущества: зрелый механизм, хорошая надежность, относительно небольшие файлы, высокая эффективность передачи и разбора.
-
Недостатки: хотя bgsave разветвляет дочерний процесс, это все же может привести к зависанию основного процесса на определенный период времени, что может повлиять на бизнес.
После всесторонней оценки было принято решение использовать bgsave from nodes для получения файлов rdb в периоды низких пиковых нагрузок, что относительно безопасно и надежно, а также может охватывать все бизнес-кластеры Redis.
Иными словами, каждый экземпляр автоматически генерирует файл .rdb каждый день в период низкой пиковой нагрузки, даже если данные отчета задерживаются на один день, это допустимо.
«О, получается, что файл .rdb — это файл кеша диска, так как же включить сохраняемость?»
Ниже приводится краткое введение в постоянство Redis.
Redis поддерживает сохраняемость двумя способами: один — RDB, а другой — AOF.
RDB — это метод, используемый Redis для обеспечения устойчивости, который заключается в записи текущего набора данных в памяти и моментального снимка на диск.
РДБ - автоматический
Метод RDB (Redis DataBase) выполняется с помощью моментальных снимков. При выполнении определенных условий Redis автоматически делает снимки всех данных в памяти и сохраняет их на жестком диске. RDB — это метод сохранения Redis по умолчанию.
vim /usr/local/redis/conf/redis.conf
save 900 1 #15分钟内有至少1个键被更改
save 300 10 #5分钟内至少有10个键被更改
save 60 1000 #1分钟内至少有10000个键被更改
#以上条件都是或的关系,当满足其一就会进行快照。
dbfilename "dump.rdb" #持久化文件名称
dir "/data/dbs/redis/6381" #持久化数据文件存放的路径
#配置文件修改后,需要重启redis服务。
скопировать код
Его также можно настроить через командную строку:
CONFIG GET save #查看redis持久化配置
CONFIG SET save "100 20" #修改redis持久化配置
#使用命令行的方式配置,即时生效,服务器重启后需要重新配置。
скопировать код
РБД — Руководство
-
save
Эта команда заблокирует текущий сервер Redis.Во время выполнения команды сохранения Redis не может обрабатывать другие команды, пока не завершится процесс RDB.
Очевидно, что эта команда будет долго блокироваться для экземпляров с большим объемом памяти, что является фатальным недостатком.
-
bgsave
При выполнении этой команды Redis асинхронно в фоновом режиме выполнит операцию создания моментального снимка, и этот моментальный снимок также может отвечать на запросы клиентов.
Конкретная операция заключается в том, что процесс Redis выполняет операцию разветвления для создания дочернего процесса.Процесс сохранения RDB отвечает за дочерний процесс и автоматически завершается после завершения. Блокировка происходит только на этапе форка.
AOF
AOF (режим APPEND ONLY) записывает состояние базы данных, сохраняя команды записи (такие как set, sadd, rpush) на сервер Redis, то есть сохраняя ваши операции записи в базу данных Redis.
Файл журнала конфигурации выглядит следующим образом:
vim /usr/local/redis/conf/redis.conf
dir "/data/dbs/redis/6381" #AOF文件存放目录
appendonly yes #开启AOF持久化,默认关闭
appendfilename "appendonly.aof" #AOF文件名称(默认)
appendfsync no #AOF持久化策略
auto-aof-rewrite-percentage 100 #触发AOF文件重写的条件(默认)
auto-aof-rewrite-min-size 64mb #触发AOF文件重写的条件(默认)
#上面的每个参数,可以找资料了解下,不做多解释了。
скопировать код
Преимущества и недостатки RDB и AOF можно увидеть выше.
На данный момент мы узнали о некоторых конфигурациях персистентности Redis, и детали в них рекомендуется запрашивать уместной информацией для исследования.
Далее мы получили файл rdb через предыдущий шаг, что эквивалентно получению данных экземпляра Redis.
-
Разберите файл rdb, чтобы получить значения ключа и значения.
-
Оцените потребление памяти на основе соответствующей структуры данных и содержимого.
-
Статистика и формирование отчетов.
инструмент анализа
-
снежок рдр:
https://github.com/xueqiu/rdr
-
Redis-RDB-инструменты:
https://github.com/sripathikrishnan/redis-rdb-tools
резюме
-
Объясняет часто используемые сценарии использования Redis в работе.
-
Объясняет два способа сохранения Redis (RDB, AOF).
-
Рекомендуются два инструмента для анализа rdb.
Используя Redis, чтобы узнать, как делать постоянные снимки данных Redis на сервере, как использовать инструменты для анализа файлов rdb и, наконец, с помощью проанализированных данных, вы, в свою очередь, можете внести некоторые предложения по использованию Redis.
То же самое и с другими точками знаний, мы не можем просто остановиться на простом вызове метода и почувствовать, что разбираемся в этой технологии!
Леново
На самом деле, из проанализированных выше данных невозможно определить, какой стороне принадлежит этот ключ, какой разработчик его создал, важен ли он и т. д. Так что же нам делать?
-
Разработайте спецификацию использования Redis Key команды разработчиков, которую можно получить, назвав ключ:
-
Какому бизнесу он принадлежит (плюс доменное имя)
-
Какой это тип данных (плюс отметка типа данных)
-
Устанавливать ли время истечения срока действия
-
...
Единая платформа применяется для Redis Key, только после применения его можно использовать:
-
заполнить заявитель
-
Заполните время заявки
-
Заполнить заявку бизнес-партии
-
Заполните тип данных
-
Важность заполнения ключа
-
Заполните, есть ли у ключа срок действия
-
Сгенерировать каноническое имя ключа в соответствии с заполненным пунктом
-
... (и так далее, что нужно отметить)
Нам удалось проанализировать содержимое rdb-файла экземпляра redis выше и интегрировать проанализированное содержимое с данными, запрошенными унифицированной платформой, чтобы проанализировать скорость передачи ключей, использование памяти, распределение различных типов данных и использование памяти. Top Значение 100 и так далее.
Благодаря эксплуатации и обслуживанию мы можем узнать о взаимосвязях конфигурации между каждым сервером и экземпляром, а затем узнать о частоте проходов, использовании памяти, распределении различных типов данных и использовании памяти на определенном сервере (N экземпляров). Значение из Топ-100 и так далее.
Таким образом, в фоновой системе вы можете видеть, какой сервер и какой экземпляр используется, что решает проблему злоупотребления Redis и не может быть отслежено.