WEBVTT

00:00:01.460 --> 00:00:02.340
어 서 옵 쇼입니다.

00:00:04.930 --> 00:00:05.880
사람들의 수행 방법

00:00:08.810 --> 00:00:14.600
좋은? 거의 대 한 말씀
회의 끝.

00:00:15.630 --> 00:00:17.150
경험은 어떻게 합니까
지금까지 했습니다.

00:00:17.160 --> 00:00:19.360
[박수]

00:00:19.520 --> 00:00:20.120
>> 좋아.

00:00:20.170 --> 00:00:24.940
멋진. 으로 잘 하기
항상 가장 마지막에 저장 합니다.

00:00:26.240 --> 00:00:32.190
여러분도, 필자는 하지 실망 시키는
넌 트는입니다. 정말 감사 드립니다.

00:00:32.240 --> 00:00:34.450
에 있어서 점심입니다.

00:00:35.200 --> 00:00:40.360
Abhishek Lal 있어요입니다. 프로그램 관리자
Azure 플랫폼 팀.

00:00:41.090 --> 00:00:45.840
PaaS를 작성 하는 팀
모바일 서비스 등의 서비스

00:00:45.890 --> 00:00:48.550
서비스 버스, Azure 캐시 합니다.

00:00:49.240 --> 00:00:51.080
및 미디어 서비스입니다.

00:00:51.720 --> 00:00:54.320
이러한 서비스는 어떤
팀을 소유 하 고 있습니다.

00:00:54.830 --> 00:00:58.940
특별히 필자와
지난 3 년간의

00:00:58.990 --> 00:01:05.100
중개 메시징 구축
조각입니다. 이 큐는 지금

00:01:05.150 --> 00:01:08.720
주제는 pub 하위
하의 부분입니다.

00:01:09.470 --> 00:01:15.150
오늘에 대해 지시
비율에서 메시징.

00:01:17.010 --> 00:01:22.030
큐와 토픽 사람들은 이제
서비스 버스에 잘 알고 있습니다.

00:01:22.840 --> 00:01:26.920
릴레이 둘러싸지 않는 것. 그렇게
알림 허브 포함

00:01:27.780 --> 00:01:29.010
큐와 토픽

00:01:29.560 --> 00:01:34.840
일종의 전체 폭 넓게
메시징 관련 서비스.

00:01:35.710 --> 00:01:39.560
세션 진행
큐에 초점을

00:01:39.610 --> 00:01:46.260
하는 기본 항목
영역입니다. 질문이 있는 경우

00:01:46.310 --> 00:01:50.120
나를 아는 것
릴레이 대 한 또는

00:01:50.170 --> 00:01:55.150
행복 하 난 알림 허브
응답 하는 또는 적어도 지점

00:01:55.200 --> 00:01:57.410
올바른 방향으로 있습니다.

00:01:58.820 --> 00:02:00.930
많은 일은
오늘 설명 하고자 합니다.

00:02:01.710 --> 00:02:04.730
모든 다양 한 측면에 대 한 이야기
배율입니다. 이야기 하고자 합니다.

00:02:04.780 --> 00:02:08.490
발신자 및 수신자에 대 한
모든 다른 처리량

00:02:08.540 --> 00:02:11.630
패턴으로는
코드의 특성입니다.

00:02:12.390 --> 00:02:14.870
어떻게 확장 시킬 수 있습니다.

00:02:15.810 --> 00:02:19.040
따라서 좋은 속도 유지 하려고 합니다.

00:02:19.640 --> 00:02:24.190
질문은 훌륭한입니다. 알림 표시
간단한 질문을 가공 하기 시작 합니다.

00:02:24.240 --> 00:02:27.780
단지 조금 나중에 있도록 I
원하는 모든 내용을 다룰 수 있습니다.

00:02:27.830 --> 00:02:31.490
설명 합니다. 난 후 사용할 수 있습니다.
세션을 언제 든 지

00:02:31.540 --> 00:02:36.200
나에 게 접근 하지만 대화형 유지 마십시오.
아무 것도

00:02:36.250 --> 00:02:41.270
마이크는 바로 여기입니다.
바로 액세스 하 고 확인해 보겠습니다.

00:02:43.930 --> 00:02:48.720
무엇에 대해 이야기 하 여 시작의
새. 마찬가지로 정렬 업데이트

00:02:48.770 --> 00:02:51.210
어떻게 우리가 한 발표 SDK 2.3으로 합니다.

00:02:52.250 --> 00:02:56.290
이야기를 전환합니다
규모의 크기입니다.

00:02:56.340 --> 00:03:00.420
보낸 사람, 수신자에 대 한 설명
처리량을 달성 하는.

00:03:01.800 --> 00:03:05.770
시간에 시간 수는 다음
가용성 고려 사항

00:03:05.820 --> 00:03:07.850
뿐 이므로 광범위 하 게 사용 가능 시간

00:03:09.190 --> 00:03:14.340
향상 SLA 복구 방법
응용 프로그램을 디자인 하려면

00:03:14.390 --> 00:03:19.520
수 항상 최대, 항상, 실행
일부 소요 됩니다 우리 때문에

00:03:19.570 --> 00:03:20.510
에 있는 시간입니다.

00:03:22.060 --> 00:03:25.780
따라서 SDK 2.3입니다.

00:03:26.330 --> 00:03:28.310
어떤 않았습니다만 출시

00:03:29.070 --> 00:03:32.540
메시지 세션입니다. 등 구성원의
juries는 밀어넣기

00:03:32.590 --> 00:03:36.970
API 스타일입니다. 기본적으로
멀리 로부터 모든 하드 작업

00:03:37.020 --> 00:03:42.960
C 루프 또는 아무 것도 기록 합니다.
그러한 복잡성의

00:03:43.010 --> 00:03:46.420
아주 이벤트-다른 제공
메시지를 사용 하는 모델입니다.

00:03:46.470 --> 00:03:50.110
수신자 쪽 API입니다. 따라서
준비 하는 세션에 대 한.

00:03:50.160 --> 00:03:52.680
확실히 다룰 것입니다.
더 자세히 오늘.

00:03:53.890 --> 00:03:58.440
연결 모드를 자동으로 검색 합니다.
실제 중 알고 있으므로

00:03:58.490 --> 00:04:02.520
Azure 서비스 버스 된 키 값
연결 하는 경우

00:04:02.950 --> 00:04:07.700
큐와 클라우드에서 주제에
방화벽의 뒤에서

00:04:07.750 --> 00:04:11.450
자신의 데이터 센터 또는 프로그램
있는 고객 데이터 센터

00:04:11.500 --> 00:04:16.230
매우 잘 보호 되 고 뒤에 앉아 됩니다.
일종의 방화벽, 서비스

00:04:16.280 --> 00:04:19.660
버스는 아웃 바운드 연결에서 TCP 포트 뿐만 아니라 수 있습니다.

00:04:19.710 --> 00:04:22.110
하지만 83 번과 443 번 포트


00:04:23.670 --> 00:04:25.860
하지만 TCP 포트 차단 됩니다.


00:04:26.700 --> 00:04:30.790
이 기능을 지금 사용할 수
직접 설정 하는 경우에

00:04:30.840 --> 00:04:34.230
모드, TCP 사용 하 여 디렉터리
따라서 절대로 선택을 했습니다.

00:04:34.910 --> 00:04:38.730
이제 코드에서 설정할 수 있습니다만
자동으로 감지 하 고 예정

