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
Awesome. Ну, как говорится, они
Всегда сохраняйте лучше всего подходит для последнего.

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
разделы, которые pub 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
Устойчивость лучше соглашения об уровне ОБСЛУЖИВАНИЯ и как
для разработки приложения

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
На сообщение сеансу. Члена т. д.
присяжные являются push

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
но порт 443 и 83


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
STPI с SCTP. Это можно сделать отправить
сообщения, сообщения

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
для очереди недоставленных сообщений.

00:06:23.880 --> 00:06:27.380
Deadlettering является очень, очень мощный
функция, где он защищает

00:06:27.430 --> 00:06:30.820
Вы назад заканчивается при повреждении
сообщения. Обычно

00:06:30.870 --> 00:06:34.620
именем очереди подозрительных где попробуйте
Для получения сообщений и

00:06:34.670 --> 00:06:38.600
сообщение не формируется или нет
Ошибка в коде, где-то

00:06:38.650 --> 00:06:42.080
на в civilizer de куда-нибудь
где вы не открываются

00:06:42.130 --> 00:06:44.560
сообщение и сбоев вашей базы данных.

00:06:45.780 --> 00:06:50.390
Шины служб предоставляет возможность
настройки max доставки

00:06:50.440 --> 00:06:54.420
Счетчик, который по умолчанию — 10, а какие
Это означает, что если мы видим

00:06:54.470 --> 00:06:57.660
что мы доставлено сообщение
то есть 10 раз и

00:06:57.710 --> 00:07:01.310
не завершено
сообщение, мы будет переместить его из

00:07:01.360 --> 00:07:03.240
основной очереди в
очередь недоставленных сообщений.

00:07:03.870 --> 00:07:07.930
Так что это помогает буквально приложений
быть устойчивым по умолчанию

00:07:08.190 --> 00:07:12.840
не требуется писать один
строки кода и защиты

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
все очереди недоставленных сообщений в
что означает одной очереди

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
1.1 версии Windows server.

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
можно увидеть каждые 3-4 месяца
и локально выпуска в

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
Поэтому отправителей имеет значение nothing, но
где-то, где вы находитесь.

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
Это было сделано, awesome, awesome фрагмент
технологии потому что происходит попытка

00:11:57.130 --> 00:12:02.580
Чтобы решить эту проблему, работающего на
код в масштаб в распределенный

00:12:02.630 --> 00:12:06.190
способом ли вы имеете дело с
события, которые создаются

00:12:06.240 --> 00:12:10.830
большим числом отправителей и
корреляцию в которых время идет своей дорогой.

00:12:12.020 --> 00:12:15.930
Итак, как убедитесь, что они
внутренние системы связаны?

00:12:15.980 --> 00:12:18.590
Как убедитесь, что они
внутренние системы способны

00:12:18.640 --> 00:12:24.640
получать сообщения по этому курсу и действовать
в случаях, в котором они были устойчивыми?

00:12:25.950 --> 00:12:29.560
И для этого необходимо поместить разделы в
по середине. Поэтому разделы не только

00:12:29.610 --> 00:12:33.440
позволяют буферизации, так же, как
будет очередь, т.е.

00:12:33.490 --> 00:12:35.950
можно сделать вашей серверной
несколько часов, а не

00:12:36.000 --> 00:12:39.060
потеря одного из событий. События
по-прежнему остаются там, но они

00:12:39.110 --> 00:12:40.490
также дают pub sub.

00:12:41.470 --> 00:12:45.530
Что означает, что при наличии других
компьютеры, на которых читаете

00:12:45.580 --> 00:12:51.310
Отслеживание состояния, допустим, размещение
значения в Azure кабелей или

00:12:51.360 --> 00:12:56.520
они ни делали analytics пакета с
связь структуры файлов в

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
и выполнение запросов бизнес-Аналитики
поверх всего этого.

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
А затем из back-end ли
вы читаете в Azure

00:13:37.040 --> 00:13:41.730
таблицы или хранилище данных SQL
можно создать свой bash

00:13:41.780 --> 00:13:43.200
Системные платы и аналитики.

00:13:44.750 --> 00:13:45.750
Поэтому одним из ключа

00:13:46.970 --> 00:13:49.340
элементы проектирования в этот пакет.

00:13:50.180 --> 00:13:52.920
Сначала использует темы
для вентилятора в.

00:13:53.960 --> 00:13:57.730
Вентилятор в необходимыми для функционирования означает невелико
разделы, чем у устройств.

00:13:57.780 --> 00:13:59.900
Не правда ли? Что такое
Возможно мощности.

00:14:01.080 --> 00:14:03.820
Он, скорее всего, не будет
один. Она не будет

00:14:03.870 --> 00:14:07.660
раздел для всех объектов. Вероятно
не будет Северная позволяет перейти

