タグ付けされた質問 「synchronization」

2
双方向データ同期のベストプラクティス/パターン
私の仕事では、多くの場合、データベースシステム間の双方向データ同期のアイデアが現れます。典型的な例は、2つのわずかに異なるCRMシステム（たとえば、Raiser's EdgeとSalesforce）と、それらの間で連絡先データの双方向同期が必要な場合です。 APIの考慮事項は別として、同期する共有キーがあり、使用するアルゴリズム/パターンを純粋に考えている場合、これは技術者以外によって過小評価されることが多いタスクです。 たとえば、次のことに注意する必要があります。 両方のシステムでどのレコードが変更されたかを簡単に検出できますか（または、システム間ですべてのレコードを比較して変更を検出する必要がありますか） N時間に1回の同期を行う場合、両方のシステムで同じレコードが多かれ少なかれ同じ時間に変化する競合に対処する方法 リアルタイム同期（つまり、1つのシステムの更新がすぐに他のシステムの更新をトリガーする）を予定している場合、バグまたはシステムクラッシュによる時間の経過に伴う逸脱の処理方法 個人的に私はこれすべてに取り組む方法を考えることができますが、私が参照できるよく知られたパターン、文献またはベストプラクティスがあるかどうか疑問に思っています。
5
不変性は、マルチプロセッサプログラミングでのロックの必要性を完全に排除しますか？
パート1 明らかに不変性は、マルチプロセッサプログラミングでのロックの必要性を最小限に抑えますが、その必要性を排除しますか、または不変性だけでは不十分な場合がありますか？ほとんどのプログラムが実際に何かを行う（データストアを更新する、レポートを作成する、例外をスローするなど）前に処理を延期し、状態をカプセル化できるのは私だけのようです。そのようなアクションは常にロックなしで実行できますか？元のオブジェクトを変更するのではなく、各オブジェクトを破棄して新しいオブジェクトを作成するという単純なアクション（不変性の大まかな見方）は、プロセス間競合からの絶対的な保護を提供しますか、それともロックが必要なコーナーケースがありますか？ 私は多くの機能的なプログラマーと数学者が「副作用なし」について話すのを好むことを知っていますが、「現実の世界」では、機械命令を実行する時間であっても、すべてに副作用があります。理論的/学術的答えと実用的/現実世界の答えの両方に興味があります。 特定の境界または仮定が与えられれば、不変性が安全であれば、「安全ゾーン」の境界が正確に何であるかを知りたいです。可能な境界のいくつかの例： I / O 例外/エラー 他の言語で書かれたプログラムとの相互作用 他のマシンとの相互作用（物理、仮想、または理論） この質問を始めたコメントに対して@JimmaHoffaに感謝します！ パート2 多くの場合、マルチプロセッサプログラミングは最適化手法として使用され、コードの実行を高速化します。ロックと不変オブジェクトを使用する方が速いのはいつですか？ アムダールの法則で定められた制限を考えると、不変オブジェクトと可変オブジェクトのロックで全体的なパフォーマンスを向上させることができます（ガベージコレクターの有無にかかわらず）。 概要 これら2つの質問を1つにまとめて、スレッド化の問題の解決策として不変性の境界ボックスがどこにあるのかを探ろうとしています。
5
中央データベースなし
非常に機密性の高いデータ（銀行/カードの詳細よりも機密性の高いデータ）を扱うWebサイト/モバイルアプリ/デスクトップアプリを構築しようとしているクライアントがいます。データは機密性が高いため、中央のデータベースに保存したくありませんが、アプリの同期が必要です（モバイルアプリにデータを追加して、デスクトップアプリと同じデータを参照してください）。 これを行うための良い、信頼できる方法を考えることはできませんし、1つあるかどうかはわかりません。それが私がここにいる理由です。誰も私がこのデータをどのように扱うことができるか知っていますか？ 私が考えていた解決策の1つは、アプリ間で何らかの形で同期するクライアント側のデータベースを各アプリに持たせることでした。
1
Redis vs Zookeeper
これら2つのサーバーが非常に異なるものを対象としていることを考慮して、これら2つのサーバーを比較するのはばかげているようです。しかし、考えてみると、構成データの保存、分散ロック、キューイングなど、多くの類似したことができます。 私はいくつかの生産関連のことのために使用しているRedisのインスタンスを持っていますが、サーバー間でいくつかの簡単な同期を行いたいと思います（主にコードを押し上げたりサーバー間で簡単なロックを必要としない構成変更）。Zookeeperは、Redisが提供しないことを何を提供してくれますか？
3
双方向同期の競合解決
接続が常に利用可能ではないことを前提として、「メイン」データベースサーバーと多くの「セカンダリ」サーバー間の双方向同期、特に競合解決をどのように管理しますか？ たとえば、iOSでCoreDataを「データベース」として使用するモバイルアプリがあり、ユーザーがインターネットに接続せずにコンテンツを編集できるようにしたいと考えています。同時に、この情報はデバイスが接続するWebサイトで入手できます。2つのDBサーバーのデータが競合している場合/その場合はどうすればよいですか？ （CoreDataをDBサーバーと呼びますが、多少異なることがわかります。） この種の問題に対処するための一般的な戦略はありますか？これらは私が考えることができるオプションです： 1.常にクライアント側のデータを優先度の高いものとして使用します 2.サーバー側でも同じ 3.各フィールドの編集タイムスタンプをマークして最新の編集を行うことで競合を解決してください 3番目のオプションは壊滅的なデータ破損の余地を開くと確信していますが。 CAP定理がこれに関係していることは承知していますが、最終的な整合性のみが必要なので、完全に除外するわけではありませんか？ 関連質問：双方向データ同期のベストプラクティスパターン。この質問に対する2番目の答えは、おそらくそれができないということです。
4
2つの異なるデータベース間でデータを同期する最良の方法
構造がまったく異なる2つの大きなデータベース間でデータ同期を実装する必要があります。基本的に、最初のデータベースのさまざまなテーブルにある製品に関するデータを収集し、2番目のデータベースの他のテーブルに再配置する必要があります。 初めて製品を作成することはそれほど複雑ではありません。しかし、私はすべてのデータではなく、各製品に関する特定のデータを更新する方法を探しています。 明らかに、これを難しくするいくつかの問題があります。 選択クエリを除いて、ソースデータベースで何もすることはできません。 ターゲットデータベースでは、通常のクエリ（選択、更新、挿入、作成）を実行できますが、既存の構造/テーブルを変更することはできません。 ターゲットとソースDBは完全に異なる構造を持ち、テーブルはまったく同じではないため、データを実際に再配置する必要があります-テーブルの比較は機能しません。 ターゲットデータベースはMySQLサーバーを使用します。ソースはDB2である場合があります。 どこにも「更新時間」フィールドはありません。 そのため、プロセス全体を1つのPython（理想的には）スクリプトで実行する必要があります。 ターゲットデータベースで更新するフィールドに基づいて、各製品のハッシュを作成することを検討します：md5（code + description + supplier +約10の他のフィールド）。同じデータに基づく新しいハッシュが、ソースデータベースから毎日作成されます。パフォーマンスのために、すべてのハッシュを単一のテーブル（項目コード、current_hash、old_hash）に保存します。次に、新しいハッシュが古いハッシュと異なる場合、製品を比較して更新します。 約50万の製品があるので、パフォーマンスが少し心配です。 それは良い方法ですか？
9
マルチスレッド同期のインタビューの質問：m個のスレッドからn個の単語を見つける
この問題は、単一のスレッドではなく、複数のスレッドを使用したソリューションの恩恵を受けることができますか？ インタビューで、複数のスレッドを使用して問題を解決するように依頼されました。私には、複数のスレッドは何の利益ももたらさないように見えます。 問題は次のとおりです。 n個の単語を含む段落が与えられ、m個のスレッドが与えられます。あなたがする必要があるのは、各スレッドが1つの単語を印刷し、次のスレッドに制御を与える必要があることです。このように、各スレッドは1つの単語を印刷し続け、最後のスレッドが来た場合、最初のスレッドを呼び出す必要があります。すべての単語が段落に印刷されるまで、印刷が繰り返されます。最後に、すべてのスレッドが正常に終了する必要があります。どのような同期を使用しますか？ ここではスレッドを活用できないと強く感じていますが、インタビュアーは私の同期スキルを測定しようとしていると考えています。この問題で、複数のスレッドに価値をもたらす何かが欠けていますか？ コードは不要です。考えてみてください。自分で実装します。
5
REST APIで双方向同期をどの程度最適に表現しますか？
リソースを持つWebアプリケーションと、別の同様のリソースを持つリモートアプリケーションへの参照があるシステムを想定して、「ローカル」リソースを「リモート」リソースと同期する双方向同期アクションをどのように表現しますか？ 例： ToDoリストを表すAPIがあります。 GET / POST / PUT / DELETE / todos /など そのAPIは、リモートTODOサービスを参照できます。 GET / POST / PUT / DELETE / todo_services /など APIを介してプロキシ経由でリモートサービスから仕事を操作できます GET / POST / PUT / DELETE / todo_services / abc123 /など TodoのローカルセットとTODOSのリモートセット間で双方向の同期を行う機能が必要です。 ある種のRPCでは、次のことができます POST / todo_services / abc123 / sync / しかし、「動詞は悪い」という考えでは、このアクションを表現するより良い方法はありますか？
2
StringBuilderまたはStringBufferはいつ使用する必要がありますか？
実稼働Webアプリケーションでは、私の仲間のプログラマーがStringBufferをどこでも使用していました。現在、アプリケーションの開発と修正を担当しています。StringBuilderとStringBufferを読んだ後、すべてのStringBufferコードをStringBuilderに置き換えることにしました。これは、データBeanでスレッドセーフが必要ないためです。 例：（各データBeanでStringBufferの使用を確認できます） @Override public String toString() { StringBuffer sb = new StringBuffer();// replace it from StringBuilder sb.append(" ABCD : ").append(abcd); sb.append(", EFGH : ").append(efgh); sb.append(", IJKL : ").append(ijkl); } セッション/リクエストごとに個別のデータBeanを作成します。セッションは、他のユーザーがアクセスできない単一のユーザーによって使用されます。 移行する前に他の点を考慮する必要がありますか？ 単一のスレッドがある場合（待機中のスレッドがないか、新しいスレッドがオブジェクトロックを探していない場合）、StringBufferまたはStringBuilderのどちらでも同様に実行されます。StringBufferの場合、オブジェクトロックを取得するのに時間がかかることは知っていますが、オブジェクトロックの保持/解放を除いて、それらの間にパフォーマンスの違いがあるかどうかを知りたいです。
2
同期用のベクタークロックではなく明示的なDAG
私は、一連のピア間でのデータ同期へのアプローチを検討し始めました。ピアは切断された方法で動作し、ローカルの変更をマージするために相互に同期できる必要があります。 ピアは、ローカルアップデートを「3方向マージ」とマージできるはずです。そのため、同期ピアでは、どのファクトがより新しいかを知る必要がありますが、厳密な順序付けがない場合は、共通ルートに基づいてファクトをマージできる必要があります。 独立したピアが変更を行う場合、「クロック」を使用して「タイムスタンプ」を付けることができます。「時計」と「タイムスタンプ」という用語を使用しますが、ウォールタイムクロックを意味しません。私は、因果関係を明確にするイベントのある種の部分的な順序付けを意味します。それはだ「の前に起こった」非循環有向グラフ（DAG）を形成するイベント間の関係。 この部分的な順序付けを行う「通常の」方法は、ベクトルクロックを使用することです。ただし、これらは非常に大きくなる可能性があります。間隔ツリークロックなどの最近の開発では、タイムスタンプのよりコンパクトなストレージが提供されます。 私がまったく明らかにしていないのは、同期プロトコルが明らかにDAGを「単純に」明示的に保存しない理由です。（それともそうですか？） ピアは、UUIDをランダムに生成することにより（またはなどの他の手段により<peer-name> + <local-monotonically-increasing-counter>）、独立してタイムスタンプを作成できます。このタイムスタンプの順序は、そのピアにとって完全に明確です。 2つのピアが互いに同期すると、新しいタイムスタンプに同意できます。繰り返しますが、このタイムスタンプの順序は、両方のピアにとって明確です。 現在、ピア間でDAGの前に発生したイベントを渡す必要がありますが、これのストレージおよび帯域幅の要件はわずかです。時点はグラフの頂点です。そのため、1つまたは2つの着信エッジがあります（クライアント上のイベント用に1つ、クライアント間の同期用に2つ）。これは制限されており、ネットワーク内のピアの数に依存しません。 個々の時点を使用するには、これにつながる時点のグラフが必要です。しかし、私の知る限り、することができる任意のピアを知っている時点では（それはそれ自体を生成し、または他のピアとそれを生成し、またはそれと同期するときに、別のピアによってそれを言われていた）しているにも持っていましたその時点までの歴史について知る機会。おそらくこれには帰納的証拠があると思います。 DAGの保存と同期は明示的に簡単に思えますが、これは実際に使用されていますか？そうでない場合、ベクタークロックが優先されるのはなぜですか？ ノート ピアツーピア クライアントサーバーソリューションよりもピアツーピアソリューションの方が望ましいです。 エンドトポロジとして考えられるのは、多数のクライアントが相互に複製するはるかに小さなサーバーグループに接続することです。ただし、この特定のトポロジを必要とするソリューションではなく、この特定のトポロジをサポートする一般的なソリューションがあると便利です。
1
同期を廃止し、待機して通知する時間ですか？
synchronizedを使用するよりも使用することが望ましい単一のシナリオ（古代のJVMとの互換性以外）がありますLockか？誰でも新しいシステムを使用しwaitたりnotify、新しいシステム上で正当化することはできますか？ 実装でそれらのいずれかを使用する必要があるアルゴリズムはありますか？ この問題に触れた以前の質問がありますが、これをもう少し詳しく見ていきたいと思いdeprecateます。新しい施設で解決されたtrapや落とし穴、注意事項は非常に多くあります。すぐにそれらを陳腐化する時が来るかもしれないと感じています。
2
変更ログとしてMongoDBを使用する2つのシステム間の同期
2つの関連システムを開発しています。そのうちの1つ（A）は、お客様のマシンにインストールされます。残りの（B）は私の組織で使用されます。 各システムには独自のデータベース（リレーショナル）があり、スキーマは異なります。ただし、両方のシステムを同期する必要があります。さらに、Bの一部の変更はすべてのクラスAシステムにエクスポートする必要があり、その他は特定のシステムにのみエクスポートする必要があります。 一部のお客様はインターネットに接続していないため、場合によっては、ファイルの交換を介して同期を行う必要があります。 そのため、次のようにこの問題を解決する予定です。 各システムは、データベースの変更ログを保持しています。MongoDBで実装する予定です。 システムが同期プロセスを初期化するとき、ログから行われたすべての変更を取得します。システムがBの場合、取得される変更は宛先によって異なります。次に、システムはそれらをXML形式でシリアル化し、最後に（ファイルまたはネットワーク経由で）送信します。 他のエンドポイントが変更セットを受信すると、それらのシリアル化を解除します。次に、システムはデータに対していくつかの変換を行います。これは必要な場合があり、最後に変更を記録します。このステップでは、必要な場合、システムは存在する可能性のある競合を解決する必要があります。 最後に、受信側システムはその変更（および競合解決の他の製品）を送信します。 このアプローチは実行可能で、スケーラブルでエレガントですか？どのような変更または追加を行いますか？
2
オフラインシステムとの同期
私は、データを生成してサーバーに送信するモバイルデバイス（アプリケーションが埋め込まれている）からのビジネスデータを同期するシステムを設計しています。同期される各行は、データベースに特定のビジネスログを生成します。 同期するデータによって、ビジネスデータの最終変更日よりも古い日付（同期データ内）のデータが生成された場合、それを無視して、ログをデータベースに追加するだけです。アップロードされたデータが処理されると、データベースからデータがフェッチされ、デバイスにダウンロードされます。 書き込み直後のこのダウンロードのため、同期は同期でなければなりません。このような何かが私の既存のソリューションを置き換えるのに十分な価値がある場合は、まだリーダー/ライターのパターンを持つことが可能です。より重要なことは、最新のデータをダウンロードできることです。そのデータは全体としてフェッチされ、現時点では差分は実装されていません（後で来る可能性がありますが、問題はありません）。 同じビジネスオブジェクトで複数の同期を実行している可能性があります。それは起こりそうにありませんが、起こり得、それを処理できることを望んでいます。組み込みモバイルアプリケーションを数日間再同期せずに使用しない限り、同期は数秒続くことが予想されますが、数分は続きません。 同期されるデータの量は、同期プロセスも大きくなることは想定されていません。 つまり、同期の方法で相互排除を使用することになります。より正確には、Javaを使用し、読み取り専用の同期をブロックしないように、同期プロセス全体ではなく、書き込みメソッドに同期を設定します。 私が知りたいのですが ： この方法が理にかなっていますか？同期プロセスの量と時間は許容範囲です。 一般的に、どのような概念を検討する必要がありますか。おまけ：Springモジュールにこれらの概念の実装がある場合。
1
HTML5ビデオスプライト
現在、単一のキャンバスに複数の同期されたビデオソースを動的に合成する必要があるプロジェクトに取り組んでいます。私がまとめた最初のプロトタイプはビデオをHTMLVideoElementsにロードし、次にrequestAnimFrameを（Paul Irishのshimを介して）使用してこれらを単一のキャンバスに描画し、異なる要素間の同期を維持しました。 これは機能的であり、システムはかなり良好に同期を保持できます（許容誤差+/- 80ミリ秒）が、控えめに言ってもやや非効率的です。私は最適化について考えてきましたが、かなり簡単に思える1つのアプローチは、すべてのメディアを1つの大きな「ビデオスプライト」に組み合わせてこれを提供することです。これにより、それを単一のビデオ要素にロードして、クライアント側で関心領域を抽出してレンダリングし、drawImage()ソース間の同期を管理する必要をなくすことができます。 他の誰かが過去に似たようなものを実装しましたか？もしそうなら、どのアプローチがあなたのためにうまくいきましたか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.