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
特別是我已經撰寫好，過去三個加上年份

00:00:58.990 --> 00:01:05.100
在建置仲介的訊息項目。這是佇列因此

00:01:05.150 --> 00:01:08.720
主題，是酒吧 sub該片段。

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
這樣的 SDK 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 現在它可以讓許多瀏覽器和網站更容易

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
傳送的訊息的側邊效能計數器每秒的第二個字母

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
最後，ForwardTo 和deadletter 佇列。

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
在中某處 de 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
將主要佇列deadletter 佇列。

00:07:03.870 --> 00:07:07.930
因此這實際上可以幫助您的應用程式預設情況下有彈性

00:07:08.190 --> 00:07:12.840
您不必撰寫單一這一行程式碼，並保護

00:07:12.890 --> 00:07:18.660
您的後端伺服器。這樣的 ForwardTo是頻道的能力

00:07:18.710 --> 00:07:23.810
郵件會自動建立豐富訊息流程，現在您

00:07:23.860 --> 00:07:30.000
可以讓應用程式可能會有6，8，10 個佇列及 ForwardTo

00:07:30.050 --> 00:07:34.450
將所有 deadletter 佇列這表示單一佇列

00:07:34.500 --> 00:07:38.530
現在您可以在其中有一個要現在的位置接收所有污染的訊息

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
要在這裡看到的一件事提供服務下一行，第一個

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
排序的定域機組發行的此頻率每隔三個月一次您

00:08:51.650 --> 00:08:55.290
可以看到每三到四個月一次前提上放開滑鼠

00:08:55.340 --> 00:08:59.520
一年的至少一次是我們試著以維護，然後使兩者

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 Server 版本因此在大多數情況它們然後再試

00:09:46.950 --> 00:09:51.580
若要如此對齊與伺服器版本我們會得到最大的平台

00:09:51.630 --> 00:09:55.010
讓我們確定我們有中獲益最大與最新的伺服器

00:09:55.060 --> 00:09:59.310
叢集與最新的管理defaces，並與所有元件。

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
telemetry，使用者的動作。

00:10:26.630 --> 00:10:31.030
和產生事件系統而且 B 到 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
能夠以幾個的郵件主題或一個主題，並發送

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
也提供您的發行端點 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
資料流，太。商業情報或許處理倉儲，您不想要使用

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 資料倉儲，您可以產生您艦隊

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
它可能不要將其中一個。不會下列其中一個

00:14:03.870 --> 00:14:07.660
主題的所有項目。這可能是不會將 n 的數目可以讓

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
針對某個訂閱，則為 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
因此所有的三個已實際上則為 true篩選器，但一個訂閱

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
我會掩護網站設定。您們可以叫用它太如果您有

00:16:21.600 --> 00:16:25.950
裝置或其他項目。被呼叫附註檔案使用者執行 Azure

00:16:26.000 --> 00:16:28.260
.NET 的網站。

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
您為這網站的程式碼。

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
放入張貼，做為傳送的案例中，抱歉，就傳送案例而言。

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
連線到我的命名空間。和我在其上有簡單的佇列

00:19:25.360 --> 00:19:28.770
您可以看到現在有兩個在 [訊息佇列。如果我做

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
任何特定的通訊協定或 API一個廠商。我要

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
能夠使用一個實體。這樣的其中一個結束點是否

00:22:11.530 --> 00:22:13.850
傳送結束點或接收結束點。

00:22:14.850 --> 00:22:16.820
您可以暫止作業。

00:22:17.560 --> 00:22:21.540
只是單一傳送呼叫或單一接收呼叫。

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
以二進位通訊協定，您實際上可以建立單一的連線，

00:23:01.370 --> 00:23:08.270
單一位元組，而單一的通訊端，和中的所有其他連結

00:23:08.320 --> 00:23:13.320
AMQP 內容是 multiflexed 的連結透過單一 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
相對於...實體支付，一次的成本，然後重複使用

00:23:26.930 --> 00:23:29.460
您的談話時以數個項目。

00:23:30.290 --> 00:23:33.900
請注意這種情況。有時候當您撰寫欄位閘道

00:23:33.950 --> 00:23:37.240
或您所自訂的閘道fronting 的裝置，很多這

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
要勉強接受它一天，一週的時間。通常您將不結清

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
使用正確的通訊協定權限的 SDK。

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
或 broke 中斷程式庫。

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
您可以看到我已經分割最多到三個部分。

00:29:29.850 --> 00:29:32.930
第一個正在進行同步處理傳送。

00:29:33.690 --> 00:29:38.660
以下是索引鍵的線條。每個訊息 qClient 作業，並傳送

00:29:38.710 --> 00:29:44.060
關閉訊息。這是非常的同步處理呼叫。一個完成的加權平均。

00:29:44.110 --> 00:29:48.030
它會等候認可準備從伺服器上，到達

00:29:48.080 --> 00:29:51.200
從用戶端，完整迴圈然後上將移動。

00:29:52.910 --> 00:29:56.650
第二個會以非同步的方式。

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
知道哪一個第一次，就會發生接下來會發生哪一個。

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
您可以看到現在佇列計數為零。

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
花了大約十秒術語這項目。並且，告訴您，

00:31:14.020 --> 00:31:18.360
我們可以永遠回來，請檢查訊息計數，以及它應該

00:31:18.410 --> 00:31:21.860
現在是 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
讓我有兩個清楚地呼叫正在對伺服器進行因此這個

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
提供數百訊息上一步]。它我們也會作任何

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
若要此批次的計算，直到我達到數百訊息。

00:34:53.920 --> 00:34:59.030
並在情況下，我打算僅保留其鎖定的語彙基元。

