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
想必，我不 disappoint你们这些家伙。我非常喜欢

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
主题，是 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
这样的 SDK 2.3。

00:03:26.330 --> 00:03:28.310
内容未刚刚发布？

00:03:29.070 --> 00:03:32.540
在邮件会话。等成员的陪审员的是推

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
最后，向前要和对于 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
消息格式不是或有在某处代码中的 bug

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
后端服务器。因此向前要是给渠道的能力

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
为所有 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
我又想快速回顾一下怎么办我们所做的最后一个月以来

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 服务器版本 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 的服务器版本因此大部分时间他们试

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
遥测，用户的操作。

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
此外为您提供 pub 子。

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 数据仓库，您可以生成您大扫除

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
对于一个订阅，则筛选器因此，在此垂直

00:15:23.740 --> 00:15:27.550
客户的情况下，它们实际上为什么使用他们的数据，

00:15:27.600 --> 00:15:31.700
状态跟踪和批处理中的代码分析功能，但不是在 BI。

00:15:31.750 --> 00:15:35.900
因此，所有这三个是真的筛选器，但一个订阅

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
churning 的 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
或断开以破坏库。

00:26:16.680 --> 00:26:20.260
因此您刚开始使用 AMQP，请参阅标准化的以后...

00:26:20.310 --> 00:26:26.370
顺便说一句，AMQP 是 OASIS 标准最后一次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 库开发集或质子库

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
现在一旦调用接收批次与 hundred 并不意味着我们

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
采用一丝一毫的 salt 值，在此网络上运行，是

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
某些情况下，您可能发送使用一个非常宽管道。

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
试图进行逐层传送流，

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
这就是一个的单个属性他们必须设置。

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
万子队列和存储每个队列的状态。因此非常，

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
此代码。实质上是您执行的操作为 true 时 quire 会话

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
邮件会话 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 加一。因此，如果它有

00:44:30.290 --> 00:44:33.480
会话 ID 之一，我要发送两条消息。如果会话

00:44:33.530 --> 00:44:36.070
两个 ID，我要发送三个邮件，等等。

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
需要会话属性假。这不是好的。

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 辅助角色中，在在开始做的方法

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
这就是我正在做此类中的。Count 是一个私有成员

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
这是会话异议上的状态。这些都是实质上的流。

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
角色已完成发送。如下所示采用了 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
只是一个简单的会话，一个关于会话和我没有

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
注册处理程序工厂，您可以控制创建方法

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 和复用很容易，一切都被处理

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
在这里有排队的 IOT专家从该网站使用。

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
必须为 super 复杂太。因此这两个是非常，非常

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
管道的位置，如果进行了更改上一个与实例中，其他

00:56:43.940 --> 00:56:45.430
与实例同步。

00:56:46.140 --> 00:56:48.340
可方主题和为该订阅。

00:56:49.760 --> 00:56:52.470
所以把它从概念上说作为主题与每个用户。

00:56:53.200 --> 00:56:58.800
您的订阅与每个实例始终使用 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
这些主题与每个用户的操作是正常的但它可能您

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
所以实际上，看看这些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
添加单个属性。单个属性被称为源。向前要

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
3 秒。此文件可能会两次。我们将在 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
Tons 的链接。Tons 的资源。您有权访问所有这些。

01:05:41.800 --> 01:05:44.130
感谢您这么多。我深表歉意一切。