タグ付けされた質問 「distributed-computing」

Amazon（または他の大規模なeコマースWebアプリケーション）のような大規模なオンラインストアを運営しており、倉庫内の物理的なアイテムの量が限られている会社を想像すると、どのように最適化できますか？単一のボトルネック？もちろん、レプリケーションを備えた多数のデータベースと、負荷を個別に処理している多くのサーバーが必要です。ただし、複数のユーザーが別々のサーバーでサービスを提供しており、両方が同じアイテムをカートに追加しようとする場合、残りのアイテムは1つだけであるため、そのアイテムの数量には「真実の源」が必要です。これは、少なくとも、単一のアイテムの製品情報にアクセスするすべてのユーザーが、同じデータベースにシリアルでクエリを実行する必要があるという意味ではないでしょうか？ 分散コンピューティングを使用して大規模なストアを運営し、インベントリ情報を含む単一のDBに大きなボトルネックを作成しない方法を理解したいと思います。

29 web-applications  scalability  distributed-computing 

分散キューの問題を解決するさまざまな方法について、もっと詳しく学ぼうとしています。それで、私はすでにどんな製品、サービス、実装と研究論文があるかについて知りたいです。 実装は多くの課題に直面し、トレードオフを余儀なくされます。 順序が強いですか、緩いですか？ べき等を入れていますか？ 単一のマシンに収まるものよりも多くのキューを使用できますか？ 単一のマシンに収まるデータよりも多くのデータをキューに入れることができますか？ データを失う可能性がある前に、何台のマシンがクラッシュする可能性がありますか？ ネットスプリットを許容できますか？ ネット分割が修正されると、自動的にデータを調整できますか？ クライアントがクラッシュした場合に配信を保証できますか？ 同じメッセージが複数回配信されないことを保証できますか？ ノードは任意の時点でクラッシュし、戻ってきて、ジャンクを送信できませんか？ ダウンタイムなしで実行中のクラスターにノードを追加、またはノードからノードを削除できますか？ ダウンタイムなしで実行中のクラスターのノードをアップグレードできますか？ 異種サーバーで問題なく実行できますか？ サーバーのグループにキューを「固定」できますか？（例：「これらのキューはヨーロッパのデータセンターでのみ許可されています」） 可能であれば、少なくとも2つのデータセンターにデータレプリカを配置することを確認できますか？ 私は、どの実装でもそのすべてに「はい」と言うことができるという幻想は持っていません。さまざまな実装について聞いてみたいだけです。それらがどのように機能するか、どのようなトレードオフを行ったか、そしておそらく彼らが特定のトレードオフのセットを決定した理由。 また、上記のリストで見逃したかもしれない課題がある場合。

23 distributed-computing  message-queue 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 分散コンピューティングを正確に構成するものは何ですか？また、並列化/コンカレントコンピューティングとどのように違いますか？ リソースへのアクセスを同期しようとする複数の並列スレッドでミューテックスとセマフォを使用することは、分散コンピューティングの領域で問題になりますか？

14 distributed-computing  operating-systems 

私は最近イベントの調達について読んでおり、その背後にあるアイデアが本当に好きですが、次の問題にこだわっています。 コマンド（Webサーバーなど）を受信し、結果としてイベントを生成し、それらを中央ストアに格納するN個の並行プロセスがあるとします。また、ストアからイベントを順番に適用することにより、すべての一時的なアプリケーションの状態が個々のプロセスのメモリで維持されると仮定します。 ここで、次のビジネスルールがあるとしましょう。各個別のユーザーには一意のユーザー名が必要です。 2つのプロセスが同じユーザー名Xのユーザー登録コマンドを受信した場合、両方がXがユーザー名のリストにないことを確認し、ルールは両方のプロセスを検証し、両方とも「ユーザーXの新しいユーザー」イベントをストアに保存します。 現在、ビジネスルールに違反しているため、一貫性のないグローバル状態に入りました（同じユーザー名を持つ2人の異なるユーザーがいます）。 従来のNサーバー<-> 1 RDBMSスタイルのシステムでは、データベースは、このような不整合の防止に役立つ同期の中心点として使用されます。 私の質問は、イベントソースシステムは通常、この問題にどのように対処するのかということです。すべてのコマンドを順番に処理するだけですか（たとえば、ストアに書き込むことができるプロセスの量を1に制限するなど）。

12 distributed-computing  event-sourcing  eventual-consistency 

ユーザーがロードバランサーをヒットし、ロードバランサーが転送先のWebサーバーを決定すると、次に何が起こりますか？ロードバランサーはリクエストとそのすべてのデータをウェブサーバーに転送し、ウェブサーバーの応答を受信して​​ユーザーに返しますか？ それとも、ロードバランサが選択したサーバーのIPアドレスをブラウザに返すだけで、ブラウザが特定のサーバーとの新しい接続を開かなければならないリダイレクトのようなものですか？ 私の直感では、後者ではないだろうと言っています。これは、すべてのWebサーバーのIPアドレスが公開されることを意味し、セキュリティ上の理由から、ロードバランサーアドレスのみを公開するのが最善であると考えました。しかし、SSL terminationロードバランサーで有効にすると、リダイレクトされたサーバーでSSLを再確立する必要がないので、私は正確にはわかりません。

12 distributed-computing  load-balancing 

CQRSではバグを修正するのは簡単で、イベントを再デプロイして再生するだけだと言われています。 ただし、イベントを再生するだけでアイテムが2回出荷される場合、イベントの1つが原因で、制御できない外部システムが顧客に「アイテムを出荷する」原因となる場合はどうでしょうか。 それをどのように解決しますか？

10 distributed-computing  cqrs  event-sourcing 

