Системата изпраща заявка за нова задача. Получателят я запазва, но отговорът се прекъсва. Повторението може да създаде втора задача. Първият въпрос е дали действието вече е извършено.
Дайте постоянна идентичност на действието
Пазете заедно ID на оригинала и ID на крайния запис. За предложен процес от запитване към задача ключът може да съчетава система, ID и тип действие. Нова версия се добавя само според правилото за обновяване. Имейл адресът често е неподходящ ключ: един човек може да изпрати няколко отделни запитвания.
Някои API поддържат ключове за идемпотентност или уникални ограничения. Други изискват търсене и постоянен дневник. Проверете действителните гаранции. Търсене преди запис не изключва състезание между две едновременни изпълнения.
Три решения за възстановяване
| Състояние | Следваща стъпка |
|---|---|
| Потвърден успех | Запазване на ID; без ново създаване |
| Потвърден отказ преди запис | Повторение според уговорената политика |
| Неизвестен резултат | Търсене по постоянния ключ; човешка проверка при неяснота |
„Няма отговор“ остава в третия ред, докато се установи резултатът. Прекъсването описва връзката, не доказва бизнес състоянието. При клиентски действия без надеждно търсене запазете изчакваща проверка.
Авторска примерна схема: Set It Once. Прекъсване може да настъпи след успешно записване в крайната система.
Прочетете текстовата версия
- Получете постоянен номер. Същият номер при всеки повторен опит.
- Проверете крайната система. Съществува ли съответният запис?
- Изберете един път. Използвайте записа или го създайте веднъж.
- Потвърдете и запишете. Пазете крайния номер и резултата.
Определете как се обработва променен оригинал
Повторно събитие и редактиран запис са различни. Поправен телефон може да обновява първата задача, а ново запитване да създава втора. Разпишете тази разлика преди избор на инструмент за премахване на дубликати.
Asana описва обработката на webhook събития. Процесът около тях пак изисква правила за повторения, промени и история. Доставено събитие не гарантира еднократно изпълнение на всички последващи действия.
Проверете прекъсване и едновременно изпълнение
- Подайте едно събитие два пъти.
- Подайте отделно валидно запитване от същия имейл.
- Редактирайте първия оригинал.
- В контролирана среда пуснете два обработчика за един ключ.
- Симулирайте липсващо потвърждение и проверете получателя преди повторение.
Запишете броя крайни записи и причината за всеки. Отстранявайте потвърдените дубликати според уговорено правило, без автоматично изтриване на неясни записи.
Липсата на постоянни ID или търсене е ограничение на проекта. Тя може да наложи адаптер, опашка за преглед или по-прост ръчен процес.
Защо „провери, после създай“ пак допуска дубликати
Двама изпълнители получават едновременно условно събитие E-27. И двамата търсят задача, не намират и създават по една. Отделната проверка не защитава от едновременност. Кратко изчакване между проверка и запис също не доказва правилност.
Нужен е поддържан механизъм за атомарно заявяване на действието, правило за уникалност в получателя или API идемпотентност с ясен обхват. Възможното решение зависи от системите. Отметка в таблица, проверявана от два независими процеса, не е автоматично заключване. Поискайте демонстрация с едновременни доставки.
Разделете идентичността на събитието и действието
Един запис може да генерира събития за създаване, редакция и прехвърляне. Премахването само на повторната доставка не пречи всяка редакция да създава нова задача. Обратното правило, всички събития за един клиент да са еднакви, може да потисне действително ново запитване.
Условният ключ за действие може да комбинира запитване E-27 и операция „създай последваща задача“. По-късните корекции обновяват тази задача според отделно правило. Пазете ID на получателя и състояние: чакащо, потвърдено, отказало преди запис или неизвестно. Историята на решенията е по-полезна от една отметка „обработено“.
Идемпотентността на API има конкретни условия
Някои API приемат ключ за идемпотентност. Stripe документира такъв механизъм, но срокът и поведението са специфични за неговото API и версия. Не приемайте, че едноименен хедър работи навсякъде, пази се завинаги или позволява смяна на първоначалните параметри.
Проверете договора на получателя, не включвайте лични данни в ключа и сравнете срока му с периода за възстановяване. Ако механизмът липсва, изберете поддържана алтернатива и опишете ограниченията. След неясен запис въпросът остава дали ефектът вече съществува.
Тествайте повторна доставка, две едновременни доставки, редактиран оригинал, изгубено потвърждение и повторение след срока на ключа. Само първият тест не е достатъчен.
Технически източник: конкретните правила за идемпотентност на Stripe.
Следваща практична стъпка
Ако това е проблем във вашия екип, разгледайте разработката по поръчка. Опишете една конкретна задача, използваните програми и очаквания резултат. Обхватът и условията се уточняват предварително.
Източници и допълнително четене
Бързи отговори
Често задавани въпроси
Мога ли да махам дубликати по имейл?
Само ако това съответства на правилото ви. Иначе може да слеете отделни запитвания на един клиент.
Повторението гарантира ли доставка?
Не. Може и да повтори действие. Проверете правилата на системата за повторения и идемпотентност.
Ако не знам дали първият запис е извършен?
Оставете резултата неустановен и го изпратете за проверка. Не го отчитайте като успех или отказ без доказателство.
За автора
Мартин Илиев
Мартин създава Set It Once, за да помага на хората да отделят по-малко време на повтарящата се работа. Ръководствата му обясняват какво можете да пробвате, как да проверите резултата и къде са ограниченията.
Повече за Мартин
