私たちを正しくする方法Postgresトリガーからのタスクキュー

Question

私の現在のアーキテクチャには、単一のストレージポイントを持つ複数のWebアプリケーションがあります - 私のpostgresデータベース。さて、私は、新しいユーザの作成時に電子メールを送信したり、特定の値が変更された場合に管理者に通知するなど、特定のことがデータベース内で発生したときには、いくつかのタスクを実装したかった。

したがって、すべてのアクションに固有のトリガーの数さて、私はそれが良いアイデアだとは思っていませんでした。

また、ノードのサーバーにLISTEN/NOTIFYを実行するトリガーが1つあるとは考えにくいです。規模が大きければ、このソリューションは扱いが面倒になるからです。

潜在的な解決策は、celeryやrabbitMQなどのタスクキューを用意し、データベースのトリガーから何らかの方法でタスクを開始することです。スケーラビリティと将来の管理が比較的容易になるかもしれません。

私の質問は、postgresqlトリガとセラムなどのタスクキューを統合する適切な方法は何ですか？私はそれについて考えている方法が適切かどうか分かりません。

ありがとうございました。

Answer 1

最適な解決策は、処理が必要なデータベース内にデータが存在する可能性があることを示すプロセス間またはHTTP通知のいずれかを受信できる別個のプロセスを持つことです。

これは、プロセスの開始時にスケジュールされたすべてのものを処理し、何らかのデータがある場合に着信通知を待ち受けます。

さらに、1分ごとに1回のように時折ポーリングを追加することもできます。

トリガから遠ざかる必要があります。トリガが壊れた場合に監視する必要があります。そのため、ソリューションがかなり複雑になります。