00:04:38.780 --> 00:04:42.910
TCP 포트는 자동으로 표시
사용할 수 있는, 사용 됩니다.

00:04:42.960 --> 00:04:48.410
우리는 방화벽에서 차단 하는 경우
HTTP로 놓습니다. 따라서 SDK

00:04:48.460 --> 00:04:51.560
사용할 수 있는 2.3
또한 메시징.

00:04:54.390 --> 00:04:57.980
CORS를 지원합니다. 얼마나 많은 사람들이
CORS는 알고?

00:05:00.360 --> 00:05:04.200
대부분의 사람들이 알고 있습니다. 이 기본적으로
보내기/받기 쉬운 사용

00:05:04.250 --> 00:05:09.370
브라우저. 생각 하는
항상 있을 수 있는,

00:05:09.420 --> 00:05:14.320
SCTP에 STPI입니다. 할 수 있는 전송
메시지를 수신 하는 메시지를

00:05:14.370 --> 00:05:18.920
CORS를 지금 하면 거의 없지만
브라우저와 웹 사이트를 쉽게

00:05:18.970 --> 00:05:23.650
통합 백 해 자세히 알아보겠습니다
에 자세히 오늘입니다.

00:05:25.010 --> 00:05:29.530
마찬가지로, 일종의 도움 함께
규모와 성능

00:05:29.580 --> 00:05:34.760
HTTP 보낸 사람에 대 한 준비
일괄 처리 지금 사용할 수 있습니다.

00:05:35.200 --> 00:05:43.980
및 다음 클라이언트 쪽 성능
당신은 때 카운터

00:05:44.030 --> 00:05:46.900
실제로 응용 프로그램을 가져오는
당신은 나는 복잡 한

00:05:46.950 --> 00:05:50.450
다양 한 환경에서 실행.
해야 할 수도 있습니다.

00:05:50.500 --> 00:05:53.340
디버깅 및 프로 파일링 할 수 있습니다.
것 이므로 클라이언트 추가 했습니다

00:05:53.390 --> 00:05:57.890
메시지를 보낸 쪽 성능 카운터
둘째, 문자 / 초 당

00:05:57.940 --> 00:06:01.460
와 같이, 수는
정말 도움이 프로필

00:06:01.510 --> 00:06:05.250
중인 메시징 레이어는
수행 반대 하 고 전반적인

00:06:05.300 --> 00:06:09.020
행사 수행 하 고 있습니다. 것 들
이러한 성능에 대 한 다음 매니페스트

00:06:09.070 --> 00:06:14.230
NuGet 패키지의 일부로 카운터
실제로 사용할 수 있도록 여기에

00:06:14.280 --> 00:06:17.550
좋은 디버깅을 수행할 수 있습니다.

00:06:20.550 --> 00:06:23.340
마지막으로, 앞으로앞 및
배달 못한 편지 큐입니다.

00:06:23.880 --> 00:06:27.380
Deadlettering는 매우 강력한
보호 하는 기능

00:06:27.430 --> 00:06:30.820
독 있으면 당신은 후면 끝
메시지입니다. 일반적으로 이러한

00:06:30.870 --> 00:06:34.620
시도 하면 포이즌 큐 라는
메시지를 받을 수 있고

00:06:34.670 --> 00:06:38.600
메시지는 잘못 되거나
내 코드에서 버그

00:06:38.650 --> 00:06:42.080
에 곳에 de civilizer의
여기서 모르는 열 수

00:06:42.130 --> 00:06:44.560
메시지와 해당 백 엔드 충돌 합니다.

00:06:45.780 --> 00:06:50.390
서비스 버스 기능 제공
최대 배달 설정

00:06:50.440 --> 00:06:54.420
기본적으로는 10, 및 어떤 횟수
볼 경우에

00:06:54.470 --> 00:06:57.660
메시지를 배달 한 것
10 번-가 수

00:06:57.710 --> 00:07:01.310
완료 하지는
메시지 옮길 것에서

00:07:01.360 --> 00:07:03.240
주 큐에는
배달 못한 편지 큐입니다.

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
모든 배달 못한 편지 큐에 대 한
즉 단일 대기열

00:07:34.500 --> 00:07:38.530
지금 당장 한 곳 것
포이즌 메시지를 모두 수신 합니다.

00:07:38.980 --> 00:07:42.340
큐 개수에 관계 없이
항목 또는 구독 하면

00:07:42.390 --> 00:07:46.280
지금 사용 하는 한
기능이 너무 추가 해야 합니다.

00:07:47.180 --> 00:07:49.910
에 설명할 것
조금 더 자세히입니다.

00:07:51.740 --> 00:07:57.570
에 신속 하 게 제시 하려는
마지막 4 월 이후의 경험

00:07:57.620 --> 00:08:01.400
때 말할 오늘에 있기 때문에
확장성 및 성능상의 조건

00:08:01.450 --> 00:08:05.780
처리량을 많이 볼 수 있습니다
이러한 기능을 참조 하 고

00:08:06.180 --> 00:08:08.570
호출을 하고자 하므로
그들의 용어에

00:08:08.620 --> 00:08:12.370
이미 사용 가능한 오늘 고 했습니다.
잠시 동안 이지만

00:08:12.420 --> 00:08:16.250
그들 계속 필요한 것은 없어입니다.

00:08:18.520 --> 00:08:22.290
여기에 한 가지 서비스를 제공합니다
아래 줄을 첫 번째

00:08:22.340 --> 00:08:26.310
서비스 버스 완성도에 따라서 마지막
서비스 버스를 했던 1 년

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
일종의 클라우드 버전의이 흐름
3 개월 마다 있습니다

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
보낸 사람 할 것이 아니라
하는 순서

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 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
모든 것에 대 한 항목입니다. 그것이
북부 수 거 됩니다.

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
상태 추적 및 일괄 처리 코드
분석 있지만 아닌 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
이 웹 페이지는 I
표시 하 고 있습니다 볼 수 방법

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
Put은 post 보내기 시나리오는
죄송 합니다 보내기 시나리오에 관해서는.

00:18:58.510 --> 00:19:02.420
사용

00:19:03.620 --> 00:19:05.210
내가 몇 가지 더 많은 메시지를 보냅니다.

00:19:05.810 --> 00:19:09.220
메시지를 표시 하 고
표시, 여기 어 서버

00:19:09.270 --> 00:19:12.280
탐색기를 사용 하 여 데이터를 로드 중...

00:19:21.330 --> 00:19:25.310
my 네임 스페이스에 연결 합니다. 내가 하 고
간단한 큐를가지고

00:19:25.360 --> 00:19:28.770
이제 두 가지를 볼 수 있습니다.
메시지를 큐에 대기 합니다. 수행 하는 경우는

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
또는 사용자 지정 게이트웨이 있는 곳
가급적 많은 장치를이

00:23:37.290 --> 00:23:40.690
매우 중요 한 고려가 됩니다.

00:23:43.280 --> 00:23:48.250
다른 부분은 당겨 깁니다.
따라서 상수 것이가

00:23:48.300 --> 00:23:51.400
큐, 오른쪽에서 잡아 당겨 하는 방법에 대 한
이 봐 요, 용량은 메시지

00:23:51.450 --> 00:23:55.160
메시지가 있습니까? 있습니까
메시지? 여기 있기 때문에

