0

私のバックエンド システムは約 10,000 の POS デバイスにサービスを提供し、各デバイスはシーケンシャル スタイルでサービスを要求しますが、特定のクライアントの要求をシーケンシャル スタイルで処理することをバックエンドがどのように保証するのか疑問に思っています。

たとえば、デバイスは「販売」リクエストを発行し、応答を取得するためにタイムアウト (DB がブロックされる可能性があります) があるため、その販売リクエストをキャンセルするために「キャンセル」を発行します。この場合、「キャンセル」リクエストを受け取ったときにバックエンドがまだ「販売」トランザクションを処理している可能性があり、予期しない結果が生じる可能性があります。

私の考えは、各デバイス (クライアント) に対して永続的なキューをセットアップすることですが、10K のキューをセットアップしても問題ありませんか? よくわかりません、助けてください。

4

1 に答える 1

1

これはコンピュータ サイエンスの非常に複雑な領域であり、これらの問題の多くは何度も解決されています。私は車輪を再発明しようとはしません。

私のアドバイス:

  • ACIDについて読み、完全に理解する(要約は言い換え):
    • 原子性- トランザクションの一部が失敗した場合、トランザクション全体が失敗し、データベースが不明または破損した状態のままになることはありません。これは非常に重要です。実際のデータベースでこれを実現するには、既存のソフトウェアに依存します。また、独自のトランザクション システムを再発明する必要があるようなデータ構造を発明しないでください。トランザクションをできるだけ小さくして、失敗を減らします。
    • 一貫性- データベースが無効な状態のままになることはありません。それにコミットされたすべての操作は、それを新しい有効な状態にします。
    • 分離- データベースで実行する操作は同時に実行でき、次々に実行された場合と同じ状態になります。 ORは、ロック トランザクション内で安全に実行されます。
    • 耐久性- トランザクションがコミットされると、コミットされたままになります。

既存のシステムと提案されたアイデアの両方がACIDに違反している可能性があるように聞こえます。

  • ステートフルな要求システムは、おそらく分離に違反しています (または違反しないようにするのが難しくなります)。
  • 万全の方法で行わないと、キューは耐久性に違反する可能性があります。

言うまでもなく、スケーラビリティの問題もあります。スケーラビリティとACIDを組み合わせると、深刻な専門知識を必要とする重量級の状況になります。

あなたがそれを助けることができるなら、特にこれが販売時点管理のためのものである場合、既存のシステムに頼ることを強くお勧めします.

于 2013-09-30T07:28:59.830 に答える