WEBVTT

00:00:01.460 --> 00:00:02.340
いらっしゃい。

00:00:04.930 --> 00:00:05.880
人々 が行っている方法

00:00:08.810 --> 00:00:14.600
良いですか?皆さんにしましたほとんど会議の終了時刻です。

00:00:15.630 --> 00:00:17.150
経験はこれまでにされているでしょうか。

00:00:17.160 --> 00:00:19.360
[拍手]

00:00:19.520 --> 00:00:20.120
>> 良い。

00:00:20.170 --> 00:00:24.940
すばらしい。、言うまでもなく、最後のベストを常に保存します。

00:00:26.240 --> 00:00:32.190
うまくいけばそれは、私は裏切りませんスタッフ。私は本当に高く評価します。

00:00:32.240 --> 00:00:34.450
ようにこの午後。

00:00:35.200 --> 00:00:40.360
私は Abhishek Lal。プログラム マネージャーAzure プラットフォーム チーム。

00:00:41.090 --> 00:00:45.840
これは、チームが PaaS を構築モバイル サービスなどのサービス

00:00:45.890 --> 00:00:48.550
Azure キャッシュ サービス バスです。

00:00:49.240 --> 00:00:51.080
メディアのサービスです。

00:00:51.720 --> 00:00:54.320
これらのサービスは何チームは、所有しています。

00:00:54.830 --> 00:00:58.940
具体的に仕事をしていたとさらに、過去 3 年の

00:00:58.990 --> 00:01:05.100
仲介のメッセージの構築にピース。このようなキュー、

00:01:05.150 --> 00:01:08.720
トピックは pub のサブある部分。

00:01:09.470 --> 00:01:15.150
今日の私たちが話しします。大規模メッセージング。

00:01:17.010 --> 00:01:22.030
キューおよびトピック。人々 は、今すぐサービス バスに慣れています。

00:01:22.840 --> 00:01:26.920
それはリレーが含まれます。これは通知のハブが含まれます

00:01:27.780 --> 00:01:29.010
キューおよびトピック。

00:01:29.560 --> 00:01:34.840
これは、全体の広範な種類のメッセージング関連のサービス。

00:01:35.710 --> 00:01:39.560
この特定のセッションになります。キューに主に焦点を

00:01:39.610 --> 00:01:46.260
プライマリのトピック領域です。質問がある場合は

00:01:46.310 --> 00:01:50.120
何が知りたいかリレーは特にまたは

00:01:50.170 --> 00:01:55.150
通知のハブ、私を喜んで答えをまたは少なくともポイント

00:01:55.200 --> 00:01:57.410
正しい方向にします。

00:01:58.820 --> 00:02:00.930
多くのことがあります。今日をカバーします。

00:02:01.710 --> 00:02:04.730
すべてのさまざまな側面について説明します。スケールします。話をしたいです。

00:02:04.780 --> 00:02:08.490
送信者と受信者は、スループットでは、すべての異なる

00:02:08.540 --> 00:02:11.630
パターンだけでなく、コードの詳細を指定します。

00:02:12.390 --> 00:02:14.870
スケールを達成できるか。

00:02:15.810 --> 00:02:19.040
したがって、良いペースを維持するように設定しましょう。

00:02:19.640 --> 00:02:24.190
質問はすばらしいです。私を参照してください場合短い質問をカットを開始

00:02:24.240 --> 00:02:27.780
後で、もう少しだけようにしました。必要な全てのものをカバーすることができます。

00:02:27.830 --> 00:02:31.490
カバーします。私は後にできます。セッションは常に

00:02:31.540 --> 00:02:36.200
到達して、私は維持しながら対話型。何があるか

00:02:36.250 --> 00:02:41.270
マイクを右ここでは。と呼ぶこと歩いて.

00:02:43.930 --> 00:02:48.720
何の話から始めますの新しい。更新プログラムの単なる並べ替え

00:02:48.770 --> 00:02:51.210
でした発表内容 SDK 2.3 として。

00:02:52.250 --> 00:02:56.290
話を切り替えますスケールの大きさ。

00:02:56.340 --> 00:03:00.420
送信者、受信者、についてお話しスループットを実現します。

00:03:01.800 --> 00:03:05.770
いくつかの時間を費やすと可用性を考慮します。

00:03:05.820 --> 00:03:07.850
広範な意味での可用性

00:03:09.190 --> 00:03:14.340
力、SLA の向上と方法アプリケーションを設計するには

00:03:14.390 --> 00:03:19.520
常に上に常に、実行しています。触れますがいくつかのように

00:03:19.570 --> 00:03:20.510
上の時間です。

00:03:22.060 --> 00:03:25.780
2.3 ようにしてください。

00:03:26.330 --> 00:03:28.310
何が私たちだけリリースですか。

00:03:29.070 --> 00:03:32.540
メッセージ セッション。メンバーのようにjuries は、プッシュです。

00:03:32.590 --> 00:03:36.970
スタイル API です。これは、基本的に後からのすべてのハード作業

00:03:37.020 --> 00:03:42.960
C ループまたは何かを記述します。複雑な問題の

00:03:43.010 --> 00:03:46.420
使用すると、非常にイベント-別メッセージを処理するモデル。

00:03:46.470 --> 00:03:50.110
これは、受信機側の API です。したがって我々 のセッションの。

00:03:50.160 --> 00:03:52.680
間違いなく説明します。今日詳細。

00:03:53.890 --> 00:03:58.440
接続モードを自動検出します。これは、実際のいずれか

00:03:58.490 --> 00:04:02.520
Azure のサービス バスがされているキーの値接続します。

00:04:02.950 --> 00:04:07.700
キューおよびトピックでは、クラウドにファイアウォールの内側から

00:04:07.750 --> 00:04:11.450
独自のデータ ・ センターから、お客様のデータ センター

00:04:11.500 --> 00:04:16.230
非常によく保護されているに座っています。種類のファイアウォール、サービス

00:04:16.280 --> 00:04:19.660
バスが TCP ポートにだけでなく、送信の接続機能

00:04:19.710 --> 00:04:22.110
ポート 83 と 443 ですが

00:04:23.670 --> 00:04:25.860
ながら、TCP ポートがブロックされます。

00:04:26.700 --> 00:04:30.790
この機能はまだ使用可能直接設定する場合にのみ

00:04:30.840 --> 00:04:34.230
TCP にモードを使用してディレクトリしないかを選択する必要もありました。

00:04:34.910 --> 00:04:38.730
これで、コード内で設定できます。それを自動検出しては

00:04:38.780 --> 00:04:42.910
かどうかは TCP ポートを自動的に表示します。我々 はそれを使用します。

00:04:42.960 --> 00:04:48.410
私たちは、ファイアウォールがブロックする場合HTTP の下にドロップします。その SDK

00:04:48.460 --> 00:04:51.560
2.3 が使用メッセージングのも。

00:04:54.390 --> 00:04:57.980
CORS をサポートします。どのように多くの人々CORS は何知っているか。

00:05:00.360 --> 00:05:04.200
ほとんどの人々 知っています。それは基本的に簡単に送受信可能にします。

00:05:04.250 --> 00:05:09.370
ブラウザー。アイデアはします。常にことができますが、

00:05:09.420 --> 00:05:14.320
SCTP の STPI。行う送信メッセージは、メッセージを表示します。

00:05:14.370 --> 00:05:18.920
CORS を今すぐになりますが、ほとんどブラウザーと web サイトを簡単に

00:05:18.970 --> 00:05:23.650
統合バックアップと説明今日の詳細を。

00:05:25.010 --> 00:05:29.530
同様の支援パフォーマンスとスケール

00:05:29.580 --> 00:05:34.760
我々 の HTTP 送信者バッチが利用可能なようになりました。

00:05:35.200 --> 00:05:43.980
クライアント側のパフォーマンスのいくつかカウンターは、するには

00:05:44.030 --> 00:05:46.900
実際にアプリケーションをもたらす複雑である場合、または

00:05:46.950 --> 00:05:50.450
別の環境でテストを実行しようとしています。必要があります。

00:05:50.500 --> 00:05:53.340
デバッグし、プロファイルする必要があります。クライアントを追加したので、

00:05:53.390 --> 00:05:57.890
メッセージの送信側のパフォーマンス カウンター1 秒あたりの 2 つ目は、文字ごと

00:05:57.940 --> 00:06:01.460
実際には、ことができますが、そのような機能と本当に役立つプロファイル

00:06:01.510 --> 00:06:05.250
メッセージングしているレイヤーが行っている全体的な反対

00:06:05.300 --> 00:06:09.020
行事を行っています。それらがそれらのパフォーマンスをマニフェストします。

00:06:09.070 --> 00:06:14.230
NuGet パッケージの一部として、カウンターそのため、本当にそれで

00:06:14.280 --> 00:06:17.550
いくつか良いのデバッグを実行できます。

00:06:20.550 --> 00:06:23.340
最後に、補配信不能キュー。

00:06:23.880 --> 00:06:27.380
Deadlettering は、非常に、非常に強力です場所は保護機能

00:06:27.430 --> 00:06:30.820
有害がある場合、バック エンドを中します。メッセージです。通常、これらは

00:06:30.870 --> 00:06:34.620
有害なキューしようとすると呼ばれるメッセージを受信して、

00:06:34.670 --> 00:06:38.600
メッセージの形式ではありませんがどこかに、コード内のバグ

00:06:38.650 --> 00:06:42.080
デ civilizer をどこかで場所を開くことしていません。

00:06:42.130 --> 00:06:44.560
メッセージと、バックエンドのクラッシュします。

00:06:45.780 --> 00:06:50.390
サービス バスを提供する機能最大配信の設定

00:06:50.440 --> 00:06:54.420
10、およびどのようなカウントある場合、我々 を参照してくださいになります

00:06:54.470 --> 00:06:57.660
メッセージを提供し、これをしました。10 回としてあります。

00:06:57.710 --> 00:07:01.310
ないが正常に完了しますメッセージを移動するとから

00:07:01.360 --> 00:07:03.240
メイン キューに、配信不能キュー。

00:07:03.870 --> 00:07:07.930
文字通り、アプリケーションは、このように既定では、回復可能

00:07:08.190 --> 00:07:12.840
1 つを記述する必要はありません。コードの保護

00:07:12.890 --> 00:07:18.660
バック エンド サーバーです。その補チャネルすることが

00:07:18.710 --> 00:07:23.810
メッセージは自動的にリッチを作成します。メッセージ フローとします。

00:07:23.860 --> 00:07:30.000
可能性のあるアプリケーションを実行できます。6、8、10 のキューおよび補

00:07:30.050 --> 00:07:34.450
配信不能キューにすべてのつまり、1 つのキュー

00:07:34.500 --> 00:07:38.530
ここで 1 つの場所に移動する必要があります。すべての有害なメッセージが表示されます。

00:07:38.980 --> 00:07:42.340
キューの数に関係なくトピック、またはサブスクリプションを

00:07:42.390 --> 00:07:46.280
これを使用しているのですが必要な機能を加えることも。

00:07:47.180 --> 00:07:49.910
取り上げる少し詳しく。

00:07:51.740 --> 00:07:57.570
簡単に要約したいでした。最後の 4 月以降は

00:07:57.620 --> 00:08:01.400
については今日のため拡張性とパフォーマンスの条件

00:08:01.450 --> 00:08:05.780
表示されます多くのスループットこれらの機能を参照します。

00:08:06.180 --> 00:08:08.570
それらを呼び出すたいだけかどうかの条件にしています。

00:08:08.620 --> 00:08:12.370
現在すでに利用可能なとしています。いくつかの時間をしているが

00:08:12.420 --> 00:08:16.250
含まれているにも関連があります。

00:08:18.520 --> 00:08:22.290
ここに 1 つのサービスを提供します。下の行は、最初の

