mirrors/system-design-primer
mirrors
/
system-design-primer
mirror of https://github.com/donnemartin/system-design-primer.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge 077643082e into a07e261677

This commit is contained in:
SATO Yusuke 2023-04-13 08:32:33 +08:00 committed by GitHub
parent a07e261677 077643082e
commit 867b393578
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
README-ja.md
View File

@ -1280,32 +1280,32 @@ def set_user(user_id, values):
<i><a href=http://lethain.com/introduction-to-architecting-systems-for-scale/#platform_layer>Source: Intro to architecting systems for scale</a></i>
</p>
非同期のワークフローはもし、連続的に行われるとリクエスト時間を圧迫してしまうような重い処理を別で処理する手法です。また、定期的にデータを集合させるなどの時間がかかるような処理を前もって処理しておくことにも役立ちます。
非同期のワークフローは、インラインで実行したらリクエスト時間を圧迫してしまうような重い処理の、リクエスト時間を短縮する手法です。また、定期的にデータを集約するといった時間のかかる処理を前もって処理しておくのにも役立ちます。
### メッセージキュー
メッセージキューはメッセージを受け取り、保存し、配信します。もし、処理がインラインで行うには遅すぎる場合、以下のようなワークフローでメッセージキューを用いるといいでしょう:
* アプリケーションはジョブをキューに配信し、ユーザーにジョブステータスを伝えます。
* ワーカーがジョブキューから受け取って、処理を行い、終了したらそのシグナルを返します。
* アプリケーションはジョブをキューに配信し、ユーザーにはジョブのステータスを伝えます。
* ワーカーはジョブをキューから受け取って、処理を行い、ジョブが終了したらそのことをユーザへ通知します。
ユーザーの処理が止まることはなく、ジョブはバックグラウンドで処理されます。この間に、クライアントはオプションとして、タスクが完了したかのように見せるために小規模の処理を行います。例えば、ツイートを投稿するときに、ツイートはすぐにあなたのタイムラインに反映されたように見えますが、そのツイートが実際に全てのフォロワーに配信されるまでにはもう少し時間がかかっているでしょう。
ジョブはバックグラウンドで処理を行うため、ユーザの処理が止められることはありません。この際、タスクが完了したかのように見せるため、クライアント側でちょっとした処理を行ってもいいでしょう。例えば、ツイートを投稿したとき、あなたのタイムラインではそのツイートがすぐ反映されたように見えます。ですが、そのツイートが全てのフォロワーに実際に配信されるまでには、もう少し時間がかかっているかもしれません。
**Redis** はシンプルなメッセージ仲介としてはいいですが、メッセージが失われてしまう可能性があります。
**Redis** はシンプルなメッセージブローカーとしては便利ですが、メッセージが失われてしまう可能性があります。
**RabbitMQ** はよく使われていますが、'AMQP'プロトコルに対応して、自前のノードを立てる必要があります。
**RabbitMQ** はよく使われていますが、'AMQP'プロトコルを使う必要があります。また、自前でノードを管理する必要があります。
**Amazon SQS** という選択肢もありますが、レイテンシーが高く、メッセージが重複して配信されてしまう可能性があります。
**Amazon SQS** はホスティングされていますが、遅延が大きく、またメッセージが重複して配信されてしまう可能性があります。
### タスクキュー
タスクキューはタスクとその関連するデータを受け取り、処理した上でその結果を返します。スケジュール管理をできるほか、バックグラウンドでとても重いジョブをこなすこともできます。
タスクキューはタスクとその関連するデータを受け取り、処理した上でその結果を返します。スケジューリングもできますし、バックグラウンドで計算集約的なジョブをこなすのにも使えます。
**Celery** はスケジューリングとpythonのサポートがあります。
### バックプレッシャー
もし、キューが拡大しすぎると、メモリーよりもキューの方が大きくなりキャッシュミスが起こり、ディスク読み出しにつながり、パフォーマンスが低下することにつながります。[バックプレッシャー](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html)はキューサイズを制限することで回避することができ、高いスループットを確保しキューにすでにあるジョブについてのレスポンス時間を短縮できます。キューがいっぱいになると、クライアントはサーバービジーもしくはHTTP 503をレスポンスとして受け取りまた後で時間をおいてアクセスするようにメッセージを受け取ります。クライアントは[exponential backoff](https://en.wikipedia.org/wiki/Exponential_backoff)などによって後ほど再度時間を置いてリクエストすることができます。
もし、キューが拡大しすぎると、メモリーよりもキューの方が大きくなりキャッシュミスが起こり、ディスク読み出しにつながり、パフォーマンスが低下することにつながります。[バックプレッシャー](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html)によりキューサイズを制限することで、高スループットと、キューに入っているジョブの応答時間の両方を良好に保つことができます。キューがいっぱいになると、クライアントはサーバービジーもしくはHTTP 503をレスポンスとして受け取りまた後で時間をおいてアクセスするようにメッセージを受け取ります。クライアントは[exponential backoff](https://en.wikipedia.org/wiki/Exponential_backoff)などによって後ほど再度時間を置いてリクエストすることができます。
### 欠点: 非同期処理