00:23:55.210 --> 00:24:01.040
AMQP 프로토콜에 대 한 연결
우리가 연결을 유지 합니다.

00:24:01.090 --> 00:24:04.370
모든 작업을 수행 하지 않아도 됩니다.
외가 보류

00:24:04.420 --> 00:24:09.120
수신에 대해 설정할 수 있는 한
무한 시간 제한입니다. 수 있다

00:24:09.170 --> 00:24:12.110
이 하루, 한 주에 라도. 일반적으로
정한 하지 않습니다.

00:24:12.160 --> 00:24:16.090
무한에 대 한 모든 항목을 설정 합니다.
프로그램 종료 특징

00:24:16.140 --> 00:24:19.560
다음과 같이 아마 20 분 또는
같습니다. 하지만

00:24:19.610 --> 00:24:24.920
수신 대기 중인 긴 풀을 가질 수 있습니다.
에 대해 걱정할 필요가 없습니다

00:24:24.970 --> 00:24:27.640
나 CPU 주기 및 물건의

00:24:29.370 --> 00:24:33.080
정보를 가져오는 중입니다. 우리는 유지
연결을 통해 연결

00:24:33.130 --> 00:24:37.040
ping 또는 부하 분산 장치
이 필요를 제공할 것을

00:24:37.090 --> 00:24:41.640
대기 시간이 짧은 응답 수
때마다 메시지가 나타납니다.

00:24:42.360 --> 00:24:45.820
가 되므로 매우 중요 한 다른
측면에서의 고려 사항

00:24:45.870 --> 00:24:50.380
물론 비용에 미치는 영향
장치입니다. 따라서 바이너리 프로토콜

00:24:50.430 --> 00:24:53.310
용어에 차이가지 않습니다
시나리오.

00:24:56.240 --> 00:24:59.820
프로토콜을 다른 고려 사항
제공 Sdk에는.

00:24:59.870 --> 00:25:03.520
원하는 생산성을 가져올 수 있습니다. 원합니다
솔리드 코어를 사용 합니다. 원합니다

00:25:03.570 --> 00:25:08.220
솔리드 라이브러리 사용 합니다. 따라서 하면 정말
선택할 수 있도록

00:25:08.270 --> 00:25:11.010
올바른 프로토콜
오른쪽 SDK입니다.

00:25:12.880 --> 00:25:13.950
서비스 버스에 대 한이

00:25:15.670 --> 00:25:19.750
.NET에서 다음 기본 사용 하는 경우
SBMP 프로토콜 기본값입니다.

00:25:19.800 --> 00:25:24.130
사용 되는 것입니다. 전환할 수 있습니다.
AMQP 언제 든 지 하 고

00:25:24.180 --> 00:25:25.170
에 유용 합니다.

00:25:25.850 --> 00:25:28.980
일부 주요 방어는
지금 바로 영업

00:25:29.030 --> 00:25:33.730
그 간격이 매우 빨리입니다. 당신이 하는 경우
.NET을 사용 하 여 다음 SBMP가

00:25:33.780 --> 00:25:36.010
일종의 기본 시나리오에 오늘입니다.

00:25:37.560 --> 00:25:42.400
이 경우 HTTP를 사용 하는 경우의
경우는 HTTP 래퍼를

00:25:42.450 --> 00:25:46.160
사용할 수 있는 운영 체제 및
라이브러리의 사용 가능한 많이입니다.

00:25:47.010 --> 00:25:50.510
다음 AMQP를 사용 하 여 시작 하는 고
많은 커뮤니티를

00:25:50.560 --> 00:25:51.700
라이브러리 제공 합니다.

00:25:52.940 --> 00:25:59.670
AMQP는 개방형 표준 되었습니다.
사용 하 여 설계 되 고 개발 된 모든

00:26:00.690 --> 00:26:05.690
효율적이 고 안정적인 염두
휴대용 데이터 정렬이 됩니다.

00:26:05.740 --> 00:26:10.310
표현과 유연성
고려 합니다. 유연성 측면에서

00:26:10.360 --> 00:26:13.470
클라이언트에 클라이언트 인지 여부
라이브러리 또는 중개 하는 클라이언트

00:26:13.520 --> 00:26:15.120
또는 위반 하는 라이브러리를 않은.

00:26:16.680 --> 00:26:20.260
따라서는 AMQP를 참조 하기 시작 했다면
표준화 앞으로...

00:26:20.310 --> 00:26:26.370
그런데 AMQP를 표준 오아시스 마지막
10 월입니다. 단순히 ISO/IEC 지워집니다.

00:26:27.560 --> 00:26:32.950
이제는 인식 한 국제
표준, 너무. 하의

00:26:33.210 --> 00:26:35.180
블로그를 새로.

00:26:36.990 --> 00:26:41.560
의미 하는 있지만 수
다양 한 라이브러리를 볼 수 있습니다.

00:26:42.230 --> 00:26:47.750
Apache Qpid 라이브러리 개발
집합 또는 proton 라이브러리

00:26:47.800 --> 00:26:51.010
여러 언어로 클라이언트입니다.

00:26:51.890 --> 00:26:55.240
C, Java, JMS 구현 합니다.

00:26:56.110 --> 00:27:00.670
Php. 이들 모두 사용할 수 있습니다.
커뮤니티를

00:27:00.720 --> 00:27:05.970
라이브러리 지원을 사용 하 여 소스를 엽니다.
개발 및 참여

00:27:06.020 --> 00:27:06.740
하 고

00:27:07.970 --> 00:27:12.310
다른 서비스와 함께
공급자에서 지원 되는

00:27:12.360 --> 00:27:14.070
AMQP 포털에.

00:27:14.820 --> 00:27:18.400
서비스 버스에 액세스 하려는 경우
서로 다른 프로토콜을 볼 수 있습니다.

00:27:18.450 --> 00:27:22.940
어떤 선택 많아
Sdk를 사용 하는 라이브러리

00:27:22.990 --> 00:27:34.850
사용 하 고 수 하지 않아도 됩니다.
특정 한 방식으로 제한 됩니다.

00:27:34.900 --> 00:27:36.150
동기화, 일괄 처리 및 비동기입니다.

00:27:37.150 --> 00:27:40.650
따라서 우리가 이해 하는 무엇입니까
프로토콜 차이 같아요

00:27:40.700 --> 00:27:45.840
경우에 대해 설명 해야 합니다
비동기 동기화 코드를 작성

00:27:45.890 --> 00:27:49.170
코드 및 일괄 처리 코드 및 이란
실제 용어 차이

00:27:49.220 --> 00:27:54.100
볼 수 있는 성능
이러한 다른 시나리오입니다.

00:27:55.890 --> 00:27:58.710
처리량이 증가 명확 하 게 일괄 처리 합니다.

00:27:59.460 --> 00:28:04.620
아주 좋은 습관은 항상
있는지의 관점에서

00:28:04.670 --> 00:28:09.260
또는 수신 측 에서도
일괄 처리를 사용 하 여 송신 측입니다.

00:28:09.310 --> 00:28:13.190
사람들에 대 한 부정만 우려
가끔 하는 대기 시간

00:28:13.240 --> 00:28:17.490
고를 수 있는 방법을 살펴보겠습니다.
하지만 하지 너무 많은 영향을 받습니다.

00:28:17.540 --> 00:28:18.880
하는 방법에 대 한 설명입니다.