00:08:22.340 --> 00:08:26.310
約束をサービス バスに最後のためサービス バスで行った年

00:08:26.360 --> 00:08:28.900
Windows server リリース 1.1。

00:08:29.580 --> 00:08:33.210
これはの完全に対称キューおよびトピックを意味

00:08:33.260 --> 00:08:37.450
たとえば、SDK 2.1 を取得する場合最後の SDK

00:08:38.470 --> 00:08:42.010
いずれかヒットすることができます。サービスのすべてを premise か

00:08:42.060 --> 00:08:45.070
使用可能な機能です。

00:08:46.760 --> 00:08:51.600
クラウドのリリースのようにこのリズム3 か月ごとを

00:08:51.650 --> 00:08:55.290
3 ～ 4 か月ごとに表示できます。前提にリリース

00:08:55.340 --> 00:08:59.520
1 年に最低 1 回は、私たちにしてください。維持し、両方を実現し、

00:08:59.570 --> 00:09:02.680
この機能はパリティに設定します。

00:09:05.540 --> 00:09:08.740
このような使用後での参照

00:09:08.790 --> 00:09:10.010
機能です。

00:09:12.110 --> 00:09:13.310
ご質問のところでしょうか。

00:09:15.820 --> 00:09:16.720
はい、してください。

00:09:16.730 --> 00:09:19.730
[Indiscernible]

00:09:19.950 --> 00:09:23.560
>> などの質問が: とは次の更新プログラムがある場所

00:09:23.610 --> 00:09:28.920
2.3 は、最新の提供は機能があります。

00:09:28.970 --> 00:09:33.240
ここで任意の日付はありません。次のサービスを共有するには

00:09:33.290 --> 00:09:36.320
バスのリリースがありますが2.2、または 1.2 をします。

00:09:37.800 --> 00:09:42.620
しかし、通常これを考えることができます。特定のリリース日

00:09:43.340 --> 00:09:46.900
Windows サーバのリリースと一致ほとんどの時間をください。

00:09:46.950 --> 00:09:51.580
サーバのリリースのため連携を私たちの最大のプラットフォームを取得します。

00:09:51.630 --> 00:09:55.010
私たち私たちが確認するためのメリットします。最新で最高のサーバー

00:09:55.060 --> 00:09:59.310
最新の管理とクラスタ リング探し、改ざんとすべてのもの。

00:09:59.360 --> 00:10:03.610
通常では、このガイドの前提としています同じ種類のリズム

00:10:03.660 --> 00:10:05.820
行われます。良い質問です。

00:10:08.920 --> 00:10:13.130
送信者に拡大または縮小します。始めましょうこれで最初

00:10:13.180 --> 00:10:14.210
スケールの側面。

00:10:15.570 --> 00:10:18.650
送信者は、何があなたの場所の場所

00:10:18.660 --> 00:10:20.040
[Indiscernible]

00:10:20.000 --> 00:10:22.830
シナリオの多くの考えることができます。ここでは。デバイスの考えることができます。

00:10:22.880 --> 00:10:24.970
遠隔測定は、ユーザーの操作。

00:10:26.630 --> 00:10:31.030
システムはイベントを生成します。B をするような状況です。

00:10:31.080 --> 00:10:32.910
生成されるイベントを指定します。

00:10:33.640 --> 00:10:37.660
どのように注意するシナリオのこれらの多くがあります。

00:10:37.710 --> 00:10:41.620
または、多くのそれらのいくつかもイベントの送信者の多く

00:10:41.670 --> 00:10:45.250
多くのイベントでしょうか。すべてのもの考えられるシナリオは。

00:10:46.830 --> 00:10:50.480
ようにコンクリート。よ実際のシナリオを起動します。

00:10:50.530 --> 00:10:54.510
顧客は、今日の使用あります。

00:10:54.560 --> 00:10:58.850
分析のためのイベントを収集します。多くのデバイス。

00:11:00.370 --> 00:11:05.900
これらのデバイスは見覚えがあります。偶然ですが

00:11:05.950 --> 00:11:11.000
確認も拒否私は。したがって、デバイス可能性があります。

00:11:11.050 --> 00:11:12.350
すべてのデバイスがあります。

00:11:13.160 --> 00:11:18.850
始まるすべての今、デバイスのキューにできること

00:11:18.900 --> 00:11:24.250
メッセージは、いくつかのためにできることトピックまたは 1 つのトピックとプッシュ

00:11:24.300 --> 00:11:28.090
多くの情報そのチャンネルに

00:11:29.520 --> 00:11:33.640
トピック内でメッセージをした後考えることができます。

00:11:34.710 --> 00:11:39.370
いくつかのシナリオがあります。それを消費します。

00:11:39.420 --> 00:11:43.330
リアルタイム分析する何か独自のコードを

00:11:43.380 --> 00:11:48.570
顕著になる本当に人気のあるとします。人たちのことでした。

00:11:48.620 --> 00:11:53.840
オルレアンのセッションになります。昨日行われたでしょうか。まあ場合、

00:11:53.890 --> 00:11:57.080
素晴らしい、素晴らしい一部技術のため

00:11:57.130 --> 00:12:02.580
実行中のこの問題を解決するために、コードでは、分散型のスケールで

00:12:02.630 --> 00:12:06.190
扱うかどうかの方式します。イベントが生成されています。

00:12:06.240 --> 00:12:10.830
によって多数の送信者とは方法をそのときどきに相関します。

00:12:12.020 --> 00:12:15.930
どのように実行することを確認これらバックエンド システムは分離しますか。

00:12:15.980 --> 00:12:18.590
どのように確認するこれらバックエンド ・ システムにすることがあります。

00:12:18.640 --> 00:12:24.640
そのレートでメッセージを処理し、動作れている弾力性のある方法ですか。

00:12:25.950 --> 00:12:29.560
そのためにトピックを配置して、中央。などのトピックだけでなく

00:12:29.610 --> 00:12:33.440
ためのバッファーと同じようにつまり、キューは

00:12:33.490 --> 00:12:35.950
バックエンド行うことができます。いくつかの時間がないです。

00:12:36.000 --> 00:12:39.060
次のイベントが失われます。イベント常にありますが、

00:12:39.110 --> 00:12:40.490
pub sub にこともできます。

00:12:41.470 --> 00:12:45.530
その他がある場合ことを意味します。システムが実行するだけです。

00:12:45.580 --> 00:12:51.310
状態の追跡、置くとしましょう値には、Azure のケーブルまたは

00:12:51.360 --> 00:12:56.520
バッチの分析を行っています。リンクでは、ファイル構造

00:12:56.570 --> 00:13:00.330
HDFS Hadoop を実行してジョブです。

00:13:01.400 --> 00:13:05.850
または高さを設定する場合SQL データ ウェアハウスにデータ

00:13:05.900 --> 00:13:09.170
BI のクエリを実行してします。

00:13:09.790 --> 00:13:13.980
ファイルの場所を移動ことができますこれらすべてのシステム同じイベントのストリーム。

00:13:15.280 --> 00:13:18.350
だけでなく、同一のイベント ストリームそれを確認するイベント

00:13:18.400 --> 00:13:21.780
ストリーム、すぎます。BI の倉庫、作業かもしれません使用したくないです。

00:13:21.830 --> 00:13:25.870
すべてのイベント。関連付けられたアクションのいずれかイベントはありませんが属しています。

00:13:25.920 --> 00:13:29.420
コードの内容にのみ所属します。ストリームを分割することができます。

00:13:29.470 --> 00:13:30.210
このようにします。

00:13:32.750 --> 00:13:36.990
次に、バックエンドからかどうかAzure、読む

00:13:37.040 --> 00:13:41.730
テーブルまたは SQL データ ウェアハウスbash を生成することができます。

00:13:41.780 --> 00:13:43.200
掲示板、および分析します。

00:13:44.750 --> 00:13:45.750
キーのいずれかのように

00:13:46.970 --> 00:13:49.340
このパケット内のポイントを設計します。

00:13:50.180 --> 00:13:52.920
最初のトピックをでください。ファンに。

00:13:53.960 --> 00:13:57.730
必須のファンは、数が少ないがあります。デバイスがするよりも、トピックにあります。

00:13:57.780 --> 00:13:59.900
ですね。何カーディナリティがあります。

00:14:01.080 --> 00:14:03.820
それはでするつもりはありません。1 つ。1 つになりません。

00:14:03.870 --> 00:14:07.660
すべてのトピックです。ある可能性があります。北では移動するわけではないです。

00:14:07.710 --> 00:14:12.220
間のどこかにある考案する方法について説明します。

00:14:12.270 --> 00:14:13.860
その右の番号です。

00:14:14.410 --> 00:14:18.960
ロード ・ バランシングを行ういくつかの理由からデータ ・ センターです。

00:14:19.320 --> 00:14:22.490
考えてみれば、これらのデバイスの場合実際には地理的には

00:14:23.190 --> 00:14:26.300
するため、を拡散します。デバイスが使用していることを確認します

00:14:26.350 --> 00:14:30.740
電源の最低量、最低遅延接続を可能に

00:14:30.790 --> 00:14:33.770
に達すると、データのキューします。

00:14:35.480 --> 00:14:39.640
これはデータ全体に負荷分散中央に揃えます。このバスを使用できるように

00:14:39.690 --> 00:14:45.690
Azure の地域のすべてのデータ センターします。機能があるので

00:14:45.740 --> 00:14:50.730
トピックを分散します。上になったバックエンドはありません。

00:14:50.780 --> 00:14:53.890
システムが abdicated することにあります。あまりのこれらの場所は、すべての。

00:14:54.880 --> 00:14:58.000
場合に実際には、Hadoop について考えた場合クラスターの場合、通常は

00:14:58.050 --> 00:15:01.860
で複製するものではありません。すべての地域ですべてのデータ センター。

00:15:01.910 --> 00:15:05.890
これにより、低遅延ですがエンドポイントです。そこからすることができます。

00:15:05.940 --> 00:15:10.490
されている場所へのデータを収集します。生成されます。引き出して

00:15:10.540 --> 00:15:14.310
バック ・ エンド。到達これらのすべての地域と

00:15:14.360 --> 00:15:18.450
別の地域で購読データを関連付けることです。

00:15:20.910 --> 00:15:23.690
すべてが 1 つのサブスクリプションのフィルターを場合は true。この垂直で

00:15:23.740 --> 00:15:27.550
顧客のケースが実際になぜすべてのデータを使用し、

00:15:27.600 --> 00:15:31.700
状態の追跡し、バッチ内のコード分析は双の内にないです。

00:15:31.750 --> 00:15:35.900
それらの 3 つをすべては実際には true。フィルターが 1 つのサブスクリプション

00:15:35.950 --> 00:15:39.960
縮小フィルターは、必要があります。は、フィルターとは、ゲームを

00:15:40.010 --> 00:15:45.060
イベントは、その気します。して、コースの操作を実行できます。

00:15:45.110 --> 00:15:47.360
リアルタイムとバッチ分析。

00:15:49.410 --> 00:15:53.110
このシナリオと考えてクイック デモに入るでしょう。

00:15:54.270 --> 00:15:59.080
CORS が紹介機能をサポートしてください。

00:16:00.290 --> 00:16:05.680
多数のクライアントを可能にするため観点をから

00:16:05.730 --> 00:16:11.600
キュー内にできます。純粋なを使用するだけのメッセージ

00:16:13.270 --> 00:16:15.140
HTTP とします。

00:16:15.730 --> 00:16:21.550
私が web サイトを設定します。皆さんこれもヒットをした場合

00:16:21.600 --> 00:16:25.950
デバイス、または何か。呼ばれるメモ ファイルのユーザーは、Azure

00:16:26.000 --> 00:16:28.260
.NET の web サイトです。

00:16:29.750 --> 00:16:40.510
ここまでは、非常に単純ですここでは、ある JavaScript

