Англійська для потоків Redis

Потоки Redis надають вам журнал, який можна лише додавати, з групами користувачів, подібними до Kafka, але термінологія перетинається лише на достатній відстані з іншими структурами даних Redis і словником Kafka, щоб спричинити справжню плутанину у дискусіях щодо дизайну. Цей посібник розв’ язує ці проблеми.

Ключовий словник

** Stream ** — тип даних журналу, що дозволяє лише додавання в Redis ( XADD, XREAD ), де кожен запис отримує унікальний, впорядкований ідентифікатор, відмінний від каналу pub/sub, оскільки записи зберігаються і можуть бути відтворені знову. “Переключити з pub/ sub на потік — повідомлення pub/ sub втрачаються, якщо ніхто з підписників не слухає, але потік зберігає запис для споживачів, які з’ єднаються пізніше.”

Entry ID — унікальний ідентифікатор, який Redis присвоює кожному запису потоку, форматований як <timestamp>-<sequence>, використовується для замовлення і для відновлення споживання з певної точки. “Ми зберігаємо останній оброблений ID запису в нашій власній таблиці контрольних точок, тому перезапуск може бути відновлений з XREAD в правильному положенні.”

** Група споживачів ** — названа група споживачів, які спільно виконують роботу з читання з потоку, з Redis, що відстежує, які записи кожного споживача було доставлено за допомогою XREADGROUP. “Обидві робочі копії належать до однієї групи споживачів, отже Redis розділяє вхідні записи між ними замість того, щоб доставляти кожен запис двічі.”

** Список очікуваних записів (PEL) ** — запис записів, які було доставлено, але ще не підтверджено, для кожної групи користувачів, використовується для виявлення і повторної обробки повідомлень, які користувач не зміг завершити. “PEL зростає, тому що наш споживач зазнає аварії перед викликом XACK — ці записи застрягли як доставлені, але не підтверджені.”

** XACK ** — команда, яку викликає користувач після успішної обробки запису, вилучаючи його зі списку очікуваних записів для цієї групи користувачів. “Упевніться, що XACK виконується тільки після того, як запис бази даних дійсно закінчиться — якщо заблокувати перед цим, то ризикуєте втратити запис, якщо запис зазнає невдачі.”

** XCLAIM / відключення споживача** — механізм передачі права власності на застарілий запит (запит, який не був заблокований занадто довго) від припущенно мертвого споживача до здорового. “Ми запускаємо періодичний XCLAIM sweep, щоб підібрати записи від користувачів, які зламалися під час обробки, тому нічого не залишається непідтвердженим назавжди.”

Звичайні фрази

• «Чи це поток або публікація / суб — чи нам дійсно потрібні записи, щоб триматись для пізніх споживачів?»
• «Що таке ринок цінних паперів і як він впливає на ринок цінних паперів?»
• «Чи зберігаємо ми вхідний ідентифікатор як контрольну точку, або перезапуск втратив би наше місце в потоці?»
• Чи є це споживач, який скаче до або після того, як фактичний побічний ефект завершиться?
• Чи нам потрібен XCLAIM sweep для застарілих запитів, або ж споживачі настільки надійні, що нам його ще не потрібно?»

Приклади висловлювань

Пояснення потоку проти pub/ sub у документації з розробки: “Ми вибрали поток над pub/sub, тому що нам потрібна принаймні одна доставка - споживач, який ненадовго не працює, не повинен втрачати записи, які прибули, коли він був офлайн.”

Звітування про застряглу групу споживачів: “Список очікуваних записів збільшився до декількох тисяч — схоже, що платіжний споживач припинив аcking кілька годин тому, хоча він все ще з’ єднаний, що свідчить про безшумну помилку в циклі обробки.”

Обговорення проекту відключення: “Ми повинні додати XCLAIM sweep з розумним порогом часу простою, так що якщо споживач помирає в середині обробки, інший екземпляр підбирає запис назад замість того, щоб він сидів в PEL назавжди.”

Професійні поради

• При обговоренні потоків Redis вкажіть stream, а не «channel» — «channel» означає семантику pub/sub, яка не зберігає записи так, як це робить поток.
• Посилання на ** список очікуваних записів ** за назвою при діагностиці відставання - це конкретний, перевіряний стан, який пояснює, чи споживачі не відстають.
• Будьте точні щодо ** коли відбувається аcking ** відносно фактичної роботи — аcking занадто рано є поширеним джерелом втрати даних при аварії користувача.
• Згадайте ** групу споживачів ** явно під час опису розподілу навантаження, оскільки два споживачі, які читають один і той же потік без спільної групи, отримають кожен по одному запису, а не розділене навантаження.

Практичні вправи

1. Поясніть одним реченням, чому поток можна вибрати замість pub/ sub.
2. Написати звіт про помилку, у якому буде описано групу споживачів зі зростаючим списком незавершених записів.
3. Опишемо, вашими словами, для чого використовується XCLAIM.

Розрізняють: практичний підхід

Погляньмо правді в очі; технічне спілкування не просто про висловлювання фактів. Це про передачу наміру і управління очікуваннями, особливо коли речі не відразу ідеальні. Під час роботи з потоками Redis і групами користувачів ви часто стикаєтеся зі сценаріями, коли користувачі не підтверджують повідомлення бездоганно або коли список очікуваних записів відображає невідповідність між очікуваним і фактично обробленим. Зрозуміти нюанси цього процесу - особливо з точки зору чіткого спілкування - є ключовим для ефективного зневадження і співпраці.

Одна з найпоширеніших проблем виникає, коли член групи споживачів тимчасово не доступний, що призводить до накопичення записів у списку очікування. Повідомлення Slack може звучати так: «Гей команда, ми бачимо збільшення очікуваних записів в черзі потоків через короткий відключення на Consumer 3. Ми перезапустили їх, але це забирає деякий час, щоб все наздоганяти. “Зауважте використання “збільшення” - кількісне вираження проблеми дає негайний контекст. Аналогічно, опис * причини * затримки (« короткий перерив ») додає цінну інформацію, окрім простого повідомлення « очікування записів є високим ». Опис запиту на завантаження може містити наступні відомості: « Дослідження затримки в черзі потоків, спричиненої проблемами з’ єднання з користувачем 2. Ми реалізували логіку повторних спроб для обробки цих ситуацій і зменшили ймовірність майбутніх затримок»

Важливо, щоб при повідомленні про таку ситуацію ви уникли нечітких тверджень на зразок « Потоки повільні ». Замість цього, будьте точні щодо того, що є повільним — список очікуваних записів, певний член групи користувачів або, можливо, швидкість, з якою надходять підтвердження. Сфокусування на спостережуваних метриках допомагає швидше визначити кореневу причину і дозволяє здійснювати цілеспрямовані втручання. Також важливо чітко сформулювати, які дії були вжиті для вирішення проблеми, демонструючи активне вирішення проблем.

redis-cli -o 'consumergroup [GROUP_NAME] status'

Після виконання цієї команди буде надано знімок стану і стану групи користувачів, що надає вам змогу швидко оцінити, чи отримуються підтвердження негайно, або ж користувачі застрягли у певному стані. Зрозуміти, як ці елементи взаємодіють — частота підтверджень, очікування записів і доступність споживача — є ключем до активного керування вашими розгортаннями потоків Redis. Визнаючи, що затримки не обов’язково є невдачі, але можливості для поліпшення є основним елементом професійного технічного спілкування.