00:28:21.250 --> 00:28:24.830
비동기 일반적 항상이 고
것이 가장 좋습니다. 항상

00:28:24.880 --> 00:28:28.620
사용 가능 합니다. 제외 하
연결 하 시겠습니까

00:28:28.670 --> 00:28:31.760
마주 보는 호출 횟수입니다. 있습니다
좁게는를

00:28:31.810 --> 00:28:34.720
하면 무한 루프
통화 잘 방법

00:28:34.770 --> 00:28:37.660
서비스 버스는 시나리오에 도움이 됩니다.

00:28:40.160 --> 00:28:44.110
마지막으로 우리가 볼 이진
상당히 높은 프로토콜

00:28:44.160 --> 00:28:47.980
얻을 수 있는 처리량
이러한 프로토콜을 단지

00:28:48.030 --> 00:28:54.290
AMQP 프로토콜 개발
효율성을 염두에

00:28:55.260 --> 00:28:58.750
흐름 제어 및 모든 것
프로토콜 계층에

00:28:58.800 --> 00:29:03.950
장점이 많은 참조 자체
표시 합니다. 따라서 실제로 사용자가 직접

00:29:04.000 --> 00:29:08.550
숫자가 표시 됩니다. 일부 실행
숫자를 비교할 수 있도록

00:29:08.600 --> 00:29:10.090
자신에 대 한 이입니다.

00:29:20.030 --> 00:29:24.820
여기 있는 몇 가지 코드
메시지를 보낼 것입니다.

00:29:26.190 --> 00:29:28.970
내가 나눈 것을 볼 수 있습니다.
세 부분으로 위로.

00:29:29.850 --> 00:29:32.930
첫 번째 동기화 보내기 수행 하 고 있습니다.

00:29:33.690 --> 00:29:38.660
다음은 주요 선입니다. 각각에 대 한
메시지는 qClient 수행 및 보내기

00:29:38.710 --> 00:29:44.060
메시지에서. 이것은 매우 동기화
호출 합니다. 가중치를 완료 한입니다.

00:29:44.110 --> 00:29:48.030
승인 되기를 기다립니다.
서버에서 다시 연결

00:29:48.080 --> 00:29:51.200
전체 클라이언트에서 다시
루프 한 후 이동 합니다.

00:29:52.910 --> 00:29:56.650
두 번째는
비동기 방식입니다.

00:29:57.900 --> 00:30:02.780
만드는 기본적으로 위치
이러한 모든 비동기 작업

00:30:03.350 --> 00:30:04.470
작업을 보냅니다.

00:30:05.700 --> 00:30:09.150
다음을 기다리는 모든
작업을 완료 합니다.

00:30:11.410 --> 00:30:15.170
마지막으로 한 일괄 처리 하 고
순서가 지정 된 송신 및 I 호출

00:30:15.220 --> 00:30:19.430
때문에 보내기 일괄 Async를 사용 하 여 일반적으로
낼 사람

00:30:19.480 --> 00:30:22.840
밝히는,이 봐, 시나리오를 사용 하 여
Async 손실 되는 순서입니다. 이해가 안

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
나타나면 지금의
큐 개수는 0입니다.

00:30:48.910 --> 00:30:52.560
내 메시지 수를 설정 했습니다.
100의 적은 수입니다.

00:30:53.660 --> 00:30:54.780
이제 실행 합니다.

00:30:57.310 --> 00:30:59.530
얻을 정도.

00:31:00.250 --> 00:31:04.670
보내기 과정 우선
동기화 합니다. 따라서 동기적으로 수행

00:31:04.720 --> 00:31:09.020
모든 랩톱에서 100 호출 된
서비스를 다시 합니다.

00:31:09.550 --> 00:31:13.970
측면에서 10 초 걸렸습니다.
하. 표시 하 고

00:31:14.020 --> 00:31:18.360
다시, 확인 항상 우리가
메시지 수와이 야

00:31:18.410 --> 00:31:21.860
이제 100 수 있습니다. 모든 백
메시지가 여기에 대 한.

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
비동기 일괄 처리와 비교

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
100 메시지를 제공 합니다.
백업 합니다. 이 모든 것은

00:34:28.880 --> 00:34:32.660
기반 네트워크에 대 한 가장 최적의
경쟁 중인 소비자

00:34:32.710 --> 00:34:35.970
다른 노드의 수에 따라
메시지를 가져와서는

00:34:36.020 --> 00:34:38.800
최적의 일괄 빌드
한을 보냅니다.

00:34:39.610 --> 00:34:43.320
이 고 있는 표시는
계속 호출 되는 외부 루프

00:34:43.370 --> 00:34:47.620
안 도달할 때까지 일괄 처리를 받을
수백 개의 메시지입니다. 원합니다

00:34:47.670 --> 00:34:51.430
이 일괄 처리 계산까지 할
난 100 메시지에 도달합니다.

00:34:53.920 --> 00:34:59.030
여기서의 건을
잠금된 토큰 보관만.

00:34:59.080 --> 00:35:01.160
메시지에서 수행 됩니다.
유지할 필요가 없습니다.

00:35:01.210 --> 00:35:04.440
전체 메시지입니다. 내가 지금까지 사용 된
내가 처리 한 메시지를

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
모든 100 받을 하려고...
먼저 수백 개의 메시지

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
10 전송 하는 대신에 앞서
18 초 걸리는 send에 대 한

00:36:24.270 --> 00:36:28.760
이러한 메시지 및 완료
하. 심지어 좋지 않습니다.

00:36:30.090 --> 00:36:35.330
비동기 사용 하 여 여러 작업을 한 것 때문에
동시에 그 중 이제 다운을 가져오기

00:36:35.380 --> 00:36:38.880
2.8 초에 대 한. 이제,
이러한 숫자는 단지...

00:36:39.410 --> 00:36:43.230
솔트의 입자를 사용 하 여 이동
여기에 네트워크에서 실행 됩니다.

00:36:43.940 --> 00:36:47.470
규모만 볼 수 있지만
차이입니다. 볼 수 있습니다.

00:36:47.520 --> 00:36:49.620
어느 정도 개선.

00:36:50.830 --> 00:36:52.580
이제 살펴보겠습니다
일괄 처리에서 발생합니다.

00:36:55.730 --> 00:37:00.720
우리 다시입니다. 우리는 수 동일
로 거의 특징

00:37:00.770 --> 00:37:04.590
모든 100 0.1 초
작업 하는 것을...

00:37:05.410 --> 00:37:07.930
사용 하 여 서
여기에 배치 합니다.

00:37:11.380 --> 00:37:16.640
지금, 뿐만 아니라 볼 수 있습니다 이러한 모든
여기 서비스의 장점

00:37:16.690 --> 00:37:21.680
버스 실제로 사용 하면 아주 쉽게
에이 코드를 작성 합니다.

00:37:21.730 --> 00:37:26.700
살펴본 코드는 없는 매우
복잡 한 있지만 실제로

00:37:26.750 --> 00:37:29.280
이 한 단계 더 발전 되 고,
쉽게 합니다.

00:37:30.200 --> 00:37:33.470
따라서 예는..., 그런데 오
것에서 여기에서

00:37:33.520 --> 00:37:37.280
300 메시지 메시지
여기가 새로 고칠 경우이

00:37:37.330 --> 00:37:41.920
나타내는 0으로 돌아가기를
내가 거 놓여 있지. 이러한 모든 300