00:16:40.560 --> 00:16:41.160
示してください。

00:16:41.880 --> 00:16:43.280
機能とは

00:16:48.770 --> 00:16:53.470
基本的なキーの値を取得します。彼女の名前の値

00:16:53.520 --> 00:16:58.790
領域の名前、キューの名前は何SaaS ルールをくれ、

00:16:58.840 --> 00:17:02.140
共有アクセス署名の承認使用されていることがあります。

00:17:02.190 --> 00:17:03.800
SaaS のキーです。

00:17:04.950 --> 00:17:07.970
基にメッセージを送信できることです。

00:17:14.280 --> 00:17:18.140
メッセージが正常に送信されました。のこれは。場合を表示します。

00:17:18.190 --> 00:17:21.380
大量のクライアントのブラウザーがあります。またはその他のクライアントまたは

00:17:21.430 --> 00:17:25.940
デバイスが、純粋な HTTP だけを実行できます。ここでは、SOAP がありません。ない.

00:17:26.900 --> 00:17:31.300
すべてのエンコーディング。メッセージを配置することができます。JSON のプロパティし、

00:17:31.350 --> 00:17:35.930
メッセージが表示される、非常に簡単な方法キューに入れられました。お見せしましょう

00:17:35.980 --> 00:17:38.170
この web サイトのコードです。

00:17:47.070 --> 00:17:52.110
いるかどうかを確認するここで豊富なプロパティを操作します。

00:17:52.730 --> 00:17:55.220
だけで、非常に基本的なプロパティも

00:17:58.440 --> 00:18:05.280
コードを簡単に送信できます。と実際には、JavaScript ライブラリ

00:18:05.330 --> 00:18:09.370
ここで使用しているが、私を表示することにも。

00:18:16.200 --> 00:18:22.410
これは、web ページあり表示するとすることができますを参照してくださいする方法

00:18:35.560 --> 00:18:40.400
単純な本当に送信し、このメッセージが表示されます。

00:18:40.450 --> 00:18:44.840
HTTP の場合、削除が実際に受信シナリオ。

00:18:45.430 --> 00:18:47.500
我々 は少し後で表示されます。

00:18:48.120 --> 00:18:56.600
Post が送信のシナリオで、put申し訳ありませんが、送信シナリオに関して。

00:18:58.510 --> 00:19:02.420
そこでください。

00:19:03.620 --> 00:19:05.210
私は、いくつかのより多くのメッセージを送信します。

00:19:05.810 --> 00:19:09.220
メッセージを表示するには後援は、ここで私がサーバー

00:19:09.270 --> 00:19:12.280
エクスプ ローラーでロードしています.

00:19:21.330 --> 00:19:25.310
my 名前空間に接続します。私がしたと単純なキューを取得します。

00:19:25.360 --> 00:19:28.770
できますが 2 つあるようになりましたを参照してください。内のメッセージ キューに格納します。かどうかは、

00:19:28.820 --> 00:19:35.430
更新、14 のメッセージが表示されます。したがってメッセージには、あるとき

00:19:35.480 --> 00:19:37.840
このキューに表示されます。

00:19:48.480 --> 00:19:53.620
受信シナリオを取り上げます少しはの後で、

00:19:53.670 --> 00:19:56.920
HTTP クライアントです。これが HTTP クライアントです。

00:19:57.510 --> 00:20:02.200
実際に具体的に説明する必要しますが、についてはプロトコルです。

00:20:02.820 --> 00:20:06.840
考慮事項を決定するときにする必要があります。

00:20:06.890 --> 00:20:11.460
HTTP を使用するかを使用するかどうかAMQP は。サービスをは

00:20:11.510 --> 00:20:13.930
バスはいくつかのプロトコルをサポートします。

00:20:15.060 --> 00:20:21.750
HTTP は、当社の RKDPI だけ AMQP を私は、標準的なプロトコル

00:20:21.800 --> 00:20:27.620
詳細については、説明し、SBMP は、その他.NET での専用のプロトコルです。

00:20:29.320 --> 00:20:35.000
ここでは、それぞれのパフォーマンスに関する考慮事項を持つことができます。考慮に到達します。

00:20:35.710 --> 00:20:39.950
いるデバイスがある場合は、その非常に低くする可能性があります。

00:20:40.000 --> 00:20:44.810
プロトコルについての問題があります。実装できる配置

00:20:44.860 --> 00:20:49.590
上があります。シナリオがあるかどうかにベンダーに依存しない、する場合します。

00:20:50.070 --> 00:20:54.160
アクセスの考慮事項があります。ここでを購入しません。

00:20:54.210 --> 00:20:57.830
任意の特定のプロトコルまたは API1 つのベンダー。いくよ

00:20:57.880 --> 00:21:00.060
AMQP のようなオープンな標準を使用します。

00:21:01.900 --> 00:21:04.390
機能はプロトコルによって変わる可能性があります。

00:21:05.130 --> 00:21:08.000
部分を強調します。多くの損失を取得します。

00:21:08.050 --> 00:21:11.300
人々 は、ほとんどの場合があります。側の機能が表示されます。

00:21:11.950 --> 00:21:13.290
送信側にはいくつかがあります。

00:21:14.560 --> 00:21:19.100
影響、また、ほとんどの時に、受信側の場所

00:21:19.150 --> 00:21:23.270
プロトコルが本当に延期される、理由はたくさんあり、私たちが表示します。

00:21:23.320 --> 00:21:24.240
このケースでは。

00:21:25.950 --> 00:21:28.810
そして、一般的にいくつかクォータの面での違い

00:21:28.860 --> 00:21:32.360
接続数のすることができます。AMQP と SBMP を作成します。

00:21:32.410 --> 00:21:35.550
これらはまた重要な考慮事項です。考えると、まあ、

00:21:35.600 --> 00:21:38.980
使用するプロトコルとどうなる大きなスケールの大きい数

00:21:39.030 --> 00:21:50.090
拒否しますか。したがってバイナリ プロトコルHTTP とその重要します。

00:21:50.140 --> 00:21:53.280
メッセージングでしょうか。キーとはメッセージングのための考慮事項ですか。

00:21:53.810 --> 00:21:56.350
だけしたいキーを呼び出すそれがシナリオを

00:21:56.400 --> 00:21:59.380
その相違点を選択することができます。問題になるかどうかを決定します。

00:21:59.430 --> 00:22:02.780
または、特定のケースではなく。

00:22:04.210 --> 00:22:08.070
HTTP の場合も、必ず呼び出すをしようとしているされます。

00:22:08.120 --> 00:22:11.480
1 つのエンティティに到達することです。ようにするの1 つのエンドポイントがあるかどうか

00:22:11.530 --> 00:22:13.850
送信、エンドポイント、または受信エンドポイント。

00:22:14.850 --> 00:22:16.820
保留中の操作のいずれかを実行できます。

00:22:17.560 --> 00:22:21.540
1 つだけ呼び出しを送信するか1 つの受信呼び出し。

00:22:22.370 --> 00:22:26.300
ほとんどの時間、操作有効期間をすることはできません以上

00:22:26.350 --> 00:22:30.940
60 秒で、何であれ、負荷バランサーを任意のことができます。

00:22:31.480 --> 00:22:33.060
実行しているプロバイダー。

00:22:34.490 --> 00:22:41.480
これには取り込む先の事例

00:22:41.530 --> 00:22:43.390
複数の端点を説明します。

00:22:44.040 --> 00:22:47.590
方向の時間の多くを購入します。あなたの通信のシナリオ

00:22:47.640 --> 00:22:51.230
キューに送信してサブスクリプションから受信します。

00:22:52.080 --> 00:22:55.730
また、通知を送信するかハブです。すべてのこれらの種類の

00:22:55.780 --> 00:22:57.060
ある場合があります。

00:22:57.640 --> 00:23:01.320
バイナリ プロトコルを使用して実際には1 つの接続を作成できます。

00:23:01.370 --> 00:23:08.270
1 つのバイトを単一のソケットその他のすべてのリンクで、

00:23:08.320 --> 00:23:13.320
AMQP コンテキストは multiflexed へのリンク1 つの HTTP 接続を経由します。

00:23:14.500 --> 00:23:18.740
したがって、多くの利点を取得します。ハンドシェイクを実行する必要がないです。

00:23:18.790 --> 00:23:22.680
そのソケットを確立する必要がないと毎回のもの

00:23:22.730 --> 00:23:26.880
... とエンティティの支払いコストは 1 回とし、再利用します。

00:23:26.930 --> 00:23:29.460
ときに話をします。いくつかのエンティティです。

00:23:30.290 --> 00:23:33.900
そのよう注意してください。あります。ゲートウェイのフィールドを記述する場合

00:23:33.950 --> 00:23:37.240
またはカスタムのゲートウェイ多くのデバイスが置かれこれ

00:23:37.290 --> 00:23:40.690
非常に重要になります。

00:23:43.280 --> 00:23:48.250
その他の部品がプル長です。このためこの定数のことは

00:23:48.300 --> 00:23:51.400
キューでは、右の方法まあは、メッセージ?

00:23:51.450 --> 00:23:55.160
メッセージは?必要がありますかメッセージか。だからここで

00:23:55.210 --> 00:24:01.040
AMQP プロトコルでの接続お維持します。

00:24:01.090 --> 00:24:04.370
任意の操作を実行する必要はありません。以外は、保留中

00:24:04.420 --> 00:24:09.120
受信の設定でしたが、無限のタイムアウトになりました。ことが

00:24:09.170 --> 00:24:12.110
1 日、1 週間の決済です。一般に、決済されません。

00:24:12.160 --> 00:24:16.090
無限大です。何のように設定します。シャット ダウンの特性

00:24:16.140 --> 00:24:19.560
よう、おそらく 20 分またはそのようなものとします。が

00:24:19.610 --> 00:24:24.920
保留中の受信プル長を持つことができます。について心配する必要はありませんし、

00:24:24.970 --> 00:24:27.640
CPU サイクルの量産と

00:24:29.370 --> 00:24:33.080
についてを取得しています。我々 が今後も接続を生きています。

00:24:33.130 --> 00:24:37.040
ping またはロード バランサー機器必要なご連絡と

00:24:37.090 --> 00:24:41.640
低レイテンシの応答します。たびに、メッセージが表示されます。

00:24:42.360 --> 00:24:45.820
これはように別の非常に重要です面での考慮事項

00:24:45.870 --> 00:24:50.380
影響だけでなく、コストのデバイスです。したがってバイナリ プロトコル

00:24:50.430 --> 00:24:53.310
用語の相違を行います。シナリオです。

00:24:56.240 --> 00:24:59.820
プロトコルをその他の考慮事項Sdk では。

00:24:59.870 --> 00:25:03.520
高い生産性を達成します。たいです。ソリッドのコアを使用します。たいです。

00:25:03.570 --> 00:25:08.220
ライブラリを使用するソリッドです。これを本当に選択することができるようにします。

00:25:08.270 --> 00:25:11.010
プロトコルの右右してください。

00:25:12.880 --> 00:25:13.950
したがって、サービス バス

