これが来るのを見たと思います、「それは依存します」。
それはすべてに依存します。また、部門Aの顧客データを共有するソリューションは、部門Bと顧客データを共有する場合とはまったく異なる場合があります。
何年にもわたって浮かび上がってきた私のお気に入りのコンセプトは、「結果整合性」のコンセプトです。この用語は、Amazonが分散システムについて話していることに由来しています。
分散型企業全体のデータの状態は現在完全に一貫しているわけではないかもしれませんが、「最終的には」一貫していることが前提です。
たとえば、システムAで顧客レコードが更新されると、システムBの顧客データは古くなり、一致しなくなります。しかし、「最終的に」、Aからのレコードは何らかのプロセスを介してBに送信されます。したがって、最終的には、2つのインスタンスが一致します。
単一のシステムで作業する場合、「EC」はなく、即時更新、単一の「信頼できる情報源」、および通常、競合状態と競合を処理するためのロックメカニズムがあります。
オペレーションが「EC」データを処理できるほど、これらのシステムを簡単に分離できます。簡単な例は、販売で使用されるデータウェアハウスです。彼らはDWを使用して日次レポートを実行しますが、レポートは早朝まで実行せず、常に「昨日」（またはそれ以前）のデータを確認します。したがって、DWが日常の運用システムと完全に一致している必要はありません。プロセスが、たとえば営業終了時に実行され、トランザクションとアクティビティが大規模な単一の更新操作でまとめて何日にもわたって移動することは完全に許容されます。
この要件が多くの問題をどのように解決できるかがわかります。トランザクションデータの競合はありません。レポートがライブデータベースに対して2つの個別のクエリを実行したため、統計の蓄積中に一部のレポートデータが変更される心配はありません。日中にネットワークやCPU処理などを吸い上げるために、詳細なチャタリングを行う必要はありません。
さて、これはECの極端で単純化された、非常に粗い例です。
しかし、Googleのような大規模なシステムを考えてみてください。検索の利用者として、Googleが検索結果を収集して検索ページに表示されるまでに、いつ、どのくらいの時間がかかるかはわかりません。 1ms？ 1秒？ 10代？ 10時間？ Googleの西海岸のサーバーにアクセスした場合、東海岸のサーバーにアクセスした場合とは異なる検索結果が得られる可能性があることを想像するのは簡単です。これらの2つのインスタンスが完全に一貫しているわけではありません。しかし、大体において、それらはほとんど一貫しています。そして、彼らのユースケースでは、彼らの消費者は実際には遅れや遅れの影響を受けません。
メールを検討してください。 AはBにメッセージを送信したいと考えていますが、その過程でメッセージはシステムC、D、およびEを経由してルーティングされます。各システムはメッセージを受け入れ、完全な責任を負い、別のシステムに渡します。送信者は、電子メールが送信されるのを確認します。彼らは必ずしもそれが来ることを知らないので、受信者は本当にそれを見逃しません。そのため、メッセージがどれだけ速いかを関係者が知らない、または気にせずに、そのメッセージがシステム内を移動するのにかかる時間は大きくなります。
一方、AはBと電話をしていた可能性があります。「送信したばかりですが、もう取得しましたか？今ですか？今ですか？今すぐ取得しますか？」
したがって、ある種の根本的な暗黙のレベルのパフォーマンスと応答があります。結局、「最終的に」、Aの送信トレイはBの受信トレイと一致します。
これらの遅延、古いデータの受け入れは、1日経過しているか、1〜5秒経過しているかにかかわらず、システムの最終的な結合を制御します。この要件が緩いほど、カップリングが緩くなり、設計の観点から自由に使用できる柔軟性が高まります。
これは、CPUのコアにまで当てはまります。同じシステムで実行されている最新のマルチコアマルチスレッドアプリケーションは、「同じ」データの異なるビューを持つことができ、マイクロ秒だけ古くなっています。コードが互いに矛盾する可能性のあるデータを正しく処理できる場合は、幸いなことに、コードは圧縮されます。そうでない場合は、揮発性メモリの修飾やロック構造などの手法を使用して、データの完全な一貫性を確保するために特別な注意を払う必要があります。これらはすべて、パフォーマンスの低下につながります。
したがって、これが基本的な考慮事項です。他のすべての決定はここから始まります。これに答えることで、マシン間でアプリケーションを分割する方法、共有されるリソース、およびそれらがどのように共有されるかがわかります。データを移動するために利用できるプロトコルと手法、および転送を実行するための処理にかかる費用。レプリケーション、負荷分散、データ共有など。すべてこの概念に基づいています。
最初のコメントに応じて編集します。
正解です。たとえば、ここでのゲームでは、Bが顧客データを変更できない場合、変更された顧客データの害は何ですか？少しの間古くなっていることを「リスク」にできますか？おそらく、顧客データは、AからBにすぐに複製できるほどゆっくりと届きます。変更がキューに入れられ、ボリュームが少ないためにすぐに取得される（<1s）が、それでも元の変更では「トランザクション外」であるため、Aが持つ小さなウィンドウがあるとします。 Bにはないデータ。
今、心は本当に回転し始めます。その1秒間の「ラグ」の間に何が起こるか、考えられる最悪のシナリオは何ですか。そして、あなたはそれを回避するように設計できますか？ 1秒の遅れを中心に設計できる場合は、5秒、1 m、またはそれ以上の遅れを中心に設計できる可能性があります。 Bで実際に使用している顧客データはどれくらいですか？多分Bは在庫からの注文ピッキングを容易にするように設計されたシステムです。単に顧客IDとおそらく名前以外に必要なものを想像するのは難しいです。それが組み立てられている間、注文が誰のためであるかを大まかに識別するためのちょうど何か。
ピッキングシステムは、ピッキングプロセスの最後まで、必ずしもすべての顧客情報を印刷する必要はありません。その時点で、注文は、特に出荷情報が最新の別のシステムに移動している可能性があります。結局、ピッキングシステムは顧客データをほとんど必要としません。実際、ピッキングオーダー内の顧客情報を埋め込み、非正規化することができるため、後で同期する必要や期待はありません。顧客IDが正しい（とにかく変更されることはありません）と名前（変更されることはめったにないので、説明する価値がない）である限り、それが必要な唯一の実際の参照であり、すべてのピックスリップはその時点で完全に正確です。作成。
秘訣は、システムを分割し、タスクに必要な重要なデータに焦点を当てるという考え方です。不要なデータを複製または同期する必要はありません。人々は、特にリレーショナルデータモデリングの世界から来た場合、非正規化やデータ削減などに悩まされます。そして、正当な理由があるので、慎重に検討する必要があります。しかし、配布されると、暗黙的に非正規化されます。一体、あなたは今それを卸売りでコピーしています。だから、あなたはそれについてもっと賢くするほうがよいでしょう。
これはすべて、確実な手順とワークフローの完全な理解によって軽減できます。リスクを特定し、それらを処理するためのポリシーと手順を作成します。
しかし、難しいのは、最初に中央DBへのチェーンを切断し、単一の中央の完璧な情報ストアがある場合に期待されるように「すべてを手に入れる」ことはできないことを人々に指示することです。