00:14:07.710 --> 00:14:12.220
Чтобы быть где-то между ними и как
мы говорим о выигрыша

00:14:12.270 --> 00:14:13.860
с данным номером справа.

00:14:14.410 --> 00:14:18.960
Вы собираетесь нагрузку по
центры обработки данных по нескольким причинам.

00:14:19.320 --> 00:14:22.490
Если вы думаете об этом, эти устройства
фактически географически

00:14:23.190 --> 00:14:26.300
распространение, поэтому необходимо сделать
Убедитесь, что устройство использует

00:14:26.350 --> 00:14:30.740
наименьшее количество электроэнергии, минимальный
задержка подключения можно

00:14:30.790 --> 00:14:33.770
Чтобы обратиться и его данных в очередь.

00:14:35.480 --> 00:14:39.640
Так что это распределяются по данным
центры. Поэтому эта шина доступна

00:14:39.690 --> 00:14:45.690
во всех регионах Azure выравнивание всех данных.
Чтобы иметь возможность

00:14:45.740 --> 00:14:50.730
для распространения темы вокруг. На теперь,
значит, к внутренним

00:14:50.780 --> 00:14:53.890
системы должны быть abdicated
для всех тех, окружение, слишком.

00:14:54.880 --> 00:14:58.000
Если факт, если вы думаете о Hadoop
кластеры, обычно это

00:14:58.050 --> 00:15:01.860
что-то не будет реплицировать в
каждый регион в каждом центре обработки данных.

00:15:01.910 --> 00:15:05.890
Но это дает небольшой задержки
Конечная точка. Оттуда можно

00:15:05.940 --> 00:15:10.490
Сбор данных, для которой выполняется
создан. А затем потяните

00:15:10.540 --> 00:15:14.310
из вашей серверной. Достижения по
для всех регионов и

00:15:14.360 --> 00:15:18.450
подписки в различных регионах
и сопоставление данных.

00:15:20.910 --> 00:15:23.690
Значение 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
Поэтому на веб-странице которой я
показал вам и вы видите как

00:18:35.560 --> 00:18:40.400
Действительно отправить простое и
Получает для данного сообщения.

00:18:40.450 --> 00:18:44.840
HTTP delete — фактически
Для получения сценария.

00:18:45.430 --> 00:18:47.500
Что мы увидим чуть позже.

00:18:48.120 --> 00:18:56.600
И put для отправки сценария, учет
к сожалению, до отправки сценария.

00:18:58.510 --> 00:19:02.420
Позвольте

00:19:03.620 --> 00:19:05.210
мне отправить несколько сообщений.

00:19:05.810 --> 00:19:09.220
И только для отображения сообщений
видны, здесь у меня сервера

00:19:09.270 --> 00:19:12.280
Explorer загрузки данных с...

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 циклы ЦП и материалы из

00:24:29.370 --> 00:24:33.080
Получение об этом. Мы будет хранить
активность через подключение

00:24:33.130 --> 00:24:37.040
пакеты или другие подсистемы балансировки нагрузки
необходим и мы представим

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 последнего
Октябрь. Он просто очистить 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
Синхронизация async и партии.

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
В общем Async, всегда
Лучшим способом. Всегда можно

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
Вторая делает это
образом async.

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
Отправка партии, так как с Async, обычно
люди придумать

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
Занимает около 10 секунд в терминах
об этом. И только для того, чтобы показать,

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
Теперь давайте посмотрим, что произойдет при
Сделать то же самое с Async.

00:31:29.190 --> 00:31:30.590
Же с Async.

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
Сравнение Async и партии.

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
Далее — Async и здесь вы
можно увидеть, что я делаю

00:33:49.430 --> 00:33:56.230
Это задача, имеющая продолжить с для
затем вызовите полный для него.

00:34:01.730 --> 00:34:05.290
И снова будет ждать все те
carving завершения задач

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
полный пакет Async со всеми
Заблокированные маркеров в него.

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
>> Абсолютно. Абсолютно.
Поэтому полный пакет Async.

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
С Async так, как вы выполняете сразу несколько
их параллельно теперь вы получаете вниз

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
Чтобы увидеть разницу между
Синхронизация, Async и пакет, и

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
и какие любой тип кода basic
там можно поместить. В этом

00:40:32.760 --> 00:40:35.500
обращение, которое все в порядке. Просто задав
свойства, являются, так что это нормально.

00:40:35.550 --> 00:40:38.540
Но если когда-нибудь показал код
в Microsoft 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
Сеансы является awesome встроенные
функция службы шины

00:42:33.120 --> 00:42:37.130
по сути, создает подочереди.
Поэтому каждый сеанс можно представить

00:42:37.180 --> 00:42:40.290
о качестве подочередь, при полной очереди.