00:25:15.670 --> 00:25:19.750
.NET では、[既定を使用している場合SBMP のプロトコルは既定値です。

00:25:19.800 --> 00:25:24.130
使用目的です。切り替えるにはいつでも AMQP と

00:25:24.180 --> 00:25:25.170
大丈夫ですが。

00:25:25.850 --> 00:25:28.980
いくつかの主要な防御があります。現在のところを閉じています。

00:25:29.030 --> 00:25:33.730
そのギャップの場合に非常に早く。場合は.NET を使用し、SBMP が

00:25:33.780 --> 00:25:36.010
デフォルト シナリオ今日。

00:25:37.560 --> 00:25:42.400
その場合は、HTTP を使用している場合の場合は、私たちがある HTTP ラッパーは多く

00:25:42.450 --> 00:25:46.160
オペレーティング システムが利用可能なのと多くのライブラリを使用します。

00:25:47.010 --> 00:25:50.510
[AMQP を開始していると多くのコミュニティを参照してください。

00:25:50.560 --> 00:25:51.700
ライブラリが考案しました。

00:25:52.940 --> 00:25:59.670
オープン標準が AMQP でした。設計と開発のすべて

00:26:00.690 --> 00:26:05.690
心に留めておいて、効率的で信頼性の高い、データの並べ替えをポータブル

00:26:05.740 --> 00:26:10.310
表現と柔軟性点に注意します。面での柔軟性

00:26:10.360 --> 00:26:13.470
クライアントであるかどうかのライブラリまたはブローカーにクライアント

00:26:13.520 --> 00:26:15.120
ライブラリが違反を破損しているか。

00:26:16.680 --> 00:26:20.260
したがって、AMQP を始めていること移動前方を標準化しています.

00:26:20.310 --> 00:26:26.370
ところで、オアシスの標準的なの AMQP 最後年 10 月。ISO/IEC だけオフにします。

00:26:27.560 --> 00:26:32.950
これでは、インターナショナルの認識標準、すぎます。ようにするの

00:26:33.210 --> 00:26:35.180
押してオフ新鮮です。

00:26:36.990 --> 00:26:41.560
それの意味をします。多数のライブラリが表示されます。

00:26:42.230 --> 00:26:47.750
Apache の Qpid ライブラリの開発または、proton のライブラリ

00:26:47.800 --> 00:26:51.010
いくつかの異なる言語でのクライアントです。

00:26:51.890 --> 00:26:55.240
C、Java の JMS の実装があります。

00:26:56.110 --> 00:27:00.670
PHP です。これらのすべてが使用可能します。コミュニティを使用する

00:27:00.720 --> 00:27:05.970
ライブラリを使用するためのソースのサポートを開きます開発および貢献

00:27:06.020 --> 00:27:06.740
して

00:27:07.970 --> 00:27:12.310
サービスまたはその他のプラスプロバイダーがサポートしているが、

00:27:12.360 --> 00:27:14.070
AMQP ポータルがあります。

00:27:14.820 --> 00:27:18.400
サービス バスにアクセスしようとしている場合別のプロトコルを確認できます。

00:27:18.450 --> 00:27:22.940
多くの何の選択肢があります。Sdk を使用してどのようなライブラリ

00:27:22.990 --> 00:27:34.850
使用してする必要はありません。ある特定の方法で制限されます。

00:27:34.900 --> 00:27:36.150
同期、非同期、バッチではなく。

00:27:37.150 --> 00:27:40.650
理解どのようなプロトコル、微妙だと思います

00:27:40.700 --> 00:27:45.840
場合について話をする必要があります非同期、同期コードを記述します。

00:27:45.890 --> 00:27:49.170
コード、およびコードのバッチは、実際の用語の違い

00:27:49.220 --> 00:27:54.100
パフォーマンスを表示します。異なるこのような場合です。

00:27:55.890 --> 00:27:58.710
スループットが増加明確にバッチ処理します。

00:27:59.460 --> 00:28:04.620
常に、非常に、非常にお勧めであるかどうか

00:28:04.670 --> 00:28:09.260
受信側でまたはであってもバッチ処理を使用すると、送信側。

00:28:09.310 --> 00:28:13.190
負の値だけの人々 の懸念遅延時間がの場合があります。

00:28:13.240 --> 00:28:17.490
思いますどのようにすることができます。ないが多すぎるが影響を受けます。

00:28:17.540 --> 00:28:18.880
についてお話しします。

00:28:21.250 --> 00:28:24.830
非同期一般的には常に、ベスト ・ プラクティスです。常に表示します。

00:28:24.880 --> 00:28:28.620
可能な限りそれを使用します。除くバインドされているようにします。

00:28:28.670 --> 00:28:31.760
見開きの呼び出しの数です。するだけで、緊密にします。

00:28:31.810 --> 00:28:34.720
ループが無限数を呼び出しと思いますか

00:28:34.770 --> 00:28:37.660
サービス バスは、このシナリオに役立ちます。

00:28:40.160 --> 00:28:44.110
最後に見たときに、バイナリと大幅により高いプロトコル

00:28:44.160 --> 00:28:47.980
スループットを達成するためにできることこれらのプロトコルであるためにだけ

00:28:48.030 --> 00:28:54.290
AMQP プロトコルが開発されました。念頭に効率的に

00:28:55.260 --> 00:28:58.750
フロー制御とすべてのことプロトコル層に組み込まれています。

00:28:58.800 --> 00:29:03.950
自体を参照してください、多くの利点表示されません。それでは、実際には

00:29:04.000 --> 00:29:08.550
いくつかの数値を示します。いくつかを実行しています。数値を比較することができますように

00:29:08.600 --> 00:29:10.090
自分のこれら。

00:29:20.030 --> 00:29:24.820
ここではいくつかのコードがあります。メッセージを送信しようとすること。

00:29:26.190 --> 00:29:28.970
分割したことを確認できます。3 つの部分に分割します。

00:29:29.850 --> 00:29:32.930
1 つ目は、同期送信を行っています

00:29:33.690 --> 00:29:38.660
重要な行は次のとおりです。それぞれのメッセージは、qClient と送信

00:29:38.710 --> 00:29:44.060
オフ メッセージ。これは非常に同期呼び出します。完了するには、1 つの重量。

00:29:44.110 --> 00:29:48.030
受信確認を待機します。サーバーから次のように到達します。

00:29:48.080 --> 00:29:51.200
バックアップ クライアントから、完全なループとし、そのに移動します。

00:29:52.910 --> 00:29:56.650
2 つ目は非同期で。

00:29:57.900 --> 00:30:02.780
本質的に作成しています。これらのすべての非同期タスク

00:30:03.350 --> 00:30:04.470
送信操作。

00:30:05.700 --> 00:30:09.150
すべての待機タスクが完了します。

00:30:11.410 --> 00:30:15.170
最後は、バッチ処理送信と発注を呼び出す

00:30:15.220 --> 00:30:19.430
送信バッチ処理と非同期、一般に人を思い付く

00:30:19.480 --> 00:30:22.840
されている場所をシナリオで非同期、順序が失われます。私はそう思いません

00:30:22.890 --> 00:30:25.800
最初に、どの 1 つが起こるか知っています。どちらかが発生します。

00:30:26.300 --> 00:30:29.430
目的は、バッチの送信これは種の優れた

00:30:29.480 --> 00:30:32.300
どちらの場合も保持するのですべての... のいずれかの全体

00:30:32.350 --> 00:30:35.920
バッチが通過または全体バッチが復帰し、

00:30:35.970 --> 00:30:38.910
後のパフォーマンスはどのくらいを参照してください。これが影響します。

00:30:40.310 --> 00:30:45.300
指すこれらのすべてがあるようにサンプル メッセージで、単純な。

00:30:45.350 --> 00:30:47.900
ことができますを参照してください今、キューの数は 0 です。

00:30:48.910 --> 00:30:52.560
私のメッセージの数が設定され少数の 100。

00:30:53.660 --> 00:30:54.780
それでは、これを実行します。

00:30:57.310 --> 00:30:59.530
取得どの程度までを参照してください。

00:31:00.250 --> 00:31:04.670
まずそれが行っていること送信を使用します。同期します。これは、同期を行う

00:31:04.720 --> 00:31:09.020
すべての私のラップトップからの 100 の呼び出し、サービスに戻るようにします。

00:31:09.550 --> 00:31:13.970
約 10 秒間の面ではことです。だけを表示するには

00:31:14.020 --> 00:31:18.360
常に戻って、チェックをおことができます。メッセージの数とする必要があります。

00:31:18.410 --> 00:31:21.860
現在は 100 になります。すべての 100メッセージをここにされています。

00:31:23.160 --> 00:31:26.940
ここでの動作を見てみましょうときに非同期で同じことを行います。

00:31:29.190 --> 00:31:30.590
非同期と同じことです。

00:31:31.940 --> 00:31:36.120
用語の違いメッセージのため

00:31:37.540 --> 00:31:40.460
メッセージのすべてにしましたここでは。200 個のメッセージになっています。

00:31:41.250 --> 00:31:46.450
.3 秒かかりました。すべての人そこで取得するメッセージを指定します。

00:31:50.260 --> 00:31:52.620
バッチをさらに高速です。

00:31:53.370 --> 00:31:54.990
実際にはさらに高速です。

00:31:56.080 --> 00:31:58.880
その理由とサービス バスは、カバーの下

00:31:58.930 --> 00:32:04.440
バイナリ プロトコルを使用している場合のように私たちのメッセージを非同期にします。

00:32:04.490 --> 00:32:09.600
私たちは一緒にそれらを分割する表と暗黙のバッチ処理とを経由して送信します。

00:32:10.260 --> 00:32:13.630
その値の設定を取得します。、どのようなバッチ フラッシュ間隔

00:32:13.680 --> 00:32:17.710
メッセージ ファクトリを設定、ことができますそのウィンドウに設定できます。

00:32:18.310 --> 00:32:21.010
広いウィンドウに設定できます。多くの遅延がわかります

00:32:21.060 --> 00:32:23.690
ただしよく多く表示されます。エンド ・ ツー ・ エンドのスループット。ことができます。

00:32:23.740 --> 00:32:27.310
小さいウィンドウに設定します。より良いレイテンシがわかります

00:32:27.360 --> 00:32:32.110
おそらく少し低いスループット。表示できますが、

00:32:32.160 --> 00:32:36.660
大きさの違い、ここで同期を使用するでは

00:32:36.710 --> 00:32:38.410
バッチと非同期。

00:32:45.080 --> 00:32:49.310
すぐにそれでは、今すぐにここでは、300 のようなメッセージがあります。

00:32:49.360 --> 00:32:51.110
受信側ではどうすれば?

00:33:02.730 --> 00:33:06.700
受信は、注意してくださいここで私はありませんでメッセージ Api を使用します。

00:33:08.710 --> 00:33:12.460
これは、リンゴを表示するためリンゴを比較する

00:33:12.510 --> 00:33:15.560
同期の Api のようになります次に説明して、

00:33:15.610 --> 00:33:18.370
メッセージの API はすべてです。

00:33:20.100 --> 00:33:23.620
これは、同期が表示されます。

00:33:24.300 --> 00:33:28.740
2 つの明確にそれが呼び出すサーバーに行われたので、この

00:33:28.790 --> 00:33:33.600
用語でメッセージを処理します。決して、これまで失われます

00:33:33.650 --> 00:33:38.280
ネットワーク上または転送中のメッセージ呼び出すことがないまで

00:33:38.330 --> 00:33:41.950
送信を完了します。同じメッセージをバックアップするとします。

00:33:43.810 --> 00:33:48.260
次のセクションはここでは、非同期を何が表示しています

00:33:49.430 --> 00:33:56.230
タスクを続行ではまず、完全なそこに。

00:34:01.730 --> 00:34:05.290
もう一度すべての人待ちとタスクが完了する彫刻

00:34:05.340 --> 00:34:07.770
前に行われる私のストップウォッチを呼び出しています。

00:34:09.300 --> 00:34:10.660
最後にバッチがあります。

00:34:11.330 --> 00:34:12.950
バッチは、もう少し面白いです。

00:34:13.890 --> 00:34:19.030
ここでは、簡単ですので私は受信バッチのパスに注意してください、

00:34:19.080 --> 00:34:21.370
メッセージの数それは、100 です。

00:34:22.040 --> 00:34:24.860
バッチを受信を呼び出すようになりました数百わけではありません

00:34:24.910 --> 00:34:28.830
100 個のメッセージを提供します。バックアップを作成します。それは何が

00:34:28.880 --> 00:34:32.660
ベースのネットワーク用に最適です。競争の中のコンシューマー、

00:34:32.710 --> 00:34:35.970
その他のノードの数に基づく表示するメッセージをプルがあります。

00:34:36.020 --> 00:34:38.800
最適なバッチを作成します。送信してください。

00:34:39.610 --> 00:34:43.320
する必要があるを参照してください、外側のループの呼び出しを保持します。

00:34:43.370 --> 00:34:47.620
されるまではないバッチが表示されます。数百メッセージ。たいです。

00:34:47.670 --> 00:34:51.430
するまではこのバッチ処理の計算を行うには100 個のメッセージを実現します。

00:34:53.920 --> 00:34:59.030
ここで、参考までに、のみを保持、ロック トークン。

00:34:59.080 --> 00:35:01.160
すべてのメッセージをしていますです。保持する必要はありません私

00:35:01.210 --> 00:35:04.440
全体のメッセージです。1 回は使用しました。処理は、メッセージ

00:35:04.490 --> 00:35:07.710
中だけがある上に維持ロック トークンと

00:35:07.760 --> 00:35:12.940
すべての完全なバッチ非同期そこでロック トークン。

00:35:14.060 --> 00:35:16.940
バッチごとにこれを行っていますないを待っているが、

00:35:16.990 --> 00:35:19.490
すべての方法にする終了時までください。すべてのメッセージを完了しますか。

00:35:19.500 --> 00:35:21.500
[Indiscernible]

00:35:21.660 --> 00:35:22.750
... .subset であるか。

00:35:23.510 --> 00:35:24.840
>> 残念ですが、何が質問ですか。

00:35:24.890 --> 00:35:28.400
>> 場合、それらの一部を処理する可能性がありますメッセージが完了します。

00:35:28.450 --> 00:35:30.520
テストのサブセットを実施するか。

00:35:30.860 --> 00:35:34.510
>> 絶対にします。絶対に。したがって非同期のバッチを完了します。

00:35:35.250 --> 00:35:39.040
単一ロック トークンは、呼び出すことができます。2 ロック トークンをどのような

00:35:39.090 --> 00:35:42.720
セットです。だけです。これらのすべてのロック トークンを送信します。

00:35:42.770 --> 00:35:46.250
バッチでバックアップを取得しますバッチになります。これは

00:35:46.300 --> 00:35:50.010
待ち時間とを節約すべてのことを行うためには、ラウンドト リップ

00:35:50.060 --> 00:35:52.540
非常に効率的になります。

00:35:54.300 --> 00:35:56.070
それでは何を参照してくださいに追加します。

00:35:58.400 --> 00:36:03.230
ここで、同じ大文字と小文字があます。私は最初の同期を使用しようと

00:36:03.280 --> 00:36:07.440
すべての 100 を受信しようとしてください.最初の 100 メッセージ

00:36:07.490 --> 00:36:11.190
ですね。これは悪くなります注意ここでパフォーマンスのための送信よりも

00:36:11.240 --> 00:36:14.080
2 倍の数の操作を行っています。これを受信します。

00:36:14.130 --> 00:36:16.460
すべてのメッセージでは、すべてのメッセージを完了します。すべてのメッセージが表示されます。

00:36:16.510 --> 00:36:20.110
すべてのメッセージを完了します。とを進みます。その 18 秒です。

00:36:20.160 --> 00:36:24.220
我々 確認していましたが、10 の送信ではなく送信の 18 秒かかる

00:36:24.270 --> 00:36:28.760
これらのメッセージを完了それら。ようなことではありません。

00:36:30.090 --> 00:36:35.330
非同期の一連を行うため並行して、これを表示するダウン

00:36:35.380 --> 00:36:38.880
約 2.8 の秒です。ここでは、これらの数値は.

00:36:39.410 --> 00:36:43.230
割り引いて解釈、好きここでは、ネットワークで実行しています。

00:36:43.940 --> 00:36:47.470
大きさだけで確認できますが、差です。ことができますを参照してください。

00:36:47.520 --> 00:36:49.620
これは、改善の程度。

00:36:50.830 --> 00:36:52.580
ここで何を見てみましょうバッチで発生します。

00:36:55.730 --> 00:37:00.720
戻ってきました。私たちはできるかほとんどの特性

00:37:00.770 --> 00:37:04.590
すべての 100 の 0.1 秒操作が実行される.

00:37:05.410 --> 00:37:07.930
使用しているためにだけバッチには。

00:37:11.380 --> 00:37:16.640
ここでは、だけではなくかこれらすべてここでは、サービスの利点

00:37:16.690 --> 00:37:21.680
バスでは、非常に、非常に簡単にこの特定のコードを記述します。

00:37:21.730 --> 00:37:26.700
示したコードは非常に複雑なが実際に取得します。

00:37:26.750 --> 00:37:29.280
その一歩と私たちさらに容易に行われます。

00:37:30.200 --> 00:37:33.470
ように、だけは、次のようにして.表示するのには、ここで、

00:37:33.520 --> 00:37:37.280
それらの 300 のメッセージの表示メッセージ彼を更新する場合があること

00:37:37.330 --> 00:37:41.920
必要がありますに戻るゼロを示す私は嘘しません。これらのすべての 300

00:37:41.970 --> 00:37:43.380
メッセージを処理します。

00:37:47.270 --> 00:37:54.910
さて。メッセージを見ていきますのでApi では金利

00:37:54.960 --> 00:37:57.880
時間の速度をしてみますここでは、もう少しアップします。

00:38:00.480 --> 00:38:04.820
違いを説明したので、同期、非同期、およびバッチと

00:38:04.870 --> 00:38:10.330
その [Indiscernible] 常に使用するバッチ処理を願っています。スループットは次のことです。

00:38:10.380 --> 00:38:14.100
パーティションのキューおよびトピック。これは SDK 2.2 をリリースしました。

00:38:15.680 --> 00:38:19.590
キューおよびトピックを本質的に分割します。1 つのキューとパーティション

00:38:19.640 --> 00:38:21.830
複数の処理ノード全体にわたることです。

00:38:23.240 --> 00:38:26.950
これだけではなくによってよりスループットの電源

00:38:27.000 --> 00:38:31.900
複数のメッセージを処理することが多くのストレージ容量を提供します。

00:38:32.410 --> 00:38:35.820
こともできます。非常に大規模なキューです。これは

00:38:35.870 --> 00:38:38.170
柔軟にすることです。

00:38:39.270 --> 00:38:42.290
1 つのパーティションが使用できない場合別のパーティションを続けることができます。

00:38:42.340 --> 00:38:43.580
メッセージを処理します。

00:38:44.640 --> 00:38:49.270
したがってパーティション キューによってで、はるかにほとんどのシナリオで提供します。

00:38:49.320 --> 00:38:52.990
かなり良いスループット可用性と障害許容力

00:38:53.040 --> 00:38:58.570
特性を参照してください。ボックス。それは簡単に作成し、

00:38:58.620 --> 00:39:02.700
されているパーティションのキューを使用します。だけを推奨

00:39:02.750 --> 00:39:06.470
これらを常に使用します。常に同じを使用します。これら。次に実際には、

00:39:06.520 --> 00:39:11.000
SDK リリースでは、私たちはトラックを作成するにはその既定値を既定では、

00:39:11.050 --> 00:39:13.380
キューを作成するときに学習パーティション分割されたキューを取得します。

00:39:15.690 --> 00:39:20.650
認識しておくが、撮影するときに何が起こるか

00:39:20.700 --> 00:39:22.590
キュー間でパーティションを分割します。

00:39:24.060 --> 00:39:26.530
セッションを使用していない場合は、よ多くのセッションを話します。

00:39:26.580 --> 00:39:30.340
場合は、詳細に使用していません。セッションし、基本的には、

00:39:31.060 --> 00:39:33.050
必要が.

00:39:34.220 --> 00:39:38.380
注意する必要があるメッセージ順序表示ことがあります。

00:39:38.430 --> 00:39:41.830
ここでは、本質的にするため別のパーティションに移動します。

00:39:41.880 --> 00:39:46.770
パーティションが使用できない場合そのメッセージが表示されます。

00:39:46.820 --> 00:39:47.720
順序。

00:39:48.460 --> 00:39:51.270
これは注意することです。セッションを使用している場合は

00:39:51.320 --> 00:39:54.720
ここでは、についてお話しをし、すべての順序のセマンティクス

00:39:54.770 --> 00:39:56.100
完全に保持されます。

00:39:57.120 --> 00:40:02.330
思いますか。だけを表示します。コードは、ここでは、いつでも

00:40:02.380 --> 00:40:05.590
キューを作成する 1 つのシングルEnablePartitioning のプロパティです。

00:40:05.640 --> 00:40:08.720
現在デフォルトで false に設定されます。次に言ったように

00:40:08.770 --> 00:40:10.040
SDK がある場合は true。

00:40:10.780 --> 00:40:13.750
ように設定してくださいだけです。によって私の方法は、どのようにします。

00:40:13.800 --> 00:40:18.770
人々 は自分の考え方が一般的に実行します。一般的にはコピーではありません。

00:40:18.820 --> 00:40:20.730
コードは PowerPoint でを参照してください。

00:40:21.330 --> 00:40:24.470
ように動作するかどうかは、必要のないです。スタッフ。私は決して、これまでのコピーします。

00:40:24.520 --> 00:40:28.150
に PowerPoint で表示するコード最も単純化したになります

00:40:28.590 --> 00:40:32.710
basic の者がコード配置できます。これで

00:40:32.760 --> 00:40:35.500
場合はいいです。だけを設定します。大丈夫ですので、プロパティです。

00:40:35.550 --> 00:40:38.540
コードを作成するこれまでに示した場合PowerPoint では、コピーしません。

00:40:40.650 --> 00:40:46.660
その接続のスループット。きました拒否されます。前に見た

00:40:46.710 --> 00:40:50.290
バイナリの接続は、実際には、方法本当に重要です。あります。

00:40:50.340 --> 00:40:55.090
送信する可能性があります。非常に広い帯域を使用します。

00:40:55.660 --> 00:40:58.340
考える、バックエンドは、私たちのためキューのメッセージにしようとします。

00:40:58.390 --> 00:41:03.370
大量のログが必要です。プッシュ アップとするようなものです。

00:41:04.400 --> 00:41:08.450
いずれかの時点で詳細を作成します。TCP 接続の物理的な可能性があります。

00:41:08.500 --> 00:41:12.630
実際には良いでしょうしすることができます。簡単に行うこと。各メッセージ

00:41:12.680 --> 00:41:16.220
クラスのインスタンスをファクトリでメッセージ ファクトリのインスタンス

00:41:16.270 --> 00:41:18.390
PCP の 1 つの接続に対応します。

00:41:19.390 --> 00:41:22.550
キューのクライアントの数をそれより作成しているもの

00:41:22.600 --> 00:41:25.680
示したように、同じ工場からしている多重すべて

00:41:25.730 --> 00:41:31.430
同一の TCP ソケットを介して接続します。したがって、複数のメッセージ ファクトリを作成します。

00:41:31.480 --> 00:41:33.700
複数のメッセージを作成する場合工場だけを表示できる以上

00:41:33.750 --> 00:41:38.720
パイプとより多くのデータをプッシュすることができます。ので、重要な考慮事項

00:41:38.770 --> 00:41:42.540
使ってください。接続レベルの復元性を作成されます。ようにしたら

00:41:42.590 --> 00:41:46.140
メッセージ ファクトリを作成します。破棄することにあります。

00:41:46.190 --> 00:41:49.320
場合は、接続を中断しますそれを再構築します。場合は、リンクの解除

00:41:49.370 --> 00:41:52.740
キューに私たちが再構築します。何であれそれは、私たちが再構築されます。

00:41:52.790 --> 00:41:54.860
え、そうすることはありませんこれを行うには.

00:41:55.370 --> 00:41:58.030
このオブジェクトを破棄する必要があります。このオブジェクトを再作成します。

00:41:58.310 --> 00:42:02.780
だけでそれらを作成し、再利用それに比べるとする必要があります。

00:42:05.910 --> 00:42:07.540
セッションに移りましょう。

00:42:08.520 --> 00:42:11.670
得ることを示すしているためすべてこれらの送信者の多く

00:42:11.720 --> 00:42:14.910
送信者のすべてのそれらを多重化し、非常に、非常に小さい数に

00:42:14.960 --> 00:42:17.850
キューのことができます。実際にこれを処理しますか。

00:42:17.900 --> 00:42:21.110
前に見たようなフレームワークでオルレアンすべてであります。

00:42:21.160 --> 00:42:23.460
ストリームをデマルチプレックスします。

00:42:24.720 --> 00:42:26.530
ストリームをデマルチプレックスします。

00:42:28.490 --> 00:42:33.070
セッションは、すばらしいものに組み込まれています。バスのサービスの機能

00:42:33.120 --> 00:42:37.130
基本的にサブキューを作成します。したがって各セッションを考えることができます。

00:42:37.180 --> 00:42:40.290
場合、キューのサブキューで。

00:42:41.480 --> 00:42:44.860
だけで、元の性質セッション ID を設定するには

00:42:44.910 --> 00:42:46.840
1 つの単一のプロパティです。設定するがあります。

00:42:48.090 --> 00:42:51.240
受信機は場所のパラダイムを実際に変更します。

00:42:52.050 --> 00:42:56.090
レシーバーは、今すぐなったが、ね私、次メッセージが表示されます。

00:42:56.140 --> 00:42:59.670
受信機は横になります。セッション。次の私を与える

00:42:59.720 --> 00:43:02.690
サブキューはいくつかのメッセージプロセス内に行くと

00:43:02.740 --> 00:43:06.760
注文の処理に行くいくつかの状態は、保存可能性があります。

00:43:06.810 --> 00:43:10.600
その受信者です。思われる場合何百万ものデバイスについて

00:43:10.650 --> 00:43:13.290
1 つに考えるようになりましたキューでは、することができますこれらのすべて

00:43:13.340 --> 00:43:18.620
サブキューとストアのドルサブキューごとの状態です。非常にこれは、

00:43:18.670 --> 00:43:20.410
その意味で非常に強力です。

00:43:21.050 --> 00:43:24.400
行う作業作業時間固定に設定を設定します。言うことができることを意味します。

00:43:24.450 --> 00:43:29.230
ローカライズするいずれかの受信機デバイス 1 ～ 100 です。したがって、

00:43:29.280 --> 00:43:32.810
移動し、セッション 1 の質問は～ 100 を固定して、

00:43:32.860 --> 00:43:33.440
です。

00:43:35.000 --> 00:43:39.680
当然のことができます保存状態です。説明するように、

00:43:39.730 --> 00:43:43.490
このコードです。基本的には真の場合に、quire セッション

00:43:43.540 --> 00:43:45.270
キューを作成しています。

00:43:45.790 --> 00:43:49.670
送信側では、するだけする必要があります。セッション ID を 1 つのプロパティを設定します。

00:43:50.530 --> 00:43:55.720
次では、受信側、およびすべての同じ種類のパラメーターを適用します。

00:43:55.770 --> 00:43:59.840
承諾メッセージを説明しましたようにセッションに同意することができます

00:43:59.890 --> 00:44:03.730
メッセージのセッション ID を持つようになりましたかどのようなだけでをリリースしました

00:44:03.780 --> 00:44:08.760
非常に簡単な方法行うにはできます。

00:44:11.810 --> 00:44:13.010
セッションの受信機。

00:44:14.920 --> 00:44:18.080
したがって、送信者セッションを開きます。

00:44:18.970 --> 00:44:21.810
そのバッチ処理を実現してすでに送信するのに最適な方法です。

00:44:21.860 --> 00:44:25.740
すべての送信者が行っています。ID、各セッションに対しては

00:44:25.790 --> 00:44:30.240
多くのメッセージとして送信する、セッション ID 1 を加えたものです。ある場合

00:44:30.290 --> 00:44:33.480
1 つは、セッション ID を送信するつもり2 つのメッセージ。セッションである場合

00:44:33.530 --> 00:44:36.070
2 つの ID を送信するか3 つのメッセージとなど。

00:44:37.350 --> 00:44:38.920
また、送信者だけで始めます。

00:44:39.880 --> 00:44:43.910
ここでは、このキューを確認する場合[メッセージ キューのサンプル

00:44:44.580 --> 00:44:49.140
このキューを作成したときに、1 つだけプロパティの追加設定するには

00:44:49.190 --> 00:44:55.090
これは、セッションのプロパティを必要とします。それが唯一の違いです。

00:44:55.670 --> 00:44:59.940
ここで行った場合に、この特定キューをしてを参照してください。

00:44:59.990 --> 00:45:02.440
説明のプロパティ

00:45:08.230 --> 00:45:09.410
参照してください.

00:45:11.710 --> 00:45:16.480
セッションのプロパティは、必要があります。false。これは、です。

00:45:16.530 --> 00:45:20.780
さて。このキューを削除してみます。

00:45:24.670 --> 00:45:34.390
メッセージ セッションのサンプルを作成します。

00:45:37.280 --> 00:45:38.780
セッションが必要です。

00:45:45.040 --> 00:45:47.020
[送信者に開封しようとしています。

00:45:51.490 --> 00:45:53.840
したがってメッセージの送信が開始されます。

00:46:09.430 --> 00:46:18.880
検索できないと思います。キュー名の今すぐです。

00:46:18.890 --> 00:46:20.800
[Indiscernible]

00:46:20.870 --> 00:46:27.580
>> ああ、でしたが。メッセージ セッションをしています.ああ、これで完了です。

00:46:29.640 --> 00:46:36.750
完璧です。それでは、それを変更します。メッセージ セッションのサンプルです。

00:46:39.450 --> 00:46:40.630
非常に多く、ありがとうございます。

00:46:42.100 --> 00:46:43.360
今すぐこの guy を実行してみましょう。

00:46:46.770 --> 00:46:49.710
簡単ですね。すべての人に送信すると呼ばれます。メッセージです。ここでお見せしましょう

00:46:49.760 --> 00:46:54.350
受信コードします。これのようになります。

00:46:55.510 --> 00:46:59.710
これは、新しい API を我々 がリリースした、上

00:46:59.760 --> 00:47:02.010
メッセージ処理の API です。

00:47:03.430 --> 00:47:07.500
それには、Azure ワーカーの役割これも変更しましょう。

00:47:10.890 --> 00:47:14.690
Azure ワーカーの役割で、start メソッドの場合と

00:47:14.740 --> 00:47:19.540
キューが存在するかどうか確認、同じqClient を作成するとします。

00:47:20.250 --> 00:47:24.120
ルールを実行するに注意してください、コードをさらに簡単に取得します。

00:47:25.610 --> 00:47:29.270
これを行う1 つの呼び出しを登録します。

00:47:29.900 --> 00:47:32.770
言って、セッションのハンドラーを登録します。

00:47:33.670 --> 00:47:36.500
されています。なし deceiveループを記述します。

00:47:37.120 --> 00:47:38.950
管理するには、有効期間がありません。

00:47:39.580 --> 00:47:43.920
すべてのことがで処理します。クライアント ライブラリです。

00:47:43.970 --> 00:47:48.540
すべてカプセル化するだけであります。どのように行うのロジック

00:47:48.590 --> 00:47:53.790
その 1 つ 1 つのストリームを処理するにはクラスと呼ばれる、私のセッションのハンドラー。

00:47:54.700 --> 00:47:57.450
このクラスを見てみましょう私はここで何を参照してください。

00:47:58.700 --> 00:48:02.660
行う場合に、まず実際にはメッセージが表示されるでしょうか。

00:48:05.430 --> 00:48:09.430
アウトを印刷メッセージ、単メッセージが表示されると

00:48:09.480 --> 00:48:10.870
私は私が増えています。

00:48:11.610 --> 00:48:15.320
このクラスで行うだけです。カウントは、プライベート メンバーです。

00:48:15.370 --> 00:48:19.860
ここではその値を保存したとします。

00:48:21.090 --> 00:48:22.960
設定数

00:48:24.710 --> 00:48:28.550
0 し、カウントしてくださいここ私のすべての処理であるためにです。

00:48:29.270 --> 00:48:34.550
クローズされたセッションでのセッションを終了します.あるときに呼び出されますなし

00:48:34.600 --> 00:48:38.750
多くのメッセージが利用可能セッションであるか、またはに達しました

00:48:38.800 --> 00:48:42.360
通貨の最大数。お話ししましたどのように多くの同時に

00:48:42.410 --> 00:48:43.630
所有します。

00:48:44.260 --> 00:48:48.230
最大値に達した場合どのように多くの同時実行の数

00:48:48.280 --> 00:48:53.040
セッションを処理すると、ここでは呼ぶそのセッションを閉じてを開きます

00:48:53.090 --> 00:48:57.610
どのようなメッセージによって新しいセッション使用できます。これを閉じる

00:48:57.660 --> 00:49:00.700
チャンスを私にしたことを言うした一連のメッセージを受けて、

00:49:00.750 --> 00:49:03.900
この特定の処理をします。セッションとはする必要があります。

00:49:03.950 --> 00:49:05.580
状態を保存します。

00:49:07.140 --> 00:49:10.730
ここではすべて表示しています状態の設定と取得を呼び出すこと

00:49:10.780 --> 00:49:15.250
オブジェクションのセッションの上にある状態です。これらは本質的にはストリームです。

00:49:16.050 --> 00:49:20.770
すぐ、カウント値を保存してたびに、セッションが終了します。

00:49:21.780 --> 00:49:26.130
エラーは、最後の 1 つセッションが切断された場合のケースです。

00:49:27.420 --> 00:49:31.050
今すぐ覚えて、こと理由これらのすべてのメッセージを相関付けます

00:49:31.100 --> 00:49:34.310
セッションをロックするにはします。行うものであることを確認

00:49:34.360 --> 00:49:38.790
人はのみ受信機メッセージをサブキューには、

00:49:38.840 --> 00:49:40.510
その subsession。

00:49:41.190 --> 00:49:43.780
常にロックが失われることができます。ロックが失われる

00:49:43.830 --> 00:49:47.660
サーバー上での障害。これは、可能性があります。接続のために失われる

00:49:47.710 --> 00:49:51.410
問題または多分プロセッサだけでハングしているし、ロックを紛失

00:49:51.460 --> 00:49:55.290
それし、操作を行うため常に表示することができますので、そこに

00:49:55.340 --> 00:49:58.940
このエラーと呼ばれます。この場合は、破棄するにはすべて、

00:49:58.990 --> 00:50:03.500
ローカルの設定の変更と移動します。であります。

00:50:04.870 --> 00:50:07.150
それでは、これは参照してください。

00:50:07.670 --> 00:50:08.790
実際に実行しています。

00:50:10.210 --> 00:50:10.800
質問がありますか。

00:50:10.850 --> 00:50:11.930
>> は同じ？

00:50:13.740 --> 00:50:17.500
>> などの質問の: これは、サブスクリプションと同じですか。100%。

00:50:17.550 --> 00:50:21.170
完全に対称であります。かどうかキューから受信しています。

00:50:21.220 --> 00:50:24.130
またはサブスクリプションから受信しています。

00:50:25.440 --> 00:50:28.920
これが私のワーカー ロールようになりました。Letどのような実際には、すばやくチェックします。

00:50:28.970 --> 00:50:30.850
検索、キューの数後に、

00:50:32.060 --> 00:50:36.390
役割を行った送信します。ように見える3,700 のメッセージが取得右

00:50:36.440 --> 00:50:40.610
ここでは、33、検索処理のと同様にを開始がします。

00:50:41.650 --> 00:50:56.690
そこにジャンプしましょう.私たちが移動します。それはに聞こえます。

00:50:56.740 --> 00:51:03.350
良い。右ここで、私のコンピューターは、使用して、

00:51:03.400 --> 00:51:06.090
何千もの処理を確認できます。数千のメッセージです。

00:51:06.890 --> 00:51:10.740
私が記述したコードが非常に、非常に単純な思考

00:51:10.790 --> 00:51:15.170
だけで、単純なセッションでは、1 つの方法セッションとはしていません。

00:51:15.220 --> 00:51:18.800
ループを書くと 1 つの受信します。だけパイプのハンドラーを登録する必要があります。

00:51:19.200 --> 00:51:23.370
示したが、ハンドラーが単純なケースをします。

00:51:23.420 --> 00:51:28.420
この作成のインスタンスを持つことができ、初期化を行っていないしています。

00:51:28.450 --> 00:51:32.020
バックアップを作成するファクトリがあります。利用可能なもです。行うことができます。

00:51:32.070 --> 00:51:36.960
登録ハンドラー ファクトリとします。作成を制御する方法

00:51:37.010 --> 00:51:38.700
その意味も。

00:51:40.370 --> 00:51:43.560
ここでは、表示できますが、永続化セッションの状態と閉じた。

00:51:44.420 --> 00:51:48.340
ズームここの人々 は自分で明らかに、ここで起こって参照してください。

00:51:49.070 --> 00:51:54.740
すべてのセッションを表示する場合は、セッション22 21 のセッションの状態です。

00:51:54.790 --> 00:51:57.810
セッション状態が 46セッション 45。

00:51:58.620 --> 00:52:03.770
そのクラスのメッセージのみを取得するためそのセッションが属しています。

00:52:04.200 --> 00:52:08.320
すべての demuxing と多重されました。簡単なすべてのものが処理されたと

00:52:08.370 --> 00:52:12.410
サービス バスです。そのときに多重化を考慮します。

00:52:12.460 --> 00:52:15.990
送信者に数が多いキューの数が少ないこと

00:52:16.040 --> 00:52:19.260
な単純さが失われない処理することができないの

00:52:19.310 --> 00:52:23.800
使用して、バック エンドでこれらの個々 のストリーム

00:52:30.570 --> 00:52:34.260
ですね。

00:52:37.740 --> 00:52:41.000
セッションの状態についてお話ししました。相関関係のセッションを使用します。

00:52:41.350 --> 00:52:46.020
これだけ要約すると、実際には私たちには、要約する前に次のようにアクセスします。

00:52:46.590 --> 00:52:49.230
もう 1 つ重要な考慮事項はある場合この非常に、非常に

00:52:49.280 --> 00:52:52.530
送信者の多くは、何が、認証モデルですか。セキュリティとは

00:52:52.580 --> 00:52:55.750
モデル化を使用するつもりですか。これと、私は共有アクセス

00:52:55.800 --> 00:52:58.420
署名は、認証モデルをお勧めします。

00:52:59.010 --> 00:53:02.150
多くの詳細があります。実際にはデッキの詳細についてをは

00:53:02.200 --> 00:53:08.190
共有アクセス署名を設定する方法を指定します。ポータルにアクセスすることができます。

00:53:08.540 --> 00:53:10.040
キューを管理します。

00:53:10.910 --> 00:53:15.270
ここでは、IOT のキューにある必要があります。guys は、web サイトから使用しています。

00:53:16.050 --> 00:53:18.850
だけここにし、構成できます。

00:53:19.420 --> 00:53:23.650
そうだ、私に注意してください.

00:53:23.660 --> 00:53:23.720
[Indiscernible]

00:53:23.700 --> 00:53:25.290
>> 申し訳ありませんので。私は残念だった。

00:53:28.330 --> 00:53:33.790
Azure ポータルにジャンプしたので[IOT のキューを選択します。

00:53:34.890 --> 00:53:38.340
この構成に行くとき共有] タブの [表示します。

00:53:38.390 --> 00:53:42.420
ポリシーの名前にアクセスします。これでその web サイトの例はあります。

00:53:42.470 --> 00:53:45.240
このレッスンで、受信では、呼び出されるとは実際にはこれ

00:53:45.290 --> 00:53:49.650
失敗のため、ここだけこの承認が送信します。

00:53:50.890 --> 00:53:54.310
しかし、簡単にして聞くの追加そのルールを承認します。

00:53:55.730 --> 00:53:56.440
保存をクリックします。

00:53:57.340 --> 00:53:58.640
キューを更新するという。

00:53:59.190 --> 00:54:00.050
ここで

00:54:01.700 --> 00:54:06.780
この生成されたトークンルールが可能

00:54:06.830 --> 00:54:11.480
送信し、受信の両方。ここで私はここにしをクリックしてが表示されます。

00:54:12.880 --> 00:54:15.660
まあ、簡単ですね。人々 のように見えるメッセージを送信していた。

00:54:15.710 --> 00:54:18.320
これで、チャット セッションに進みます皆さんがタッチで保持できます。

00:54:18.370 --> 00:54:20.210
相互オンライン。

00:54:21.490 --> 00:54:24.220
その共有アクセス署名は非常に、非常に軽量で、非常には、

00:54:24.270 --> 00:54:28.290
モデルを使用して簡単です。必要がある場合SDS の種類のモデルにジャンプします。

00:54:28.340 --> 00:54:35.540
ACS は完全にサポートされます。ACS はそれでも、適切なオプションがあります。

00:54:35.590 --> 00:54:37.660
キューを使用しました。

00:54:39.580 --> 00:54:43.390
要約は、プロトコルが見られました。関連する理由です。

00:54:43.650 --> 00:54:47.970
ストリームの相関処理を行ってください。必要がない理由を

00:54:48.020 --> 00:54:50.860
デバイスごとにキューを作成します。管理したくないです。

00:54:50.910 --> 00:54:53.980
100万のキューです。そうしないとはするコードを記述します。

00:54:54.030 --> 00:54:57.760
非常に複雑になりすぎないようにするには。したがってこれらの両方は、非常に、非常に

00:54:57.810 --> 00:55:00.840
簡単にサービスとサポートバスのメッセージングします。

00:55:01.900 --> 00:55:05.320
キュー、トピック、サブスクリプション。すべてのこれらの対称。

00:55:05.370 --> 00:55:08.990
すべての用語で示しましたキューの動作

00:55:09.040 --> 00:55:12.280
セッションは、まったく同じ方法を動作します。トピックとサブスクリプション

00:55:12.330 --> 00:55:16.290
フィルターします。サブスクリプションを作成するときに必要とします。

00:55:16.340 --> 00:55:18.360
セッションに等しいかどうかを true にします。

00:55:21.680 --> 00:55:22.910
受信機に対応します。

00:55:27.210 --> 00:55:30.850
Visual Studio がこのチャレンジトンを起動することができます。

00:55:30.900 --> 00:55:34.520
IDE でのインスタンスし移動し、変更する可能性があります、

00:55:34.570 --> 00:55:37.840
それらの 1 つのプロファイルすべてのそれらを同期します。

00:55:38.640 --> 00:55:41.980
できる移動通信これらのすべてのインスタンス。

00:55:42.490 --> 00:55:45.600
これらは動的なインスタンスとすぎるため、VS の数

00:55:45.650 --> 00:55:49.910
起動したインスタンスは異なります週の曜日によって異なります。

00:55:49.960 --> 00:55:53.530
統計情報が実際にあります。あることを示す、ところで。

00:55:53.580 --> 00:55:57.170
ユーザーは、水曜日に方法の複数のインスタンスを開く金曜日に開いています。

00:55:57.220 --> 00:56:04.740
その生産性は金曜日まで tanking します。とにかくこれは、問題をもう一度

00:56:04.790 --> 00:56:07.440
トピックを解決をします。何百万と何百万もがあります。

00:56:07.490 --> 00:56:11.110
最後のポイント。すべての場合自分のいずれかを聞くこと

00:56:11.160 --> 00:56:14.070
メッセージのサブスクリプションが 1 つです。

00:56:15.150 --> 00:56:19.140
これらのメッセージが生成されるかどうかのバックエンドをベースします。

00:56:19.190 --> 00:56:22.840
システム内のいくつかの変更をまたは送信するような

00:56:22.890 --> 00:56:26.270
ユーザーへの通知をします。Windows に通知するには

00:56:26.320 --> 00:56:30.510
7 のボックスがあるなしの通知サービスです。通知します。

00:56:30.560 --> 00:56:34.520
それらと言ってこんにちは、新しい更新プログラムがあります。Visual Studio で利用できます。

00:56:34.570 --> 00:56:39.970
ダウンロードを参照してください。さらに重要なのか低レイテンシの並べ替えを与える

00:56:40.020 --> 00:56:43.890
変更を加える場合は、パイプの場所もう 1 つの VS インスタンスに

00:56:43.940 --> 00:56:45.430
インスタンスと同期します。

00:56:46.140 --> 00:56:48.340
トピック sues することができ、購読します。

00:56:49.760 --> 00:56:52.470
概念的にはそれのかトピックあたりの VS ユーザー。

00:56:53.200 --> 00:56:58.800
サブスクリプションごとの VS インスタンスがあります。MQP を使用して接続されている常に。

00:56:58.850 --> 00:57:03.260
MQP は、多くの接続のため効率性のあります。

00:57:03.310 --> 00:57:07.830
私たちの何百万と何百万も非常には、セクションの同時実行

00:57:07.880 --> 00:57:12.350
待っているだけで、非常に低いオーバーヘッド臨時の通知します。

00:57:12.380 --> 00:57:14.840
通知に関する違いです。偶発的なのです。

00:57:14.890 --> 00:57:18.080
性質を持つ。人々 がどのくらいの頻度はそのプロファイルの色を変更しますか。

00:57:19.770 --> 00:57:20.260
1 日か。

00:57:20.310 --> 00:57:22.960
週か。うまくいけばしない毎日。

00:57:23.790 --> 00:57:25.160
私は、ユーザーの気持ちに依存します。

00:57:26.260 --> 00:57:29.100
しかし、非常に多くの場合、発生しません。どのくらいの頻度がある更新プログラム

00:57:29.150 --> 00:57:33.660
プッシュですか。非常によくないです。しかしこの BNS の種があります。

00:57:33.710 --> 00:57:38.290
インフラストラクチャの使用接続先が

00:57:38.340 --> 00:57:41.780
その通知を待ってください。ときに通知します。

00:57:41.830 --> 00:57:45.170
たいインスタント。右クリックします。

00:57:45.220 --> 00:57:46.040
ありますし。

00:57:51.000 --> 00:57:54.990
ここで実際に考慮する必要があります。について考える必要があります。

00:57:55.040 --> 00:57:59.320
メッセージ フローします。今日トピックできます 2000年まで

00:57:59.370 --> 00:58:03.170
サブスクリプションと考えています。数にスケールの

00:58:03.220 --> 00:58:07.420
レシーバーの 2000年十分でしょうまたは 2000年できない場合があります。

00:58:07.980 --> 00:58:10.910
Visual Studio は、について考えた場合1 人のユーザーが複数

00:58:10.960 --> 00:58:13.700
2000 の各インスタンスのよりIDE を実行するには

00:58:16.030 --> 00:58:20.210
不可能です。多分にわからない起こらないことです。

00:58:20.520 --> 00:58:24.520
トピックあたりの VS ユーザーであることすることがあります。

00:58:24.570 --> 00:58:27.660
だれもがリッスンしていることがあります。同じのフィード。します。

00:58:27.710 --> 00:58:30.790
送信できるすべてのユーザーに送信してください.単一のメッセージを送信します。

00:58:30.840 --> 00:58:34.790
すべてのユーザーの広範なキャスト。そうしトピックをチェインするとします。

00:58:35.250 --> 00:58:38.680
転送自動を使用しています。

00:58:39.850 --> 00:58:43.350
大量にジャンプしませんこれらのパターンの詳細での

00:58:43.400 --> 00:58:45.280
フィルターを設定する方法の条件です。

00:58:45.800 --> 00:58:48.520
これらはすべて MSDN.com にサンプリングを行います。

00:58:49.130 --> 00:58:55.380
この特定のサンプルが呼び出されます。リストです。呼ばれるサンプルがあります。

00:58:55.430 --> 00:58:58.720
発行購読します。完全なコードこれらを使用できます。

00:58:58.770 --> 00:59:02.570
本当に皆さんにするためにはお勧めファイルの場所、これらのトピックで

00:59:02.620 --> 00:59:06.190
本当にこれらの豊富なを決済できます。フローの場所は、すべてのメッセージ

00:59:06.240 --> 00:59:09.930
すべてにルーティングする必要はありません。200万人、し

00:59:09.980 --> 00:59:14.280
たびに破棄されます。できます。多くの人にルーティングされます。

00:59:14.330 --> 00:59:18.680
人、または、無限のようなケースであるアドレスを記述します。

00:59:18.730 --> 00:59:19.660
電子メール。

00:59:20.190 --> 00:59:23.130
ここでは言ってのようにメッセージを最初に読み上げる

00:59:23.180 --> 00:59:24.230
コンマで区切られた 2 番目。

00:59:25.130 --> 00:59:27.850
2 つのデバイスへの対応です。最初のデバイスと 2 番目

00:59:27.900 --> 00:59:30.770
デバイス、または 2 つの購読最初と 2 番目の。

00:59:30.820 --> 00:59:35.390
規則の設定を持っているためにのように2 番目のようにします。

00:59:36.390 --> 00:59:40.470
本当にこれは、次のファイルの場所します。pub のサブ (indiscernible)

00:59:42.610 --> 00:59:47.050
自動転送します。非常に、非常に簡単使用します。本質的に作成します。

00:59:47.100 --> 00:59:52.150
キューの最初の目的地と次に、送信元のキューを

00:59:52.200 --> 00:59:55.970
1 つのプロパティを追加します。単一のプロパティソースと呼ばれます。補、

00:59:57.220 --> 01:00:00.600
送信先キューへのとこれは。すべてのメッセージを受信

01:00:00.650 --> 01:00:03.280
元のキューに入る送信先のキューです。

01:00:03.330 --> 01:00:10.030
ソースはサブスクリプションをすることができ、キューです。監査のトピックにすることができます。

01:00:10.080 --> 01:00:10.960
キューです。

01:00:13.190 --> 01:00:16.800
完全に対称の多くを設定、フォントには申し訳ありませんが

01:00:16.850 --> 01:00:18.810
参照してください。

01:00:19.400 --> 01:00:22.540
一時的な場合がある場合にサブスクリプションがあること

01:00:22.590 --> 01:00:23.390
なくなる

01:00:24.660 --> 01:00:28.430
自動削除を使用するには、アイドル状態にします。したがってこれも非常に便利な機能です。

01:00:28.480 --> 01:00:32.570
多数の管理しましょう一時的に接続します。実際には

01:00:32.620 --> 01:00:35.640
1 つのキーのシナリオでは、これはSignalR が使用されていると

01:00:35.690 --> 01:00:38.590
ソケット I/O です。非常には、本質的に、非常に一時的なものです。

01:00:38.640 --> 01:00:40.200
接続は、接続します。

01:00:41.380 --> 01:00:43.700
削除ノードの負荷が追加された.

01:00:44.600 --> 01:00:48.680
バックアップ サービス バスを使用するように再生は基本的にそこ

01:00:48.730 --> 01:00:52.540
ノードごとに、サブスクリプションを作成するたびに新しいサブスクリプションは、

01:00:52.590 --> 01:00:56.160
新しい接続ではなくを立ち上がる新しいノードが、時に、

01:00:56.210 --> 01:00:57.260
サーバーを追加します。

01:00:58.320 --> 01:01:03.210
使用して、トピックおよびサブスクリプションと、背面にパイプとして

01:01:03.260 --> 01:01:05.970
ノード間のメッセージの転送より広い範囲を取得します。

01:01:07.010 --> 01:01:10.090
ときにノードがなくなるとサブスクリプションの期限が切れたもの

01:01:10.140 --> 01:01:17.490
メッセージはあるなった。両方これらのコードは、開いているコードです。

01:01:17.540 --> 01:01:20.240
両方ともする場合スケール アウト、信号、またはソケット

01:01:20.290 --> 01:01:24.720
I/O、耐久性のあるメッセージングが必要なため最後に、サービスのパイプ

01:01:24.770 --> 01:01:27.980
バスが実装これらの両方。

01:01:29.920 --> 01:01:33.050
でした説明します少し構築に関する可用性の話をしましょう

01:01:33.100 --> 01:01:36.780
簡単に説明します。私は知っています。私たちはほとんど時間の経過とともに

01:01:38.830 --> 01:01:42.440
コードは、弾力性のある操作をする必要があります。接続されているだけでなく障害

01:01:42.490 --> 01:01:43.470
問題です。

01:01:43.990 --> 01:01:46.750
だから言ったでしょう」と同様に、配信不能キュー本当に役立ちます。これらのヘルプ

01:01:46.800 --> 01:01:50.790
平準化すると、アプリケーションでの場所メッセージの decivilization または

01:01:50.840 --> 01:01:51.830
何かが失敗する可能性があります。

01:01:52.980 --> 01:01:57.440
サービス バスをスローするすべてのメッセージ一時的なプロパティを持つ

01:01:57.490 --> 01:01:58.020
そこに

01:01:59.480 --> 01:02:02.780
明確かつ簡単にできるようになります知っているかどうかを

01:02:02.830 --> 01:02:04.350
かどうか、再試行する必要があります。

01:02:05.090 --> 01:02:08.560
既定では、実際には自動的に再試行します。説明しましたので、

01:02:08.610 --> 01:02:12.090
タイムアウトに関する基本的操作タイム アウト。既定では

01:02:12.140 --> 01:02:15.190
操作のタイムアウト設定します。場合は、60 秒を

01:02:15.240 --> 01:02:19.720
send 呼び出しを 1 回、それが失敗します。後にもう一度、みましょう

01:02:19.770 --> 01:02:22.980
3 秒です。2 回ファイル可能性があります。よ10 秒後にもう一度試してください。

01:02:23.030 --> 01:02:27.840
私たちは 60 秒を指定することでその呼び出しが成功するようにしようとしてください。

01:02:27.890 --> 01:02:29.740
いない場合は、おこれをするには。

01:02:31.320 --> 01:02:33.650
いくつかの他の場所がある場合それは罰金を保持します。

01:02:33.700 --> 01:02:36.920
それ以外の場合一時的なものとして確認し、再度送信すると思います。

01:02:38.160 --> 01:02:42.430
パーティションのキューおよびトピックが大幅に可用性が向上します。

01:02:43.080 --> 01:02:48.230
桁違いの改善。したがって強く、強くお勧めを使用します。

01:02:48.280 --> 01:02:49.710
この機能では。

01:02:51.830 --> 01:02:55.280
既定のポリシーを再試行します。オフにして、してください。

01:02:57.200 --> 01:02:59.970
ペアの名前空間。最後今日に関する説明です。

01:03:00.490 --> 01:03:03.540
名前空間、サービス バスを使用している場合メッセージがうまく流れています

01:03:03.590 --> 01:03:08.210
使用し、全体のデータをセンターは caput または少なくとも

01:03:08.260 --> 01:03:13.570
全体の名前空間は、caput。無効な名前空間が作成されます。

01:03:13.620 --> 01:03:15.790
名前空間のバックアップします。作成します。名前空間のバックアップします。

01:03:15.840 --> 01:03:19.190
我々 と我々 を提供するだけでしょうメッセージの格納を開始します。

01:03:19.240 --> 01:03:23.440
名前空間のバックアップします。どのように移動に失敗したメッセージ

01:03:24.140 --> 01:03:25.350
背面に移動されます。

01:03:26.210 --> 01:03:29.450
いくつかの時点でメッセージが開始されます。通過します。システム

01:03:29.500 --> 01:03:30.340
返されます。

01:03:31.350 --> 01:03:35.150
この時点では、siphonこれらのメッセージになります。

01:03:35.200 --> 01:03:39.110
転送キューと reenqueue元のキューにしています。

01:03:40.650 --> 01:03:43.590
すべての送信者のコードは、このように変化がない、受信機

01:03:43.640 --> 01:03:46.370
コードは変更されません。送信者は、受信側の場合に

01:03:46.420 --> 01:03:48.470
常にサービスに話すバスの名前空間。

01:03:49.240 --> 01:03:54.700
内部を作成しています転送キューは、移動します。

01:03:54.750 --> 01:03:57.870
メッセージをプルしがあります。それらバックアップします。

01:03:58.720 --> 01:04:03.160
これは、唯一変更する必要のあるコードです。

01:04:03.740 --> 01:04:06.070
これは必要なだけの作業ではありません。す。についてお話しします

01:04:06.120 --> 01:04:08.520
考慮事項は、これには、のみのコードする必要があります。

01:04:08.570 --> 01:04:13.330
変更を作成するときに工場では、

01:04:13.380 --> 01:04:17.690
時間に送信を実行して、コードが表示されます。クラスを組み合わせて名前

01:04:17.740 --> 01:04:21.230
スペースとまあ秒があります。工場出荷時、2 番目の名前空間

01:04:21.280 --> 01:04:24.130
目的のマネージャー対応します。

01:04:24.660 --> 01:04:28.600
他のすべては、クライアント側では。センダーの変更はありません。

01:04:28.650 --> 01:04:31.470
受信機の変更はありません。コード同じままです。

01:04:36.210 --> 01:04:41.520
ここでは、送信者の使用はサポートされます。図で説明したように

01:04:41.570 --> 01:04:44.590
受信機はメッセージを取得できません。元の名前まで

01:04:44.640 --> 01:04:45.760
領域は戻った。

01:04:46.330 --> 01:04:49.340
このような送信の可用性より多く。ここでは

01:04:49.390 --> 01:04:54.000
呼び出してその可用性オプションを送信します。順序付けが失われるため

01:04:54.050 --> 01:04:57.910
転送中のメッセージキューは表示されません。

01:04:58.630 --> 01:05:02.360
エンド ・ ツー ・ エンドの遅延を受信し、当然高くなります。

01:05:02.410 --> 01:05:06.420
そこでいくつかの考慮事項があります。本当と考えているが

01:05:06.470 --> 01:05:10.730
ようにする、重要なシナリオ災害復旧の種類

01:05:12.070 --> 01:05:14.770
これまでのシナリオです。

01:05:15.810 --> 01:05:18.710
アウト、我々 をただ見た Azureサービス バスが本当に拡張可能

01:05:18.760 --> 01:05:21.870
すべてのディメンション。送信者の多くは。大量のスループット。

01:05:21.920 --> 01:05:23.080
多数の受信機。

01:05:23.730 --> 01:05:27.420
信頼性を向上させることができ、アウトの新機能を使用します。

01:05:27.470 --> 01:05:31.950
パーティションのキューのようなボックスの名前空間のペア、または

01:05:32.000 --> 01:05:37.320
ようなパターンを使用して、コードの作成非同期バッチおよび機能。

01:05:38.100 --> 01:05:41.750
リンクのトン。リソースのトン。すべてのことへのアクセスがあります。

01:05:41.800 --> 01:05:44.130
非常に多く、ありがとうございます。私は申し訳ありません。ものです。