00:37:41.970 --> 00:37:43.380
메시지가 처리 되었습니다.

00:37:47.270 --> 00:37:54.910
확인 합니다. 때문에 메시지에 알아 보겠습니다
Api에서 이자

00:37:54.960 --> 00:37:57.880
시간이 될 것 같아 속도
잠시 여기를.

00:38:00.480 --> 00:38:04.820
차이 볼 수 있도록
동기화, 비동기, 및 일괄 처리를 하 고

00:38:04.870 --> 00:38:10.330
해당 [Indiscernible] 항상 사용 하 여 일괄 처리 하는 것이 좋겠습니다. 처리량에 대 한 다음 으로입니다.

00:38:10.380 --> 00:38:14.100
분할 된 큐와 토픽
지금 SDK 2.2 릴리스 되었습니다.

00:38:15.680 --> 00:38:19.590
큐 항목과 기본적으로 분합니다
한 큐 및 파티션

00:38:19.640 --> 00:38:21.830
여러 처리 노드 간 것입니다.

00:38:23.240 --> 00:38:26.950
뿐만 아니라 이렇게 하면 훨씬 더
처리량 전원

00:38:27.000 --> 00:38:31.900
더 많은 메시지를 처리할 수 있지만
그 많은 스토리지 용량을 제공합니다.

00:38:32.410 --> 00:38:35.820
기능을 제공
많은 큐. 이 통해

00:38:35.870 --> 00:38:38.170
하면 보다 유연 하 게 하는 기능입니다.

00:38:39.270 --> 00:38:42.290
파티션 하나를 사용할 수 없는 경우
다른 파티션으로 계속

00:38:42.340 --> 00:38:43.580
메시지를 처리 합니다.

00:38:44.640 --> 00:38:49.270
따라서 분할 큐 및 여가
대부분의 시나리오를 제공 합니다.

00:38:49.320 --> 00:38:52.990
수 작업을 훨씬 더 나은 처리량
가용성과 복원 력

00:38:53.040 --> 00:38:58.570
특징을 참조 하십시오. 부재 중 상자.
너무 쉽게 만들 수 있기를

00:38:58.620 --> 00:39:02.700
파티션 큐 사용
것으로 권장 하는 것

00:39:02.750 --> 00:39:06.470
이 항상 사용 합니다. 마찬가지로 항상 사용
이러한. 다음에 사실,

00:39:06.520 --> 00:39:11.000
SDK 버전, 우리는 트랙을
그 기본을 기본적으로

00:39:11.050 --> 00:39:13.380
큐를 만들 때 볼 수 있겠지
분할 된 큐를 가져옵니다.

00:39:15.690 --> 00:39:20.650
이제 인식 해야 할 필요가
수행할 때 수행 되는 작업

00:39:20.700 --> 00:39:22.590
큐를 통해 파티션을.

00:39:24.060 --> 00:39:26.530
세션을 사용 하지 않을 경우 것
세션에 대 한 많은 이야기

00:39:26.580 --> 00:39:30.340
자세히 경우에만 사용 하지 않는
세션 다음 본질적으로

00:39:31.060 --> 00:39:33.050
되어야 할...

00:39:34.220 --> 00:39:38.380
주의 해야 하는 메시지
표시 될 순서 대로

00:39:38.430 --> 00:39:41.830
이제 기본적으로 할 수
다른 파티션으로 이동 합니다.

00:39:41.880 --> 00:39:46.770
파티션을 사용할 수 없는 경우
다음 메시지가 표시 됩니다.

00:39:46.820 --> 00:39:47.720
순서가 있습니다.

00:39:48.460 --> 00:39:51.270
주의 해야 할 것입니다.
세션을 사용 하는 경우

00:39:51.320 --> 00:39:54.720
에 대해 설명 하는 다음
모든 순서 지정 의미 체계

00:39:54.770 --> 00:39:56.100
완전히 유지 됩니다.

00:39:57.120 --> 00:40:02.330
잘 방법. 으로 표시
코드는 여기에 언제 든 지

00:40:02.380 --> 00:40:05.590
큐가 만드는 단 하나의
EnablePartitioning 속성입니다.

00:40:05.640 --> 00:40:08.720
오늘은 기본적으로 false로 설정 됩니다.
다음에서 말했듯이

00:40:08.770 --> 00:40:10.040
SDK 것 true입니다.

00:40:10.780 --> 00:40:13.750
지금 있는 설정 바로 해야 합니다. 에 의해
모르는 방법으로 어떻게 하면

00:40:13.800 --> 00:40:18.770
사람들이 내 철학 이지만 일반적으로 마십시오.
일반적으로 복사 되지 않습니다.

00:40:18.820 --> 00:40:20.730
PowerPoint에서 볼 수 있는 코드입니다.

00:40:21.330 --> 00:40:24.470
에 대해서 작동 하는 잘 모르겠습니다.
넌 트는입니다. 사용 안 함, 항상 복사

00:40:24.520 --> 00:40:28.150
때문에 PowerPoint에서 볼 수 있는 코드
가장 간단한 수 있습니다.

00:40:28.590 --> 00:40:32.710
기본 종류의 모든 사람이 어떤 코드를
그곳 넣을 수 있습니다. 이에

00:40:32.760 --> 00:40:35.500
경우는 문제가 있습니다. 방금 설정한
속성을 하므로는 문제가 되지 않습니다.

00:40:35.550 --> 00:40:38.540
그러나 코드를 작성 하면 항상 설명 했습니다
powerpoint에서에 복사 하지 마십시오.

00:40:40.650 --> 00:40:46.660
따라서 연결 처리량입니다. 지금까지 설명 했던
에 대 한 보낸 사람. 앞서 설명한 것

00:40:46.710 --> 00:40:50.290
이진 연결을, 방법
정말 중요 합니다. 가지

00:40:50.340 --> 00:40:55.090
경우에 따라 전송 될 수 있습니다
매우 fat 파이프를 사용합니다.

00:40:55.660 --> 00:40:58.340
것으로 생각 하면 백 엔드 있으므로
메시지 큐에서에서 하려고합니다.

00:40:58.390 --> 00:41:03.370
원하는 로그의 톤을가지고
밀어넣기 및 등입니다.

00:41:04.400 --> 00:41:08.450
일부 지점에도 더 만들기
실제 TCP 연결 될 수 있습니다.

00:41:08.500 --> 00:41:12.630
한 것이 좋습니다.
이렇게 쉽게. 각 메시지

00:41:12.680 --> 00:41:16.220
클래스 팩터리 인스턴스의
인스턴스 메시징 팩터리

00:41:16.270 --> 00:41:18.390
하나의 PCP 연결에 해당합니다.

00:41:19.390 --> 00:41:22.550
더 많은 수의 큐 클라이언트
만드는 것과

00:41:22.600 --> 00:41:25.680
같은 공장 처럼 설명 했습니다 해제
하는 멀티플렉싱 모든

00:41:25.730 --> 00:41:31.430
동일한 TCP 소켓을 통해 연결 합니다.
따라서 더 많은 메시징 팩터리를 만듭니다.

00:41:31.480 --> 00:41:33.700
자세한 메시지를 작성 하는 경우
팩토리를 얻을 수 있습니다만 더

00:41:33.750 --> 00:41:38.720
파이프 및 더 많은 데이터를 처리할 수 있습니다
통해 있으므로 중요시

