Англійська для NATS JetStream

JetStream додає міцну, повторювану постійність на вершині легкого pub-sub ядра NATS, а зміна словника — від простих «суб’єктів» до «потоків» і «споживачів» — збиває людей в обговореннях дизайну, якщо терміни не використовуються точно. Цей підручник містить основні терміни.

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

** Потік ** — тривалий, упорядкований журнал повідомлень, отриманих з одного або декількох об’ єктів, еквівалент JetStream набору розділів тем Kafka, налаштований з власною політикою зберігання і зберігання. “Ми створили поток під назвою ЗАКЛАДИ, який захоплює все опубліковане на orders.>, з семиденною політикою зберігання.”

** Потребувач ** — перегляд потоку, який відстежує поступ доставки для одного або декількох підписників, заснований на витягуванні (запит клієнта на повідомлення) або на відсиланні (доставка повідомлень сервером). “Ми використовуємо pull-consumer для пакетного процесора, щоб він контролював свій власний темп, а не push-consumer, який міг би перевантажити його під час затримки.”

** Правило підтвердження (ack) ** — параметр, який керує тим, чи і як споживач повинен підтвердити обробку повідомлення (none, all або explicit ) перед тим, як JetStream розгляне повідомлення як доставлене.

• “З явним ack, повідомлення зруйнованого робітника, які не були підтверджені, автоматично передаватимуться замість тихого зникнення.” *

** Правила зберігання ** — налаштування рівня потоку, що визначає, як довго зберігатимуться повідомлення: limits (засноване на часі/ розмірі/ кількості), interest (зберігатимуться, поки існуватимуть користувачі), або workqueue (вилучатимуться після підтвердження будь- яким користувачем).

• “Ми переключили поток сповіщень на зберігання у робочій черзі, оскільки кожне повідомлення потрібно обробляти лише один раз, і нам не потрібно, щоб воно затримувалося після цього.” *

** Redelivery ** — автоматичне перенаправлення повідомлення споживачеві, який не зміг підтвердити його в налаштованому вікні AckWait, основний механізм надійності, відмінний від майже одноразової доставки.

• “Дубліковані листи з замовленнями були спричинені повільним обробником, який перевищив AckWait і викликав повторне надсилання — ми розширили вікно замість того, щоб обробник перемагав у часі до ack.” *

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

• «Чи це pull-consumer або push-consumer, і чи відповідає це тому, як клієнт побудований для його споживання?»
• «Що таке політика зберігання даних на цьому потоці — обмеження, відсотки, або черга роботи?»
• Чи використовує цей споживач явний ack, або може аварія безшумно скидати повідомлення?»
• «Що таке AckWait, і чи достатньо це довго для типового часу обробки цього обробника?»
• Чи ми бачимо перевидання через справжню помилку, чи тому, що вікно ack занадто вузьке?»

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

Пропозиція проекту потоку у перегляді архітектури: “Я б налаштував поток платежу з обмеженням зберігання на тридцять днів і явним ack на споживача, щоб у нас було вікно повторення, якщо служба нижче потребує повторної обробки.”

Зневадження інциденту обробки дублікатів: “Передоставка була викликана тому, що AckWait споживача становив п’ять секунд, але обробник займав вісім під навантаженням - ми розширили вікно і зробили обробник ідемпотентним як безпечну сітку.”

Пояснення вибору споживача колегі: “Ми використовуємо pull consumer тут, особливо тому, що worker повинен контролювати свій власний розмір пакету — push consumer просто випустить повідомлення з будь-якою швидкістю потоку, який їх виробляє.”

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

• Скажіть ** поток ** і ** споживач ** точно, а не “тема” і “підписник” - ці терміни з смаком Кафки не відображаються чисто і викликають плутанину в обговоренні, специфічному для NATS.
• Визначте ** політику збереження ** явно, коли пропонуєте новий потік — це рішення щодо дизайну з реальними наслідками для зберігання і коректності, а не типове рішення, яке не слід вказувати.
• Завжди згадуйте ack policy при описі гарантій надійності споживача — « він обробляє повідомлення » не говорить нічого про те, що відбувається при аварії в середині обробки.
• Під час повідомлення про ваду, пов’ язану з дублюванням повідомлень, перевірте і повідомте про значення AckWait разом з redelivery — тісне вікно, замасковане як « нерівна обробка », є дуже поширеною причиною.

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

1. Напишіть речення, у якому буде описано правила зберігання потоку для певного випадку використання.
2. Пояснити різницю між споживачем pull і споживачем push.
3. Опишіть сценарій повторної доставки і як ви запобігаєте виникненню подвійних побічних ефектів.

На практиці: Навігація Nuance в розподіленій команді

Розуміння технічного жаргону - це одне; ефективне спілкування в професійному середовищі - особливо при співпраці з колегами з різних сфер - це зовсім інше. При роботі з такими системами, як NATS JetStream, словник не просто визначає * що * щось робить; це про передачу його впливу, потенційних проблем і бажаних результатів таким чином, що резонує на різних рівнях технічного розуміння. Розглянемо деякі типові сценарії, в яких оволодіння нюансованим англійським фразуванням може зробити або пошкодити ваші взаємодії.

Наприклад, уявіть, що ви переглядаєте запит на витяг для нової програми для споживачів. Розробник може подати опис PR просто заявивши: «Додано споживача для обробки повідомлень з потоку X». Хоча це технічно вірно, йому бракує важливого контексту. Ефективнішим підходом було б щось на зразок: «Цей споживач тепер обробляє всі повідомлення, опубліковані на stream_name, пов’язані з виконання замовлення. Ми реалізували політику повторних спроб для перехідних помилок — зокрема, якщо повідомлення не буде підтверджено після трьох спроб, воно буде перенесено до черги і оброблено іншим екземпляром користувача. Будь ласка, переконайтеся, що це відповідає нашим поточним правилам збереження, що стосуються втрати даних. » Зауважте, що додавання відомостей про те, * чому * було внесено зміну, стратегію обробки помилок і посилання на існуючі правила підвищує опис з простого сповіщення до чіткого пояснення для перегляду. Аналогічно, в дискусіях Slack, уникнення надто коротких повідомлень, таких як «Споживач потребує ack», є життєво важливим. Замість цього спробуйте щось на зразок: «Споживач не надійно підтверджує повідомлення на stream_name. Давайте розглянемо потенційні проблеми з обробкою повідомлень або підтвердженням параметрів. ”

Інша часта проблема виникає при обговоренні політики зберігання - критичний елемент стійкості JetStream. Пояснення концепції просто для когось, хто не знайомий з постійністю даних, може бути складним. Фрази на кшталт «повідомлення зберігаються до тих пір, поки вони не будуть явно підтверджені» або «ми повинні налаштувати зберігання для цього потоку» є набагато більш доступними, ніж чисто технічні описи. Також важливо розглянути потенційні наслідки різних політик. Сказати: « Давайте встановимо 24- годинну політику зберігання для цього потоку », ясно, але додавання: « Це забезпечить збереження всіх даних замовлення для цілей аналізу, навіть якщо деякі повідомлення тимчасово недоступні через проблеми з мережею » надає цінний контекст і обґрунтовує рішення.

nats-jetstream consumer create --name my_consumer --stream my_stream --options { "retries": 3, "ack_timeout": "10s"}

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