最近、クレジットカード処理を扱うプロジェクトを完了しました。私が直面した問題の1つは、通知メッセージの遅延/起こりうる失敗の処理でした。最も複雑な例は次のとおりです。 支払い要求を送信する外部システム 私のシステムはその要求を支払いゲートウェイへの要求に変えます ユーザーをゲートウェイに送信する ユーザーが支払いを実行するのを待っています ユーザーがシステムに戻ったが、システムが成功/失敗の通知を受け取るまで保留される 失敗に応じてユーザーを外部システムに送り返す さらに困難だったのは、通知の送信に失敗すると、ゲートウェイは15分ごとに何時間も通知を送信しようとすることでした。 保留中のトランザクションのデータベースレコードを使用して解決し、リターンからの成功と失敗に加えて、通知とトランザクション処理のための時限遅延リスナーを検出しました... かなり難しい！ しかし、これは何億回も前に解決されたに違いないので、ベストプラクティスは何ですか？ 私の将来は、これらすべてのシステム間の処理を記述し、時間遅延と起こりうるネットワーク障害を管理することになるので、ベストプラクティスに従いたいと思います。 本/記事の推奨事項は素晴らしいでしょう。 前もって感謝します！

10 web-services  rest  distributed-computing 

ソフトウェアのアーキテクチャと設計の観点から、マイクロサービスはミドルウェアに対してどのように「積み上げ」られますか（意図されていません）私はJavaから来ています。APIとしてのまっすぐなRESTから離れ、少なくともJavaでさまざまなレイヤーと接続パラメーターを抽象化すると、非常に古い学校のアイデアにほぼ完全に戻ってきたようです。仮想化に戻りました... JVMがすでに仮想化されているかどうか。 不可知論的な方法で、RESTful APIをCORBAに抽象化することができ、その利点を主張します。または、よりJava中心の方法で、JMSまたはMDB。 かつて、EJBはJavaで大きな問題でしたが、それがクラスター効果の一部であると認識されていましたが、今、最初に戻りましたか？ または、マイクロサービスは、CORBA、またはさらに優れたMDBにはないものを提供しますか？マイクロサービスの説明（TLDR）Martin Fowlerを読んだとき、もしそうなら、それは悪い問題の良い解決策として私を驚かせます。むしろ、問題を押し広げるだけの複雑さのレベルをもたらすクローズドマインドアプローチ。サービスが本当にマイクロで数が多い場合、それぞれのサービスの実行と維持に1ドルのコストがかかります。 さらに、多くの中で1つのマイクロサービスがそのAPIを変更すると、そのサービスに依存するすべてが壊れます。それはしないように見えるそれは、疎結合思わアジャイルの反対を。それとも私はそれらの言葉を誤用していますか？ もちろん、これらの両極端の間には不確定な量の選択肢があります。 サメ対ゴリラ...行く！ （知識を深めるために、それは皮肉なことを意味し、私の意図ではありません。質問は額面通りに受け取られることを意味します。質問を改善できる場合は、そうするか、コメントしてください。修正します。 ） Dockerで実行されている多数のマイクロサービスがすべて1台のマシンで実行され、互いに対話していることを想像してください...狂気。保守や管理が難しく、変更を重ねると予期しないエラーが発生するため、何も変更することはほとんど不可能です。これらのサービスが異なるマシンに分散していることはどういうわけですか？そして、それらが分散されている場合、確かに、非常に古くからあるいくつかの手法が、少なくともある程度、分散コンピューティングを解決しています。 なぜ水平スケーリングが普及しているか、少なくとも望ましいのですか？

9 java  enterprise-architecture  distributed-computing  client-server  middleware 

これは、Javaアプリケーションでの2つの分散コンポーネントの一般的なシーケンスです。 1 A sends request to B 2 B starts some job J in parallel thread 3 B returns response to A 4 A accepts response 5 Job finishes after some time 6 Job sends information to A 7 A receives response from a Job and updates これは、すべてが機能すると仮定した場合の理想的なシナリオです。もちろん、実生活は失敗に満ちています。たとえば、最悪のケースの1つは、#6単にネットワークが原因で失敗した場合です。ジョブは正しく実行されましたが、ジョブAについて何も知りません。 このシステムのエラーを管理する方法についての軽量なアプローチを探しています。多くのコンポーネントがあるため、エラー処理のためにそれらをすべてクラスター化しても意味がありません。次に、同じ理由で各コンポーネントに再度インストールされる分散メモリ/リポジトリの使用を取りやめました。 私の考えは、Bに1つの絶対状態を持ち、Aに永続状態を決して持たないという方向に向かっていAます。これは、次のことを意味します。 …

8 java  distributed-computing 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 5年前休業。 分散型の問題追跡は、私にとってベルトのような考えのように見えますが、実際に大きな成功を収めたことはありません。その正当な理由はありますか？ 気がついた： どこでもバグズ セットアップするには複雑すぎる 要件が多すぎる ある程度成功し、一部の大規模プロジェクトで使用されている 化石 あまりにも多くのものを統合しようとし、最終的にそれらすべてのやや悪いバージョンになります-おそらく、まともな（おそらく私が見た中で最高の）分散型問題追跡部分を除いて 他のいくつかの小さなプロジェクト どれも牽引力を獲得していません 私は自分で作ることを考えていますが、始める前に、他の誰もが大きな成功を収めていない理由を知りたいと思います。 予想される問題：（すべて克服できると思います） 更新された分散問題をマージすることは、コードファイルをマージするのと同様に複雑です。 コメントはいつでも入ってくる可能性があり、おそらく正しいフローではないため、会話の継続性が破壊される可能性があります 最新の問題がある中央サーバーへの期待

8 version-control  issue-tracking  distributed-computing