У меня есть три процесса на одном компьютере:
Вот схема различных событий:
T M R
| | |
O-------->+ FLUSHDB
| | |
+<--------O (FLUSHDB acknowledge as successful)
| | |
O-------->+ SET key value
| | |
+<--------O (SET acknowledge as successful)
| | |
O--->+ | Start nginx including my module
| | |
| O--->+ GET key
| | |
| +<---O (SUCCESS 80% and FAILURE 20%)
| | |
Тест очищает базу данных Redis с помощью FLUSHDB, а затем добавляет ключ с помощью SET key value. Затем тест запускает nginx, включая мой модуль. Там время от времени модуль nginx GET key дает сбой.
Примечание 1. Я не использую ASync реализацию Redis.
Примечание 2: я использую библиотеку C hiredis.
Возможно ли, что между SET и последующим GET с тем же ключом будет задержка, которая объясняет, что этот процесс время от времени давал сбой? Есть ли способ убедиться, что SET действительно выполняется после возврата функции redisCommand()?
ВАЖНАЯ ЗАМЕТКА:, если я запускаю один такой тест и в моем модуле nginx происходит сбой GET, ключ появляется в моем Redis:
redis-cli
127.0.0.1:6379> KEYS *
1) "8b95d48d13e379f1ccbcdfc39fee4acc5523a"
127.0.0.1:6379> GET "8b95d48d13e379f1ccbcdfc39fee4acc5523a"
"the expected value"
Итак
SET "8b95d48d13e379f1ccbcdfc39fee4acc5523a" "the expected value"
работал как положено. Только GET не удалось, и я бы предположил, что это произошло потому, что это произошло слишком быстро. Любая идея, как решить эту проблему?





Нет, задержки между set и get нет. То, что вы делаете, должно работать.
Попробуйте запустить команду монитора в отдельном окне. Когда это не удается - команда set идет до/после команды get?
Хорошо! Я нашел свой баг. nginx не готов на 100% systemd (по крайней мере, в Ubuntu 16.04), поскольку он может вернуться до создания файла PID. Таким образом, дочерний процесс должен создавать файл PID, а родитель не ждет, чтобы убедиться, что это сделано правильно...
Это очень классная функция.
redis-cli monitorСпасибо за информацию. До сих пор я не видел, чтобы это потерпело неудачу, но для меня это только начало дня.