00:34:59.080 --> 00:35:01.160
這是所有我做的訊息上。若要保留所沒有的

00:35:01.210 --> 00:35:04.440
整個訊息。我已耗用的一次我已經處理的訊息

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
您可以以單一的鎖定語彙基元來呼叫兩個鎖定語彙基元任何

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
嘗試接收所有一百...第一次數百個訊息

00:36:07.490 --> 00:36:11.190
在那裡。現在更糟的是，這將會是附註效能比傳送，因為

00:36:11.240 --> 00:36:14.080
它進行兩次作業的數目所以我想要接收

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
我們也發現而不是十個傳送傳送，它會採用 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
所有一百 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
基本上分割佇列及主題取得一個佇列和磁碟分割

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
如果一個磁碟分割無法使用，另一個磁碟分割可以繼續

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
建立的佇列，有一個單一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
和基本種類的程式碼的任何人可以放那裡。在此

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
某些情況下，可能會傳送您使用非常 fat 的管道。

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 連線。

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
嘗試 demultiplex 資料流，

00:42:24.720 --> 00:42:26.530
demultiplex 資料流。

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
這是一個單一屬性他們必須設定。

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
現在您可以回想一下單一佇列中，您可以讓所有這些

00:43:13.340 --> 00:43:18.620
million 的子佇列和存放區每個佇列的狀態。因此就非常

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 工作階段，則為 true 時

00:43:43.540 --> 00:43:45.270
您正在建立佇列。

00:43:45.790 --> 00:43:49.670
在傳送端，您只需要設定一個屬性，此工作階段 id。

00:43:50.530 --> 00:43:55.720
然後在收到側邊，所有套用相同的參數

00:43:55.770 --> 00:43:59.840
像我跟剛才接受訊息工作階段，您可以接受

00:43:59.890 --> 00:44:03.730
訊息識別碼為工作階段] 或 [立即什麼，我們只要發行了

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
傳送成多個訊息當成工作階段識別碼加一。因此，如果它有

00:44:30.290 --> 00:44:33.480
工作階段 ID，我要傳送兩個訊息。如果工作階段

00:44:33.530 --> 00:44:36.070
兩個識別碼，我要傳送三個訊息等等。

00:44:37.350 --> 00:44:38.920
因此我會先寄件者。

00:44:39.880 --> 00:44:43.910
以及這裡，如果您查看此佇列中，在 [訊息佇列範例

00:44:44.580 --> 00:44:49.140
當建立此佇列中，只有一個屬性額外設定

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
現在讓我們來執行此份子。

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
這是所有正在執行一個暫存器呼叫。

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
單一資料流中的程序類別稱為 「 我的工作階段處理常式。

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
等於零，我們只保留計數因此，我所有的處理是。

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
在工作階段 objection 上的狀態。這些是基本上是資料流。

00:49:16.050 --> 00:49:20.770
並將計數值存放消失每次關閉工作階段。

00:49:21.780 --> 00:49:26.130
和最後一則錯誤大小寫的工作階段時遺失。

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
>> 問題是如此: 這將會使用相同的訂閱嗎?數百個百分比。

00:50:17.550 --> 00:50:21.170
它是完全對稱。是否您要從佇列接收

00:50:21.220 --> 00:50:24.130
或您正在接收訂閱。

00:50:25.440 --> 00:50:28.920
因此，這裡我的背景工作角色現在。讓我實際上快速檢查什麼

00:50:28.970 --> 00:50:30.850
看起來的佇列計數喜歡之後

00:50:32.060 --> 00:50:36.390
角色已完成傳送。看起來像從這裡得到為每小時 3700 郵件權限

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
關於只是簡單的工作階段，單一工作階段，我沒有

00:51:15.220 --> 00:51:18.800
若要撰寫在單一接收迴圈。只需已註冊管道處理常式。

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
暫存器處理常式 factory，您可以控制建立的方式

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
如果您看到每個工作階段，工作階段狀態是工作階段 21 22。

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 和 muxing簡單及所有項目已處理

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
因此另一個關鍵的考量當您有這些非常

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
這裡有佇列的 IOTguys 從網站中使用。

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
存取此原則名稱。因此在該網站範例哪些我

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
百萬個佇列。但您不會想要撰寫程式碼，

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
在其中一個他們和您的設定檔讓所有這些同步。

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
訊息的單一訂閱。

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
管道的位置，如果他們所做的變更上一個 VS 執行個體，其他

00:56:43.940 --> 00:56:45.430
VS> 執行個體同步。

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
一天嗎？

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，一個人擁有更多

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
並不需要將所有路由2 百萬個部門，然後

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
逗號，第二個。

00:59:25.130 --> 00:59:27.850
和我正在定址兩個裝置第一個裝置和第二個

00:59:27.900 --> 00:59:30.770
裝置或兩個訂閱，第一個和第二個。

00:59:30.820 --> 00:59:35.390
因為它們有設定好的規則喜歡第一個和第二個在那裡像。

00:59:36.390 --> 00:59:40.470
所以說真的，看看這些發行端點 sub (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
新增單一屬性。單一屬性稱為來源。ForwardTo，

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
其中一個的金鑰的情況下，這是正在使用，是 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
Deadletter 佇列，像我說您真的幫助您。它們可以協助

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
進行呼叫的傳送，請一次，則它可能會失敗我們會再試一次之後

01:02:19.770 --> 01:02:22.980
三秒。它可能檔案兩次。我們會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
此時，我們有虹吸管將會從這些郵件

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
空間，您認為嘿，第二個工廠，第二個命名空間

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
非常謝謝你。我深感抱歉對於任何內容。