PostgreSQL-Sperren bei hoher gleichzeitiger API-Schlüssel-Nutzung

Hallo Community,

wir verwenden die Discourse-API in einer selbst gehosteten Installation. Unser Anwendungsfall ist aufgrund der hohen Nebenläufigkeit recht intensiv, mit durchschnittlich etwa 100 API-Anfragen pro Sekunde. Wir verwenden außerdem PostgreSQL+Patroni+HAProxy, um ein Hochverfügbarkeits-Datenbank-Setup bereitzustellen. Gelegentlich sperrt unser PostgreSQL und Patroni startet den Master-Knoten neu.

Wir haben einen Cronjob implementiert, um blockierte Transaktionen zu überprüfen, und jedes Mal, wenn dieses Problem auftritt, finden wir die gleichen Arten von Operationen:

 blocked_pid | blocked_user | blocking_pid | blocking_user |                                       blocked_statement                                        |                             current_statement_in_blocking_process                              
-------------+--------------+--------------+---------------+------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------
      297904 | discourse    |       293083 | discourse     | UPDATE "api_keys" SET "last_used_at" = '2024-07-16 16:38:16.822352' WHERE "api_keys"."id" = 21 | UPDATE "api_keys" SET "last_used_at" = '2024-07-16 16:34:48.163449' WHERE "api_keys"."id" = 21
      296718 | discourse    |       293083 | discourse     | UPDATE "api_keys" SET "last_used_at" = '2024-07-16 16:34:50.900480' WHERE "api_keys"."id" = 21 | UPDATE "api_keys" SET "last_used_at" = '2024-07-16 16:34:48.163449' WHERE "api_keys"."id" = 21
      293101 | discourse    |       293083 | discourse     | UPDATE "api_keys" SET "last_used_at" = '2024-07-16 16:34:49.485074' WHERE "api_keys"."id" = 21 | UPDATE "api_keys" SET "last_used_at" = '2024-07-16 16:34:48.163449' WHERE "api_keys"."id" = 21

Wie Sie sehen können, versuchen viele Anfragen, die letzte Nutzungzeit desselben API-Schlüssels zu aktualisieren.

Vorerst haben wir die Anzahl der von unserer Anwendung verwendeten API-Schlüssel erhöht, um die Wahrscheinlichkeit einer Kollision zu verringern. Ich habe festgestellt, dass es Code gibt, der prüft, ob der API-Schlüssel in der letzten Minute geändert wurde, um eine Aktualisierung zu vermeiden. Ich gehe jedoch davon aus, dass diese Schutzmaßnahme nicht wirksam ist, da wir mehr als einen Pod zur Verarbeitung der Anfragen verwenden.

Ich bin mir nicht sicher, ob wir dies als Fehler melden sollten oder ob es Parameter gibt, um diese Art von Kollision zu vermeiden (entweder in Discourse oder PostgreSQL). Beachten Sie, dass die Informationen zur letzten Nutzung für uns relevant sind, aber eine Auflösung von 1 Tag wäre ausreichend.

Ich würde auch gerne wissen, welcher Ansatz zur Verwaltung von PostgreSQL HA mit automatischer Wiederherstellung bevorzugt wird.

Danke

Ist jemandem ein ähnliches Problem begegnet oder kann jemand Anleitungen geben, was zu untersuchen ist? Könnte es sein, dass Discourse nicht für diese Menge an Anfragen pro Sekunde ausgelegt ist?

Vielen Dank im Voraus.