00:41:38.770 --> 00:41:42.540
해당 합니다. 연결 수준 회복
기본 제공 됩니다. 따라서 한 번만 하면

00:41:42.590 --> 00:41:46.140
메시징 팩터리를 만들 수
삭제할 필요가 없습니다.

00:41:46.190 --> 00:41:49.320
연결이 중단 되 면 우리 것
다시 만드는 것입니다. 연결이 중단 되 면

00:41:49.370 --> 00:41:52.740
큐에 게 다시 구축 합니다. 무엇이 든
우리는 다시는

00:41:52.790 --> 00:41:54.860
그럴 수 없습니다
이 작업을 수행 하는 중...

00:41:55.370 --> 00:41:58.030
이 개체를 삭제 하는
고이 개체를 다시 만듭니다.

00:41:58.310 --> 00:42:02.780
단지 많이 만들고 다시 사용
지에 게 필요합니다.

00:42:05.910 --> 00:42:07.540
그렇다면 의문이 세션.

00:42:08.520 --> 00:42:11.670
알려 고 내가 있기 때문에
모든이 보낸 많은

00:42:11.720 --> 00:42:14.910
보낸 사람 모두 멀티플렉싱 및
매우 작은 수로

00:42:14.960 --> 00:42:17.850
대기열은 어떻게
실제로이 처리?

00:42:17.900 --> 00:42:21.110
프레임 워크의 한 식품 종류를 살펴본
하 고는 모든 것

00:42:21.160 --> 00:42:23.460
demultiplex 스트림 하려고 합니다.

00:42:24.720 --> 00:42:26.530
demultiplex 스트림.

00:42:28.490 --> 00:42:33.070
세션은 놀라운 내장
서비스의 기능을 버스

00:42:33.120 --> 00:42:37.130
기본적으로 큐를 만듭니다.
생각할 수 있으므로 각 세션

00:42:37.180 --> 00:42:40.290
경우 전체 큐 큐로.

00:42:41.480 --> 00:42:44.860
원래 특성 뿐
세션 ID를 설정 합니다.

00:42:44.910 --> 00:42:46.840
그건 하나의 단일 속성
설정 해야 합니다.

00:42:48.090 --> 00:42:51.240
수신기는 위치는
패러다임을 실제로 변경합니다.

00:42:52.050 --> 00:42:56.090
수신기는 이제 더 이상 이동 하 고
말이 봐, 나 한 테 줄 다음 메시지.

00:42:56.140 --> 00:42:59.670
수신기의 말 다음 꿀
세션입니다. 다음 꿀

00:42:59.720 --> 00:43:02.690
일부 메시지를 하위 큐
및 처리에 다루겠습니다.

00:43:02.740 --> 00:43:06.760
주문 처리를 사용 하 여 보겠습니다
특정 상태를 저장 하는

00:43:06.810 --> 00:43:10.600
에 대 한 수신기를. 그렇게 생각 하면
수많은 장치에 대 한

00:43:10.650 --> 00:43:13.290
지금 생각 하면 하는 장에
큐를 사용할 수 있습니다 이러한 모든

00:43:13.340 --> 00:43:18.620
하위 큐 및 저장소만
큐 상태입니다. 따라서, 매우

00:43:18.670 --> 00:43:20.410
이런 의미에서 매우 강력 합니다.

00:43:21.050 --> 00:43:24.400
할 수 있는 작업 시간 고정 설정 작업을 설정 합니다.
말할 수 있는 것입니다.

00:43:24.450 --> 00:43:29.230
지역화 하려는 경우 수신기 하나
장치 1과 100 사이입니다. 따라서 그

00:43:29.280 --> 00:43:32.810
서 1 세션에 대 한 문의
-100을 고정 하 고

00:43:32.860 --> 00:43:33.440
하 하.

00:43:35.000 --> 00:43:39.680
그런 다음 물론 있습니다. 저장할 수 있습니다.
상태입니다. 설명 하도록는

00:43:39.730 --> 00:43:43.490
이 대 한 코드입니다. 기본적으로
quire 세션을 경우 true

00:43:43.540 --> 00:43:45.270
큐를 만들면.

00:43:45.790 --> 00:43:49.670
송신 측에서 해야
세션 ID 속성을 설정 합니다.

00:43:50.530 --> 00:43:55.720
쪽에 나타날 모든의
같은 종류의 매개 변수 적용

00:43:55.770 --> 00:43:59.840
살펴본, 승인 메시지와 같은
세션을 수락 마십시오

00:43:59.890 --> 00:44:03.730
세션 ID 사용 하 여 메시지 또는 시작
릴리스 단지 했습니다 무엇

00:44:03.780 --> 00:44:08.760
아주 간단한 방법
할 수 있는

00:44:11.810 --> 00:44:13.010
세션 수신기입니다.

00:44:14.920 --> 00:44:18.080
따라서 세션 보낸 열.

00:44:18.970 --> 00:44:21.810
일괄 처리를 이미 실현 한 우리
보내는 가장 좋은 방법은

00:44:21.860 --> 00:44:25.740
모든 보낸 사람에 게는 그렇게
각 세션에 대해이 ID는

00:44:25.790 --> 00:44:30.240
많은 메시지를 보낼 수 있는
세션 ID + 1입니다. 따라서이 경우

00:44:30.290 --> 00:44:33.480
세션 ID를 보내는 것 같아
두 개의 메시지가 있습니다. 세션 경우

00:44:33.530 --> 00:44:36.070
두 개의 ID를 보낼 거 야,
3 메시지와 등등입니다.

00:44:37.350 --> 00:44:38.920
따라서 보낸 사람이 바로 시작 하겠습니다.

00:44:39.880 --> 00:44:43.910
이 큐를 보면 여기 고
메시지 큐 샘플

00:44:44.580 --> 00:44:49.140
이 큐를 만들었을 때의
하나의 속성만 추가 설정

00:44:49.190 --> 00:44:55.090
이런 것에 세션 속성을 필요 합니다.
유일한 차이점은 했습니다.

00:44:55.670 --> 00:44:59.940
이제 이동할 때에이 특정
큐를 가지는지

00:44:59.990 --> 00:45:02.440
수 속성

00:45:08.230 --> 00:45:09.410
보기는...

00:45:11.710 --> 00:45:16.480
세션 속성은 필요 합니다.
false입니다. 것은 아닙니다.

00:45:16.530 --> 00:45:20.780
확인 합니다. 그런 다음이 큐를 삭제 하겠습니다.

00:45:24.670 --> 00:45:34.390
세션 샘플 메시지를 만듭니다.

00:45:37.280 --> 00:45:38.780
세션이 필요 합니다.

00:45:45.040 --> 00:45:47.020
에 내 보낸 것입니다.

00:45:51.490 --> 00:45:53.840
따라서 메시지를 보내는 시작 됩니다.

00:46:09.430 --> 00:46:18.880
찾는 것은 아마도
지금 큐 이름입니다.

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

00:46:20.870 --> 00:46:27.580
>> 오가 나? 메시지 세션...
아, 그렇지.

00:46:29.640 --> 00:46:36.750
완벽 한. 변경 해 드리죠
메시지 세션 예제로 설정 합니다.

00:46:39.450 --> 00:46:40.630
정말 고마워요입니다.

00:46:42.100 --> 00:46:43.360
이제이 항목을 실행 해 보겠습니다.

00:46:46.770 --> 00:46:49.710
자 됐어요. 보내는 모든 것
메시지입니다. 이제 설명 해 보겠습니다

