1. Что такое идемпотентность?
Посмотрите, что говорит Википедия:
Идемпотентность:Многократный вызов метода или интерфейса не изменит бизнес-состояние, что гарантирует соответствие результата повторных вызовов результату одного вызова.
Во-вторых, использование идемпотентных сценариев
1. Передняя повторная отправка
Для таких операций, как регистрация пользователя, создание пользователем продуктов и т. д., клиентская часть будет отправлять некоторые данные в серверную службу, а серверная часть должна создавать записи в базе данных в соответствии с данными, предоставленными пользователем. Если пользователь случайно щелкнет несколько раз, и серверная часть получит несколько представлений, в базе данных будет неоднократно создаваться несколько записей. Это ошибка, что интерфейс не имеет идемпотентности.
2. Время ожидания интерфейса истекло, и повторите попытку.
Для интерфейса, вызываемого третьему лицу, вызов может завершиться ошибкой по сетевым причинам, в этом случае механизм повторной попытки неудачи обычно добавляется к вызову интерфейса при проектировании. Сетевое исключение возникает, если первый вызов находится на полпути. В это время при повторном вызове произойдет исключение вызова из-за наличия грязных данных.
3. Повторное потребление сообщений
При использовании ПО промежуточного слоя для обработки очередей сообщений и подтверждения вручную, чтобы убедиться, что сообщения используются нормально. Если потребитель внезапно отключается, сообщение, которое было выполнено наполовину, возвращается в очередь.
Когда сообщение повторно используется другими потребителями, если нет идемпотентности, это приведет к ненормальным результатам при повторном использовании сообщения, например к дублированию данных базы данных, конфликту данных базы данных, дублированию ресурсов и т. д.
3. Решения
1. Реализация механизма токенов
Идемпотентность интерфейса достигается за счет механизма маркеров, который является более общим методом реализации.
Схематическая диаграмма выглядит следующим образом:
Конкретные этапы процесса:
-
Клиент сначала отправит запрос на получение токена, сервер сгенерирует глобально уникальный идентификатор в качестве токена и сохранит его в Redis, а затем вернет идентификатор клиенту.
-
Клиент должен иметь этот токен при вызове запроса на обслуживание во второй раз.
-
Сервер проверит токен, если проверка прошла успешно, выполнит бизнес и удалит токен в Redis.
-
Если проверка не удалась, значит, в redis нет соответствующего токена, значит, операция повторяется, а указанный результат возвращается напрямую клиенту
Уведомление:
-
Рекомендуется использовать Lua-скрипты для реализации логики наличия токена в redis и удалять код для обеспечения атомарности
-
Глобально уникальный идентификатор может быть сгенерирован генератором uid от Baidu и Leaf от Meituan.
2. Реализация на базе mysql
Эта реализация использует функцию уникального индекса mysql.
Схематическая диаграмма выглядит следующим образом:
Конкретные этапы процесса:
-
Создайте таблицу дедупликации, в которой поле должно быть уникально проиндексировано.
-
Клиент запрашивает сервер, и сервер вставит некоторую информацию этого запроса в эту таблицу дедупликации.
-
Поскольку поле в таблице имеет уникальный индекс, в случае успешной вставки это доказывает, что в таблице нет информации для этого запроса, и выполняется последующая бизнес-логика.
-
Если вставка не удалась, это означает, что текущий запрос был выполнен и возвращается напрямую.
3. Реализация на основе Redis
Эта реализация основана на команде SETNX.
Значение ключа SETNX: установите значение ключа в значение тогда и только тогда, когда ключ не существует. Если данный ключ уже существует, SETNX ничего не делает.
Команда возвращает 1, если настройка прошла успешно, и 0, если настройка не удалась.
Конкретные этапы процесса:
-
Клиент сначала запрашивает сервер и получает уникальное поле, которое может представлять запрошенный бизнес.
-
Сохраните это поле в redis в виде SETNX и установите соответствующий тайм-аут в соответствии с бизнес-процессами.
-
Если настройка прошла успешно, это доказывает, что это первый запрос, и выполняется последующая бизнес-логика.
-
Если настройка не удалась, это означает, что текущий запрос был выполнен и возвращается напрямую
4. Резюме
Эти несколько способов реализации идемпотентности на самом деле похожи, и существуют похожие способы использования конечных автоматов, пессимистической блокировки и оптимистической блокировки, которые относительно просты.
Короче говоря, когда вы проектируете интерфейс, идемпотентность является первым соображением, особенно когда вы отвечаете за разработку интерфейсов, связанных с деньгами, такими как переводы и платежи, вам следует уделять особое внимание!