00:42:41.480 --> 00:42:44.860
И только исходный характер
установить идентификатор сеанса.

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
код для этого. По сути это сделать.
значение true, если сеанс безопасная

00:43:43.540 --> 00:43:45.270
При создании очереди.

00:43:45.790 --> 00:43:49.670
На стороне отправки достаточно
задается одно свойство идентификатор сеанса.

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
Поэтому-то отправителя
для каждого сеанса идентификатор будет

00:44:25.790 --> 00:44:30.240
Чтобы отправить так много сообщений, как
Идентификатор сеанса, плюс один. Таким образом, если он имеет

00:44:30.290 --> 00:44:33.480
Идентификатор сеанса, я собираюсь отправить
два сообщения. Если сеанс

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
требуется свойство сеанса
"Ложь". Это не хорошо.

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
И здесь можно увидеть все, что я делаю
вызывает состояние set и get

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
Эта ошибка вызывается. В этом случае
все это будет сделать это abandon

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
Так вот Моя рабочая роль. Let
мне действительно быстро проверить, что

00:50:28.970 --> 00:50:30.850
Поиск очереди счетчик
как и после

00:50:32.060 --> 00:50:36.390
роль была выполнена отправка. Выглядит как
ней есть 3,700 сообщения справа

00:50:36.440 --> 00:50:40.610
Теперь 33, выглядит обработки
активации.

00:50:41.650 --> 00:50:56.690
Позвольте мне перейти в него...
мы последовательно. Они приходят.

00:50:56.740 --> 00:51:03.350
Хорошо. Поэтому прямо сейчас, находятся на моем компьютере
При работе через

00:51:03.400 --> 00:51:06.090
можно увидеть обработки тысяч
и тысячи сообщений.

00:51:06.890 --> 00:51:10.740
И код, который я написал:
очень, очень простой анализ

00:51:10.790 --> 00:51:15.170
о достаточно простой сеанс, один
сеанс и я не было

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 и 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
Здесь имеется IOT, в очереди которого вы
Авторы используют с веб-сайта.

00:53:16.050 --> 00:53:18.850
А можно просто перейти здесь и настроить.

00:53:19.420 --> 00:53:23.650
Обратите внимание на то, что было Oh...

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
экземпляров интегрированной среды разработки, а затем
может вернуться и изменить свой

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 экземпляров
запуск интегрированной среды разработки является

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
Разъем ввода/вывода. Они являются очень,
очень временный характер.

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
Оба они доступны, если вы хотите
горизонтальное масштабирование, сигнал out или сокета

01:01:20.290 --> 01:01:24.720
Ввод-вывод так как вам понадобится устойчивый обмен сообщениями
канал в конце службы

01:01:24.770 --> 01:01:27.980
Шина имеет реализации
для обоих из них.

01:01:29.920 --> 01:01:33.050
Необходимо поговорить немного построен
о доступности позвольте мне

01:01:33.100 --> 01:01:36.780
быстро говорить об этом. Я знаю
Мы практически со временем

01:01:38.830 --> 01:01:42.440
код должен быть устойчивым к операции
сбои также подключен

01:01:42.490 --> 01:01:43.470
с проблемами.

01:01:43.990 --> 01:01:46.750
Очереди недоставленных сообщений, как я сказал, что
Вы действительно помогают. Они помогают

01:01:46.800 --> 01:01:50.790
Вы в приложение на уровне где
decivilization сообщения или

01:01:50.840 --> 01:01:51.830
что-то может произойти сбой.

01:01:52.980 --> 01:01:57.440
Каждое сообщение, порождающий шины служб
в временные свойства

01:01:57.490 --> 01:01:58.020
на нем

01:01:59.480 --> 01:02:02.780
просто и очевидно, что упрощает
узнать ли вы

01:02:02.830 --> 01:02:04.350
понадобится повторить его или нет.

01:02:05.090 --> 01:02:08.560
По умолчанию мы на самом деле являются автоматически
Повторная попытка. Поэтому я говорил

01:02:08.610 --> 01:02:12.090
о времени ожидания операции по сути
истечение времени ожидания. По умолчанию

01:02:12.140 --> 01:02:15.190
значение времени ожидания операции
60 секунд, что означает, если вы

01:02:15.240 --> 01:02:19.720
Сделайте вызов send, может оказаться один раз,
мы попытаемся найти его снова после

01:02:19.770 --> 01:02:22.980
три секунды. Он может файл два раза. Мы будем
Попробуйте снова через десять секунд.

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
сделать код с помощью шаблонов, подобно
Async и партии и материалы.

01:05:38.100 --> 01:05:41.750
Множество ссылок. Многочисленные ресурсы.
Имеется доступ к все это.

01:05:41.800 --> 01:05:44.130
Спасибо так много. Приношу извинения
по какой-либо.