00:46:49.760 --> 00:46:54.350
수신 코드를
이 처럼 보입니다.

00:46:55.510 --> 00:46:59.710
이 새로운 API는 하는
방금 출시 했습니다, 고 대

00:46:59.760 --> 00:47:02.010
메시지 처리 API입니다.

00:47:03.430 --> 00:47:07.500
Azure 작업자 역할에서
너무 변경 하겠습니다.

00:47:10.890 --> 00:47:14.690
Azure 작업자 역할에서 대 여
start 메서드를 할 수

00:47:14.740 --> 00:47:19.540
큐가 있는 경우 동일한 바로 확인
하 고는 qClient을 만듭니다.

00:47:20.250 --> 00:47:24.120
실행된 규칙에 주의
더 간단한 코드를 가져옵니다.

00:47:25.610 --> 00:47:29.270
이 모든 것은
하나의 레지스터 호출 합니다.

00:47:29.900 --> 00:47:32.770
말할 세션 처리기를 등록 합니다.

00:47:33.670 --> 00:47:36.500
와 게 다입니다. Deceive 없음
루프를 쓰려고 합니다.

00:47:37.120 --> 00:47:38.950
관리할 수 없는 수명입니다.

00:47:39.580 --> 00:47:43.920
모두 처리 하 여
클라이언트 라이브러리를.

00:47:43.970 --> 00:47:48.540
모두 캡슐화
거 어떻게의 논리

00:47:48.590 --> 00:47:53.790
하나는 단일 스트림 처리
클래스는 세션 처리기입니다.

00:47:54.700 --> 00:47:57.450
이 클래스를 통해 살펴보겠습니다.
고 무엇 여기를 참조 하십시오.

00:47:58.700 --> 00:48:02.660
가장 먼저 수행할 때입니다.
실제로 메시지가 무엇입니까?

00:48:05.430 --> 00:48:09.430
메시지에서 바로 인쇄
필자는 메시지와

00:48:09.480 --> 00:48:10.870
난 내 수 증가 시.

00:48:11.610 --> 00:48:15.320
이 클래스에서 수행 됩니다.
전용 멤버입니다.

00:48:15.370 --> 00:48:19.860
여기와 값만 저장 하는.

00:48:21.090 --> 00:48:22.960
따라서 개수 설정

00:48:24.710 --> 00:48:28.550
0과 같은 수를 기억 하 고
내 모든 처리 때문입니다.

00:48:29.270 --> 00:48:34.550
닫힌된 세션에 세션 종료
있을 때 라고 하지

00:48:34.600 --> 00:48:38.750
자세한 메시지를 사용할 수
세션 또는 수에 도달 했습니다.

00:48:38.800 --> 00:48:42.360
사용자 최대 통화 수입니다. 설명 했던
얼마나 많은 대 한 동시에

00:48:42.410 --> 00:48:43.630
보유 하 고 있습니다.

00:48:44.260 --> 00:48:48.230
최대값에 도달한 경우
동시성 수 수

00:48:48.280 --> 00:48:53.040
세션을 처리 하는 데이 라
해당 세션을 닫고 열기

00:48:53.090 --> 00:48:57.610
메시지 내용에 따라 새 세션
사용할 수 있습니다. 따라서 닫기

00:48:57.660 --> 00:49:00.700
지금까지 내가 말할 수 있는
한 일련의 메시지를 참조

00:49:00.750 --> 00:49:03.900
이 특정에 대 한 처리를
세션 및 지금 내가 해야

00:49:03.950 --> 00:49:05.580
상태를 저장 합니다.

00:49:07.140 --> 00:49:10.730
여기 모두 수행 하 고 볼 수 있습니다.
호출 상태 설정 및 가져오기

00:49:10.780 --> 00:49:15.250
세션 의심 되는 상태입니다.
이들은 기본적으로 스트림입니다.

00:49:16.050 --> 00:49:20.770
Count 값을 바로 저장
때마다 세션이 닫힙니다.

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
단지 간단한 세션 하나에 대 한
없는 세션 및 I

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
참고 댄 했습니다...

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
정책 이름을 여기에 액세스 합니다. 때문에
해당 웹 사이트 예제는 I

00:53:42.470 --> 00:53:45.240
내가 받기, 호출 하는 경우를 보여 주었습니다.
이 실제로

00:53:45.290 --> 00:53:49.650
실패 하기 때문에 지금 당장만
이 권한 부여 보내기입니다.

00:53:50.890 --> 00:53:54.310
하지만 쉽게 이동 하 고 듣기 추가
해당 규칙을 인증 합니다.

00:53:55.730 --> 00:53:56.440
저장을 누르십시오.

00:53:57.340 --> 00:53:58.640
속담 큐 업데이트 합니다.

00:53:59.190 --> 00:54:00.050
이제 모든

00:54:01.700 --> 00:54:06.780
이 대해 생성 된 토큰
수 있는 규칙

00:54:06.830 --> 00:54:11.480
않으면 모두 주고받을 수 있습니다. 이제
클릭 수신 하 고 여기에 이동할 수 있습니다.

00:54:12.880 --> 00:54:15.660
물론 그렇지. 다음과 같은 사람들
가 메시지를 보낼 했습니다.

00:54:15.710 --> 00:54:18.320
이제 채팅 세션으로 이동
말씀 터치를 유지할 수 있습니다.

00:54:18.370 --> 00:54:20.210
다른 온라인.

00:54:21.490 --> 00:54:24.220
따라서 공유 액세스 서명는 바로,
매우 가벼운, 너무

00:54:24.270 --> 00:54:28.290
사용 하기 쉬운 모델입니다. 하는 경우
점프는 SDS 종류의 모델에

00:54:28.340 --> 00:54:35.540
ACS는 완벽 하 게 지원 됩니다. ACS는
여전히 오른쪽 옵션이 없습니다.

00:54:35.590 --> 00:54:37.660
큐를 사용 하 여 방금 알아보았습니다.


00:54:39.580 --> 00:54:43.390
너무 요약, 살펴본 프로토콜입니다.
왜 관련 됩니다.

00:54:43.650 --> 00:54:47.970
스트림의 상관 관계를 통해 차
필요 하지 않은 이유는

00:54:48.020 --> 00:54:50.860
장치 큐 만들기
관리

00:54:50.910 --> 00:54:53.980
백만 큐입니다. 하지만 이렇게 하지 않으면
사용할 수 있는 코드 작성

00:54:54.030 --> 00:54:57.760
가 너무 매우 복잡 합니다. 따라서
모두는 아주, 아주

00:54:57.810 --> 00:55:00.840
쉽게 서비스와 지원
버스 메시징입니다.

00:55:01.900 --> 00:55:05.320
큐, 항목, 구독입니다.
전부에 대칭 됩니다.

00:55:05.370 --> 00:55:08.990
모든 측면에서 살펴본
큐를 사용 하 여 작동 하는 것

00:55:09.040 --> 00:55:12.280
정확 하 게 동일한 방식으로 작동 하는 세션
항목 및 구독

00:55:12.330 --> 00:55:16.290
및 필터입니다. 구독을 만들 때
필요한 것만 언급

00:55:16.340 --> 00:55:18.360
세션에는 여부를 true로.


00:55:21.680 --> 00:55:22.910
수신기에서 조정 합니다.


00:55:27.210 --> 00:55:30.850
Visual Studio이 과제
톤의 시작

00:55:30.900 --> 00:55:34.520
IDE에 개 한 후
이동 및 변경 하 여

00:55:34.570 --> 00:55:37.840
고 수의 프로필
모두 동기화를 클릭 합니다.

00:55:38.640 --> 00:55:41.980
이동 통신 예정 입니까
이러한 모든 인스턴스에?

00:55:42.490 --> 00:55:45.600
동적 인스턴스 들
너무 때문에 VS 수

00:55:45.650 --> 00:55:49.910
인스턴스 시작 되 다
요일에 따라.

00:55:49.960 --> 00:55:53.530
실제로 통계 들
그런데, 표시 합니다.

00:55:53.580 --> 00:55:57.170
수요일까지 더 이상 열
것이 금요일에 열.

00:55:57.220 --> 00:56:04.740
따라서 생산성은 금요일까지 tanking. 
 어쨌든 지금 다시 문제 수 있습니다.

00:56:04.790 --> 00:56:07.440
항목을 해결할 수 있는 수
수백만 및 수백만의

00:56:07.490 --> 00:56:11.110
끝 지점입니다. 모든
자신의 하나를 수신 하

00:56:11.160 --> 00:56:14.070
메시지에 대 한 구독입니다.

00:56:15.150 --> 00:56:19.140
이러한 메시지가 생성 되는지 여부입니다
기반으로 하 여 백 엔드

00:56:19.190 --> 00:56:22.840
시스템의 일부 변경 또는
보내려는 등

00:56:22.890 --> 00:56:26.270
원하는 사용자에 게 알림을
Windows에 게

00:56:26.320 --> 00:56:30.510
알림이 있는 경우 7 상자
서비스입니다. 알리고 싶은

00:56:30.560 --> 00:56:34.520
그 말한 봐 새 업데이트가
Visual Studio 사용할 수 있는

00:56:34.570 --> 00:56:39.970
다운로드 이동 합니다. 특히 나
적은 대기 시간 정렬 지정

00:56:40.020 --> 00:56:43.890
위치를 변경 하는 경우 파이프
다른 VS 인스턴스 하나에

00:56:43.940 --> 00:56:45.430
VS 인스턴스를 동기화합니다.

00:56:46.140 --> 00:56:48.340
항목을 sues 수 및
알림 신청입니다.

00:56:49.760 --> 00:56:52.470
지금 생각 하면 개념상
항목 당 VS 사용자입니다.

00:56:53.200 --> 00:56:58.800
구독 당 VS 인스턴스
항상 MQP를 사용 하 여 연결 합니다.

00:56:58.850 --> 00:57:03.260
MQP 연결을 많이 제공 하므로
있는 효율성

00:57:03.310 --> 00:57:07.830
수백만 및 수백만의 우리에
동시에, 매우 섹션

00:57:07.880 --> 00:57:12.350
만으로 매우 낮은 오버 헤드,
가끔 알림.

00:57:12.380 --> 00:57:14.840
알림에 대 한 차이입니다.
그들은 아주 가끔

00:57:14.890 --> 00:57:18.080
특성. 놀라운 얼마나 자주?
색 프로필 변경

00:57:19.770 --> 00:57:20.260
하루에?

00:57:20.310 --> 00:57:22.960
주 시겠습니까? 바라 건 대 모든 일입니다.

00:57:23.790 --> 00:57:25.160
뭐, 분위기에 따라 다릅니다.

00:57:26.260 --> 00:57:29.100
하지만 자주 발생 하지 않습니다.
업데이트는 얼마나 자주 있는지

00:57:29.150 --> 00:57:33.660
? 자주 하지 않습니다. 하지만
아직 이러한 BNS

00:57:33.710 --> 00:57:38.290
사용할 수 있는 인프라
있는 연결 수

00:57:38.340 --> 00:57:41.780
때문에 해당 알림을 기다리는
때 해당 알림

00:57:41.830 --> 00:57:45.170
이 원하는 것
인스턴트입니다. 오른쪽 클릭

00:57:45.220 --> 00:57:46.040
다음 가지.

00:57:51.000 --> 00:57:54.990
정말 생각해 야 여기
에 대 한 생각해 야 하 고

00:57:55.040 --> 00:57:59.320
에 대 한 메시지 흐름. 때문에 오늘
항목 수 최대 2000

00:57:59.370 --> 00:58:03.170
가입 하 고 생각 될 때
수에 대 한 규모의

00:58:03.220 --> 00:58:07.420
수신자의 2000 수 있습니다.
또는 2000 충분할 수도 있습니다.

00:58:07.980 --> 00:58:10.910
Visual Studio 대 한 생각
한 사람이 더 많은 것

00:58:10.960 --> 00:58:13.700
2000 개 보다
IDE를 실행 하는

00:58:16.030 --> 00:58:20.210
다음 불가능 합니다. 아마 모르는
수 있지만 발생 하지 않습니다.

00:58:20.520 --> 00:58:24.520
이 게 주제 당 VS 사용자
하지만 잘 될 수 있습니다.

00:58:24.570 --> 00:58:27.660
모든 사용자가 수신 하는 수
같은 피드에. 하려면

00:58:27.710 --> 00:58:30.790
보내는 사람이 보낼 수...
단일 메시지를 보낼

00:58:30.840 --> 00:58:34.790
모든 사용자에 게 광범위 한 캐스트입니다. 그렇다면
항목에 연결 하려고 합니다.

00:58:35.250 --> 00:58:38.680
및 전달 자동 사용 하 고 있습니다.

00:58:39.850 --> 00:58:43.350
많은에 이동 하겠습니다.
이러한 패턴 정보

00:58:43.400 --> 00:58:45.280
필터를 설정 하는 방법에 대 한 조건입니다.

00:58:45.800 --> 00:58:48.520
이들 모두는 msdn.com 샘플입니다.

00:58:49.130 --> 00:58:55.380
이 샘플 이라고
목록입니다. 다음은 호출 샘플

00:58:55.430 --> 00:58:58.720
게시를 구독 합니다. 전체 코드
이 사용할 수 있습니다.

00:58:58.770 --> 00:59:02.570
정말 말씀을 활용 장려
보기를 다음이 항목으로

00:59:02.620 --> 00:59:06.190
실제로 이러한 리치를 정한 수 있습니다.
흐름은 어디 모든 메시지

00:59:06.240 --> 00:59:09.930
모든 울림 없습니다
200만 사람들이 고

00:59:09.980 --> 00:59:14.280
매번 삭제 합니다. 얻을 수합니다 있습니다.
많은 것 들을 한 사람에 게 회람

00:59:14.330 --> 00:59:18.680
사람, 또는 케이스의 무한 한 종류의
여기서 주소만 작성 합니다.

00:59:18.730 --> 00:59:19.660
같은 전자 메일입니다.

00:59:20.190 --> 00:59:23.130
말씀와 마찬가지로 경우에
먼저 말하면 메시지

00:59:23.180 --> 00:59:24.230
쉼표, 초입니다.

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
말 처럼 배달 못한 편지 큐
하면 정말 수 있습니다. 하는 데 도움이

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
서비스 버스를 throw 하는 모든 메시지
임시 속성에는

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
링크의 톤입니다. 자원의 톤입니다.
모두를 액세스할을 수 있습니다.

01:05:41.800 --> 01:05:44.130
정말 고마워요입니다. 사과
에 관계 없이.