WEBVTT

00:00:01.460 --> 00:00:02.340
Buon pomeriggio.

00:00:04.930 --> 00:00:05.880
Come si eseguono persone?

00:00:08.810 --> 00:00:14.600
Buona? Voi ragazzi sono state quasi
alla fine della conferenza.

00:00:15.630 --> 00:00:17.150
Come è l'esperienza
è stato finora?

00:00:17.160 --> 00:00:19.360
[Un applauso]

00:00:19.520 --> 00:00:20.120
>> Bene.

00:00:20.170 --> 00:00:24.940
Awesome. Beh, come si dice, essi
salvare sempre il meglio per ultimo.

00:00:26.240 --> 00:00:32.190
Molto probabilmente non sarà deluso
voi ragazzi. Apprezza

00:00:32.240 --> 00:00:34.450
il rendendo il pomeriggio.

00:00:35.200 --> 00:00:40.360
Mi Abhishek Lal. Gestione programma
con il team di piattaforma Azure.

00:00:41.090 --> 00:00:45.840
Si tratta del team che compila il modello PaaS
servizi quali servizi mobili

00:00:45.890 --> 00:00:48.550
Bus di servizio, cache Azure.

00:00:49.240 --> 00:00:51.080
E servizi multimediali.

00:00:51.720 --> 00:00:54.320
Tali servizi sono ciò che
il team è proprietario.

00:00:54.830 --> 00:00:58.940
E in particolare ho lavorato
per gli ultimi tre più anni

00:00:58.990 --> 00:01:05.100
sulla creazione di messaggistica gestito
pezzi. Si tratta pertanto di code,

00:01:05.150 --> 00:01:08.720
sub pub, sono argomenti,
i pezzi di che.

00:01:09.470 --> 00:01:15.150
Oggi abbiamo parlerò
la messaggistica a livello di scalabilità.

00:01:17.010 --> 00:01:22.030
Le code e degli argomenti. A questo punto sono persone
familiarità con Bus di servizio.

00:01:22.840 --> 00:01:26.920
Esso comprende relay. Affermativo
comprendere l'hub di notifica,

00:01:27.780 --> 00:01:29.010
le code e degli argomenti.

00:01:29.560 --> 00:01:34.840
Pertanto, è sorta di un'intera gamma
dei servizi di messaggistica correlati.

00:01:35.710 --> 00:01:39.560
Questa particolare sessione in corso
a concentrarsi soprattutto su code

00:01:39.610 --> 00:01:46.260
e gli argomenti in modo che sia primario
area. Ma se hai domande

00:01:46.310 --> 00:01:50.120
o qualsiasi elemento che si desidera conoscere
in particolare sull'inoltro o

00:01:50.170 --> 00:01:55.150
hub di notifica, mi piace
rispondere o almeno scegliere

00:01:55.200 --> 00:01:57.410
è nella direzione giusta.

00:01:58.820 --> 00:02:00.930
Vi sono moltissime cose
Si desidera coprire la data odierna.

00:02:01.710 --> 00:02:04.730
Parlare di tutti gli aspetti diversi
di scala. Desidero comunicare con

00:02:04.780 --> 00:02:08.490
sui mittenti e riceventi, e
velocità di trasmissione, tutti i diversi

00:02:08.540 --> 00:02:11.630
modelli di oltre il
specifiche del codice.

00:02:12.390 --> 00:02:14.870
Di come è possibile ottenere scala.

00:02:15.810 --> 00:02:19.040
Verranno pertanto tentare di mantenere un buon ritmo.

00:02:19.640 --> 00:02:24.190
Domande sono molto utili. Se viene visualizzato a me
a partire da tagliare brevi domande

00:02:24.240 --> 00:02:27.780
un po' successivamente, in modo che I
grado di coprire tutti i dati da

00:02:27.830 --> 00:02:31.490
per coprire. Sarà disponibile dopo
la sessione e si può sempre

00:02:31.540 --> 00:02:36.200
applicazioni per me, ma mantenerla interattivo.
Tutto ciò che si dispone,

00:02:36.250 --> 00:02:41.270
i microfoni sono qui.
È sufficiente scorrere e richiamo.

00:02:43.930 --> 00:02:48.720
Parlando di ciò che possiamo del
nuovo oggetto. Ordinamento solo di un aggiornamento

00:02:48.770 --> 00:02:51.210
in che cosa abbiamo abbiamo annunciato il lancio come SDK 2.3.

00:02:52.250 --> 00:02:56.290
È possibile passare a parlare di
le dimensioni di scala.

00:02:56.340 --> 00:03:00.420
Parleremo dei mittenti, destinatari,
velocità effettiva, come è possibile ottenere che.

00:03:01.800 --> 00:03:05.770
E quindi verranno dedicate del tempo su
Considerazioni sulla disponibilità.

00:03:05.820 --> 00:03:07.850
Disponibilità solo su vasta scala ovvero

00:03:09.190 --> 00:03:14.340
capacità di recupero, contratto di servizio migliore e come
Per progettare l'applicazione per

00:03:14.390 --> 00:03:19.520
essere sempre verso l'alto, sempre, in esecuzione
in tale posizione in modo che verranno dedicate alcuni

00:03:19.570 --> 00:03:20.510
ora che.

00:03:22.060 --> 00:03:25.780
In questo SDK 2.3.

00:03:26.330 --> 00:03:28.310
Che cosa è stato appena rilascio?

00:03:29.070 --> 00:03:32.540
Nella sessione di messaggistica. Di membro così via
sono un push il juries

00:03:32.590 --> 00:03:36.970
stile API. Essenzialmente viene
stoccaggio duro lavoro da parte dell'utente

00:03:37.020 --> 00:03:42.960
di scrittura di cicli di C o qualsiasi elemento
di tale complessità e

00:03:43.010 --> 00:03:46.420
offre molto evento-diversa
modello per l'utilizzo dei messaggi.

00:03:46.470 --> 00:03:50.110
Questo è l'API di lato ricevente. Così
Abbiamo che per le sessioni.

00:03:50.160 --> 00:03:52.680
Senza dubbio verranno trattati che
in maggiore dettaglio oggi.

00:03:53.890 --> 00:03:58.440
Modalità di connettività, rilevazione automatica.
Così come è noto, una delle reali

00:03:58.490 --> 00:04:02.520
valore della chiave è stata Azure Bus di servizio
che quando ci si connette

00:04:02.950 --> 00:04:07.700
le code e gli argomenti nella cloud
sistema protetto da firewall

00:04:07.750 --> 00:04:11.450
data center o dal
centri dati di clienti che

00:04:11.500 --> 00:04:16.230
sono seduti dietro ben protetto
specie di firewall, servizio

00:04:16.280 --> 00:04:19.660
Bus è in grado di stabilire connessioni in uscita non solo sulla porta TCP

00:04:19.710 --> 00:04:22.110
ma porta 83 e 443


00:04:23.670 --> 00:04:25.860
mentre le porte TCP sono bloccate.


00:04:26.700 --> 00:04:30.790
Questa funzionalità sarà ancora disponibile
solo se si imposta direttamente

00:04:30.840 --> 00:04:34.230
la directory con la modalità per TCP,
è stato mai la scelta.

00:04:34.910 --> 00:04:38.730
A questo punto nel codice è possibile impostare
viene automaticamente rilevare ed eseguiremo per voi

00:04:38.780 --> 00:04:42.910
vedere automaticamente se è la porta TCP
disponibili, questi verranno utilizzati.

00:04:42.960 --> 00:04:48.410
Se il firewall blocca questo, ci impegniamo a
rilasciarlo a HTTP. In questo SDK

00:04:48.460 --> 00:04:51.560
2.3, che è disponibile
per la messaggistica anche.

00:04:54.390 --> 00:04:57.980
Supporta CORS. Quante persone
sapere cosa è CORS?

00:05:00.360 --> 00:05:04.200
La maggior parte delle persone conoscono. È essenzialmente
consente la facile invio/ricezione

00:05:04.250 --> 00:05:09.370
dal browser. In modo che l'idea è che è
può essere sempre eseguita, è necessario

00:05:09.420 --> 00:05:14.320
STPI con SCTP. Quando si invia
messaggi, ricevere messaggi,

00:05:14.370 --> 00:05:18.920
ma con CORS ora agevola la maggior parte
più facile per i browser e i siti Web

00:05:18.970 --> 00:05:23.650
integrazione back e si procederà
in che in dettaglio oggi.

00:05:25.010 --> 00:05:29.530
Analogamente, ordinamento di aiutare con
prestazioni e di scala

00:05:29.580 --> 00:05:34.760
per i mittenti HTTP, abbiamo
divisione in batch ora disponibili.

00:05:35.200 --> 00:05:43.980
E quindi una paio di prestazioni sul lato client
contatori che è una volta

00:05:44.030 --> 00:05:46.900
veramente portare un'applicazione
che è complessa o si è

00:05:46.950 --> 00:05:50.450
verrà eseguito in ambienti diversi,
potrebbe essere necessario

00:05:50.500 --> 00:05:53.340
eseguire il debug e potrebbe essere necessario un profilo
in modo che sono state aggiunte client

00:05:53.390 --> 00:05:57.890
contatori di prestazioni sul lato dei messaggi inviati
per ogni secondo, lettere al secondo

00:05:57.940 --> 00:06:01.460
e attività simili che possono effettivamente,
maggiore praticità profilo

00:06:01.510 --> 00:06:05.250
che cosa sta messaggistica è di livello
In generale si è opposto

00:06:05.300 --> 00:06:09.020
esegue le occasioni. In modo che quelli verrà
quindi manifesto per tali perf

00:06:09.070 --> 00:06:14.230
contatori come parte del pacchetto NuGet
in, in modo davvero consente

00:06:14.280 --> 00:06:17.550
è possibile eseguire alcune buone il debug.

00:06:20.550 --> 00:06:23.340
Infine, ForwardTo e
per le code di messaggi non recapitabili.

00:06:23.880 --> 00:06:27.380
Deadlettering è un molto, molto potente
funzionalità dove protegge

00:06:27.430 --> 00:06:30.820
Se non esistono non elaborabile siete estremità posteriore
messaggi. Si tratta in genere

00:06:30.870 --> 00:06:34.620
chiamato code non elaborabili in cui si tenta di
Per ricevere un messaggio e il

00:06:34.670 --> 00:06:38.600
messaggio non è valido o non esiste
un bug nel codice in un punto

00:06:38.650 --> 00:06:42.080
su di in un punto qualsiasi del civilizer de
Se non si è in grado di aprire

00:06:42.130 --> 00:06:44.560
il messaggio e gli arresti anomali del back-end.

00:06:45.780 --> 00:06:50.390
Bus di servizio consente all'utente
impostazione di una consegna max

00:06:50.440 --> 00:06:54.420
conteggio che per impostazione predefinita è 10 e il
significa che se è visualizzato

00:06:54.470 --> 00:06:57.660
che ci ha consegnato il messaggio
a è 10 volte e dispone di un

00:06:57.710 --> 00:07:01.310
non è stata completata la
messaggio, verrà trasformato da

00:07:01.360 --> 00:07:03.240
la coda principale nel
coda di messaggi non recapitabili.

00:07:03.870 --> 00:07:07.930
In modo che in questo modo letteralmente le applicazioni
resistenti per impostazione predefinita

00:07:08.190 --> 00:07:12.840
senza dover scrivere un singolo
riga di codice e proteggere

00:07:12.890 --> 00:07:18.660
i server back-end. In tal caso ForwardTo
è la capacità di canale

00:07:18.710 --> 00:07:23.810
i messaggi di creano automaticamente RTF
flusso dei messaggi e ora

00:07:23.860 --> 00:07:30.000
può richiedere un'applicazione che potrebbe avere
6, 8, 10 code e ForwardTo

00:07:30.050 --> 00:07:34.450
per tutti la coda di messaggi non recapitabili in
una coda singola, ovvero

00:07:34.500 --> 00:07:38.530
a questo punto si avrà un'unica posizione per passare a questo punto
ricevere tutti i messaggi non elaborabili

00:07:38.980 --> 00:07:42.340
a prescindere dal numero di code
o argomenti o le sottoscrizioni è

00:07:42.390 --> 00:07:46.280
Questa operazione utilizza di un
necessario aggiungere anche funzionalità.

00:07:47.180 --> 00:07:49.910
Invece, che in
un po' più dettagliatamente.

00:07:51.740 --> 00:07:57.570
Intendeva riassumere rapidamente su ciò che
Abbiamo adottato dall'ultimo aprile

00:07:57.620 --> 00:08:01.400
perché quando si parla oggi
termini di scalabilità e prestazioni

00:08:01.450 --> 00:08:05.780
velocità di trasmissione si vedrà una grande quantità di
Queste funzionalità a cui fa riferimento

00:08:06.180 --> 00:08:08.570
in modo che si desidera evidenziare tali
in termini di se si sta

00:08:08.620 --> 00:08:12.370
Hai già oggi disponibili e
stato per qualche tempo ma

00:08:12.420 --> 00:08:16.250
sono rilevanti anche in tale posizione.

00:08:18.520 --> 00:08:22.290
Serve una cosa a vedere qui
sotto la riga, il primo

00:08:22.340 --> 00:08:26.310
bus di servizio promessa così ultimo
anno che abbiamo fatto il Bus di servizio

00:08:26.360 --> 00:08:28.900
1.1 per il rilascio di Windows server.

00:08:29.580 --> 00:08:33.210
Questo è completamente simmetrico per
coda e argomenti, ovvero

00:08:33.260 --> 00:08:37.450
Se scegliete di SDK 2.1, ad esempio,
che è stato l'ultimo SDK,

00:08:38.470 --> 00:08:42.010
è possibile per uno dei due hit
il servizio o su premise tutti

00:08:42.060 --> 00:08:45.070
le funzionalità disponibili.

00:08:46.760 --> 00:08:51.600
Questa velocità di ordinamento delle release cloud
ogni tre mesi è

00:08:51.650 --> 00:08:55.290
può vedere ogni tre-quattro mesi
e in locale rilasciare in

00:08:55.340 --> 00:08:59.520
almeno una volta all'anno è ciò che cerchiamo
Per mantenere e ripristinare entrambi

00:08:59.570 --> 00:09:02.680
la funzione imposta in parità.

00:09:05.540 --> 00:09:08.740
Quindi, questa è disponibile per
più avanti in termini di riferimento

00:09:08.790 --> 00:09:10.010
le funzionalità.

00:09:12.110 --> 00:09:13.310
Per eventuali domande finora?

00:09:15.820 --> 00:09:16.720
Sì, grazie.

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

00:09:19.950 --> 00:09:23.560
>> Così la domanda è stata: quando verrà
essere l'aggiornamento successivo e dove

00:09:23.610 --> 00:09:28.920
vi aiuteremo ad la 2.3, la versione più aggiornata
funzionalità disponibili.

00:09:28.970 --> 00:09:33.240
In questo momento non dispone di tutte le date
per la condivisione per il servizio successivo

00:09:33.290 --> 00:09:36.320
Rilascio del bus ma non è presente
essere un 2.2 o un 1.2.

00:09:37.800 --> 00:09:42.620
Ma in genere può essere considerato questo
Data di rilascio specifico

00:09:43.340 --> 00:09:46.900
corrisponde alla versione di Windows Server
in modo che la maggior parte dei casi tentano

00:09:46.950 --> 00:09:51.580
Per allineare in modo con le versioni server
è possibile ottenere la massima piattaforma

00:09:51.630 --> 00:09:55.010
i vantaggi in modo siamo assicurati di che avere
più server con le più recenti

00:09:55.060 --> 00:09:59.310
clustering con la gestione di più recente
e Cancella e tutto il contenuto.

00:09:59.360 --> 00:10:03.610
Si supponga che in genere sufficiente per la Guida
che lo stesso tipo di cadence

00:10:03.660 --> 00:10:05.820
verrà di seguito. Ottima domanda.

00:10:08.920 --> 00:10:13.130
Scalare dal mittente. Iniziamo con
Questo in termini di primo

00:10:13.180 --> 00:10:14.210
aspetto della scala.

00:10:15.570 --> 00:10:18.650
Mittenti è nulla, ma
un punto dove ti

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

00:10:20.000 --> 00:10:22.830
È possibile considerare una serie di scenari
di seguito. Può essere considerato del dispositivo

00:10:22.880 --> 00:10:24.970
telemetria, azioni dell'utente.

00:10:26.630 --> 00:10:31.030
E i sistemi di generazione di eventi
e B a B tipo di scenario.

00:10:31.080 --> 00:10:32.910
Eventi generati.

00:10:33.640 --> 00:10:37.660
Come occuperà di scenari
cui si dispongono di molti di questi

00:10:37.710 --> 00:10:41.620
o forse alcuni di essi con un lotto
di eventi o un lotto di mittenti

00:10:41.670 --> 00:10:45.250
con un'elevata quantità di eventi? Tutti quelli
sono possibili scenari.

00:10:46.830 --> 00:10:50.480
Facciamo si concreta. È possibile
iniziare con uno scenario effettivo

00:10:50.530 --> 00:10:54.510
i clienti che sono di uso di oggi
che è dove è necessario

00:10:54.560 --> 00:10:58.850
raccolta di eventi per l'analisi da
un numero elevato di dispositivi.

00:11:00.370 --> 00:11:05.900
Tali dispositivi potrebbero avere un aspetto familiare
ma si tratta di una coincidenza che

00:11:05.950 --> 00:11:11.000
Verrà confermare né negare.
Può essere qualsiasi dispositivo.

00:11:11.050 --> 00:11:12.350
Può essere qualsiasi dispositivo.

00:11:13.160 --> 00:11:18.850
Ora tutto questo inizia con la
dispositivo è in grado di mettere in coda in

00:11:18.900 --> 00:11:24.250
messaggi, accettare alcuni
gli argomenti o un argomento e push

00:11:24.300 --> 00:11:28.090
una notevole quantità di informazioni
in quel canale

00:11:29.520 --> 00:11:33.640
Se si dispone di un messaggio in un argomento
è possibile pensare che è possibile

00:11:34.710 --> 00:11:39.370
dispone di diversi scenari in cui
si desidera utilizzarlo.

00:11:39.420 --> 00:11:43.330
Analisi in tempo reale o ciò che si
farebbe con il proprio codice è

00:11:43.380 --> 00:11:48.570
diventando realtà molto più frequenti
e diffusi. Persone hanno fatto

00:11:48.620 --> 00:11:53.840
per la sessione di Orleans che
è stato fatto ieri? Beh, se

00:11:53.890 --> 00:11:57.080
è stato fatto, awesome, awesome pezzo
della tecnologia perché si tenta di

00:11:57.130 --> 00:12:02.580
Per risolvere il problema dell'esecuzione del
codice a livello di scalabilità in distribuito

00:12:02.630 --> 00:12:06.190
modo se si utilizzano con
eventi che vengono generati

00:12:06.240 --> 00:12:10.830
da un numero elevato di mittenti e sono
correlare ogni qual modo.

00:12:12.020 --> 00:12:15.930
In che modo è possibile essere certi che questi
sistemi back-end sono separate appropriati?

00:12:15.980 --> 00:12:18.590
Come è possibile essere certi che questi
sistemi back-end sono in grado di

00:12:18.640 --> 00:12:24.640
utilizzare messaggi alla velocità e agire
in modi in cui è affidabile?

00:12:25.950 --> 00:12:29.560
E per cui è possibile inserire gli argomenti in
la parte centrale. Non solo gli argomenti in tal caso

00:12:29.610 --> 00:12:33.440
consentono la memorizzazione nel buffer, come
sarebbe una coda, ovvero

00:12:33.490 --> 00:12:35.950
il back-end può essere eseguito
un paio di ore non

00:12:36.000 --> 00:12:39.060
perdere degli eventi. Gli eventi
ancora successo ma

00:12:39.110 --> 00:12:40.490
inoltre offrono sub pub.

00:12:41.470 --> 00:12:45.530
Vale a dire che se si verificano altri
sistemi che eseguono solo

00:12:45.580 --> 00:12:51.310
stato di verifica, si supponga di inserire
i valori in Azure cavi, o

00:12:51.360 --> 00:12:56.520
che svolgono analisi batch con
collegare la struttura di file

00:12:56.570 --> 00:13:00.330
HDFS e quindi eseguire Hadoop
processi su di esso.

00:13:01.400 --> 00:13:05.850
Oppure mettere altezza si sta
dati in un data warehouse SQL

00:13:05.900 --> 00:13:09.170
e l'esecuzione di query di Business Intelligence
nella parte superiore che.

00:13:09.790 --> 00:13:13.980
Tutti questi sistemi possono andare Cerca
con lo stesso flusso di eventi.

00:13:15.280 --> 00:13:18.350
E non solo lo stesso flusso di eventi,
è possibile osservare eventi

00:13:18.400 --> 00:13:21.780
flusso troppo. Forse la Business Intelligence di lavoro warehouse,
non si desidera utilizzare

00:13:21.830 --> 00:13:25.870
tutti gli eventi. Qualsiasi azione correlata
eventi estranei presenti.

00:13:25.920 --> 00:13:29.420
Appartengono solo per elementi di codice.
È possibile dividere i flussi

00:13:29.470 --> 00:13:30.210
In questo modo.

00:13:32.750 --> 00:13:36.990
E quindi dal back-end, se
che stai leggendo il Azure

00:13:37.040 --> 00:13:41.730
tabelle o il data warehouse SQL,
è possibile generare il bash

00:13:41.780 --> 00:13:43.200
schede madri e analytics.

00:13:44.750 --> 00:13:45.750
Pertanto, una della chiave

00:13:46.970 --> 00:13:49.340
punti di progettazione in questo pacchetto.

00:13:50.180 --> 00:13:52.920
Innanzitutto utilizza argomenti
per la ventola in.

00:13:53.960 --> 00:13:57.730
Ventola in essenziali significa si hanno meno
gli argomenti che si dispongono di periferiche.

00:13:57.780 --> 00:13:59.900
Destra? Che cosa sono, che
potrebbe essere la cardinalità.

00:14:01.080 --> 00:14:03.820
Probabilmente non ci sia
uno. Non ci sia una

00:14:03.870 --> 00:14:07.660
argomento per tutti gli elementi. Si tratta probabilmente di
non si tratta di N. consente di passare

00:14:07.710 --> 00:14:12.220
per essere in qualche punto tra in e come
Descrivere come ottenere

00:14:12.270 --> 00:14:13.860
con tale numero.

00:14:14.410 --> 00:14:18.960
Si prevede di caricare il saldo tra
centri dati per diversi motivi.

00:14:19.320 --> 00:14:22.490
Se si ritiene che su di esso, questi dispositivi
sono effettivamente geograficamente

00:14:23.190 --> 00:14:26.300
distribuito, in modo da rendere
Verificare che la periferica utilizza il

00:14:26.350 --> 00:14:30.740
minore quantità di energia, il più basso
connessione di latenza per consentire

00:14:30.790 --> 00:14:33.770
per raggiungere e accodare i dati.

00:14:35.480 --> 00:14:39.640
Pertanto, è il carico bilanciato tra dati
centri. In modo che il bus è disponibile

00:14:39.690 --> 00:14:45.690
in tutte le regioni di Azure, centri di tutti i dati.
In modo da avere la possibilità

00:14:45.740 --> 00:14:50.730
per diffondere argomenti intorno. In questo punto
non significa che il back-end

00:14:50.780 --> 00:14:53.890
i sistemi devono essere abdicated
su tutti quelli troppo inserito.

00:14:54.880 --> 00:14:58.000
Se fatti, se si ritiene che Hadoop
cluster, è in genere

00:14:58.050 --> 00:15:01.860
non è una cosa in che è necessario replicare
ogni regione in ogni centro dati.

00:15:01.910 --> 00:15:05.890
Ma in questo modo una bassa latenza
endpoint. Da qui è possibile

00:15:05.940 --> 00:15:10.490
raccogliere i dati per cui è in corso
generato. E quindi

00:15:10.540 --> 00:15:14.310
dal back-end. Oltrepassare
per tutte le regioni e

00:15:14.360 --> 00:15:18.450
sottoscrizioni in regioni diverse
e che i dati di correlazione.

00:15:20.910 --> 00:15:23.690
Filtro true per tutte tranne una sottoscrizione,
In questo verticale

00:15:23.740 --> 00:15:27.550
case del cliente, sono effettivamente perché
utilizzo di tutti i loro dati e

00:15:27.600 --> 00:15:31.700
codice traccia dello stato e batch
ma non in Business Intelligence Analytics.

00:15:31.750 --> 00:15:35.900
In modo che tutti e tre questi sono stati effettivamente true
filtri, ma una sola sottoscrizione

00:15:35.950 --> 00:15:39.960
aveva un filtro di riduzione. Che aveva un
filtro che afferma che se si tratta di un gioco

00:15:40.010 --> 00:15:45.060
eventi, quindi abbiamo non interessa
che e ovviamente è possibile eseguire

00:15:45.110 --> 00:15:47.360
analisi in tempo reale e batch.

00:15:49.410 --> 00:15:53.110
Così per questo scenario, ho pensato che
occorre passare in una rapida dimostrazione.

00:15:54.270 --> 00:15:59.080
E Mostra il CORS
supporto delle relative caratteristiche.

00:16:00.290 --> 00:16:05.680
Perché consente una grande quantità di client
raggiungere dal punto di vista

00:16:05.730 --> 00:16:11.600
di essere in grado di coda
messaggi solo utilizzando puro

00:16:13.270 --> 00:16:15.140
HTTP e interessanti.

00:16:15.730 --> 00:16:21.550
Ho un sito Web impostato. Voi ragazzi
possibile raggiungere troppo se si dispone di

00:16:21.600 --> 00:16:25.950
un dispositivo o un elemento. La chiamata
utente file nota si di Azure

00:16:26.000 --> 00:16:28.260
siti Web .NET.

00:16:29.750 --> 00:16:40.510
È qui è molto semplice
JavaScript che sarà

00:16:40.560 --> 00:16:41.160
viene illustrato.

00:16:41.880 --> 00:16:43.280
E le operazioni eseguite

00:16:48.770 --> 00:16:53.470
viene preso i valori di chiave di base
valori di che cos'è il relativo nome

00:16:53.520 --> 00:16:58.790
che cos'è il nome della coda, il nome dello spazio
Scarica la regola di SaaS, il

00:16:58.840 --> 00:17:02.140
autorizzazione di accesso condiviso firma,
Questo è ciò che viene utilizzato

00:17:02.190 --> 00:17:03.800
e la chiave di SaaS.

00:17:04.950 --> 00:17:07.970
E si basa su che è possibile inviare un messaggio.

00:17:14.280 --> 00:17:18.140
Messaggio inviato correttamente. Ecco
esso. Per visualizzare se è

00:17:18.190 --> 00:17:21.380
sono molti e molti dei client browser
o qualsiasi altro client o

00:17:21.430 --> 00:17:25.940
dispositivo che può eseguire solo HTTP puro,
non esiste alcun SOAP qui. Non esiste alcun corso...

00:17:26.900 --> 00:17:31.300
qualsiasi codifica. È possibile inserire il messaggio
proprietà in JSON e quindi

00:17:31.350 --> 00:17:35.930
un modo molto semplice ottenere messaggi
in coda. Vediamo di spiegare

00:17:35.980 --> 00:17:38.170
è il codice per questo sito Web.

00:17:47.070 --> 00:17:52.110
Qui è possibile verificare se sono
eseguire tutte le proprietà avanzate

00:17:52.730 --> 00:17:55.220
o anche le proprietà di base solo molto, molto,

00:17:58.440 --> 00:18:05.280
è possibile inviare tale codice. E
in effetti, la libreria JavaScript

00:18:05.330 --> 00:18:09.370
che viene utilizzato qui, let
Me mostrano che all'utente anche.

00:18:16.200 --> 00:18:22.410
In modo che questa è la pagina web che si
è stato illustrato è ed è possibile vedere come

00:18:35.560 --> 00:18:40.400
semplice realmente l'invio e la
ricezione per questo messaggio è.

00:18:40.450 --> 00:18:44.840
Il protocollo HTTP, l'eliminazione è in realtà
per lo scenario di ricezione.

00:18:45.430 --> 00:18:47.500
Come verrà illustrato più avanti.

00:18:48.120 --> 00:18:56.600
E il put è scenario Invia post,
Spiacenti, per quanto di scenario di invio.

00:18:58.510 --> 00:19:02.420
Ed è possibile

00:19:03.620 --> 00:19:05.210
Me inviare ulteriori messaggi.

00:19:05.810 --> 00:19:09.220
E per mostrare i messaggi
visualizzazione, qui ho Server

00:19:09.270 --> 00:19:12.280
Explorer con il caricamento...

00:19:21.330 --> 00:19:25.310
connessi allo spazio dei nomi. E avere
ha ricevuto una semplice coda in cui

00:19:25.360 --> 00:19:28.770
può vedere adesso vi sono due
i messaggi in coda. Se è necessario eseguire un

00:19:28.820 --> 00:19:35.430
aggiornamento, vengono visualizzati alcuni 14 messaggi. Così
come quando la provenienza dei messaggi in esse

00:19:35.480 --> 00:19:37.840
verrà visualizzato in questa coda.

00:19:48.480 --> 00:19:53.620
Esamineremo lo scenario di ricezione
un po' più termini del

00:19:53.670 --> 00:19:56.920
Client HTTP. E questo è per i client HTTP.

00:19:57.510 --> 00:20:02.200
Ma volevo davvero parlare in modo specifico
sui protocolli.

00:20:02.820 --> 00:20:06.840
Quali sono le considerazioni che
è necessario effettuare prima di decidere

00:20:06.890 --> 00:20:11.460
Se si desidera utilizzare il protocollo HTTP o da utilizzare
il AMQP. Come è noto il servizio

00:20:11.510 --> 00:20:13.930
Bus supporta diversi protocolli.

00:20:15.060 --> 00:20:21.750
HTTP è semplicemente il nostro RKDPI è AMQP
un protocollo standard che I'll

00:20:21.800 --> 00:20:27.620
approfondito e SBMP è l'altro
protocollo proprietario su .NET.

00:20:29.320 --> 00:20:35.000
A questo punto, ciascuno di essi può avere considerazioni perf
e raggiungere considerazioni.

00:20:35.710 --> 00:20:39.950
Quindi, se si dispone di un dispositivo in cui
è molto bassa alimentazione, che potrebbe

00:20:40.000 --> 00:20:44.810
desidera conoscere quale protocollo
implementazione è possibile inserire

00:20:44.860 --> 00:20:49.590
in tale posizione. Se si dispongono di scenari dove
si desidera essere fornitore indipendente,

00:20:50.070 --> 00:20:54.160
è possibile raggiungere considerazioni
detto non acquistare in

00:20:54.210 --> 00:20:57.830
qualsiasi protocollo particolare o l'API
con un unico fornitore. Mi

00:20:57.880 --> 00:21:00.060
utilizzare uno standard aperto come AMQP.

00:21:01.900 --> 00:21:04.390
Talvolta le funzioni variano dal protocollo.

00:21:05.130 --> 00:21:08.000
E la parte che si desidera mettere in evidenza
che va perduto su un lotto di

00:21:08.050 --> 00:21:11.300
chi sono che è prevalentemente
funzionalità sul lato di ricezione.

00:21:11.950 --> 00:21:13.290
Esistono alcuni lato invio

00:21:14.560 --> 00:21:19.100
implicazioni, troppo, la maggior parte del
ora è l'operazione di ricezione dove

00:21:19.150 --> 00:21:23.270
protocolli sono realmente rinviati un
lotto e si vedrà perché, vale a dire

00:21:23.320 --> 00:21:24.240
il caso.

00:21:25.950 --> 00:21:28.810
E quindi in genere sono presenti alcuni
differenze in termini di quota

00:21:28.860 --> 00:21:32.360
il numero di connessioni è possibile
creare con AMQP e SBMP.

00:21:32.410 --> 00:21:35.550
Pertanto anche queste sono considerazioni importanti
Nella valutazione, hey,

00:21:35.600 --> 00:21:38.980
protocollo che si intende utilizzare
per mio su larga scala, numero di grandi dimensioni

00:21:39.030 --> 00:21:50.090
dei mittenti? Protocolli binari così
rispetto a HTTP, perché è importante

00:21:50.140 --> 00:21:53.280
per la messaggistica? Che cosa sono la chiave
Considerazioni per la messaggistica?

00:21:53.810 --> 00:21:56.350
Desidera evidenziare la chiave
scenari in cui è un

00:21:56.400 --> 00:21:59.380
differenza di questa operazione è possibile scegliere
e decidere se è importante

00:21:59.430 --> 00:22:02.780
o non per il caso particolare.

00:22:04.210 --> 00:22:08.070
Casi HTTP, ogni volta che apportate
una chiamata in uscita, si dovranno essere

00:22:08.120 --> 00:22:11.480
in grado di raggiungere un'entità. In modo che del
un endpoint, ovvero

00:22:11.530 --> 00:22:13.850
un endpoint di invio o un endpoint di ricezione.

00:22:14.850 --> 00:22:16.820
È possibile eseguire un'operazione in sospeso.

00:22:17.560 --> 00:22:21.540
Un solo invio chiamata o
una chiamata singola ricezione.

00:22:22.370 --> 00:22:26.300
E la maggior parte dei casi, l'operazione
durata non può essere superiore a

00:22:26.350 --> 00:22:30.940
60 secondi o qualunque sia il carico
Consente di qualsiasi sistema di bilanciamento

00:22:31.480 --> 00:22:33.060
provider. che è in esecuzione.

00:22:34.490 --> 00:22:41.480
In modo che unificare sorta di
un punto in cui desidera di scenari

00:22:41.530 --> 00:22:43.390
per comunicare con più punti di fine.

00:22:44.040 --> 00:22:47.590
Molte volte nel acquistare direzionale
scenari di comunicazione che sta

00:22:47.640 --> 00:22:51.230
Vai a da inviare per passare una coda e
ricezione da una sottoscrizione.

00:22:52.080 --> 00:22:55.730
O anche inviare una notifica di go
hub. Tutti i tipi di

00:22:55.780 --> 00:22:57.060
gli scenari possono essere presenti.

00:22:57.640 --> 00:23:01.320
Con un protocollo binario, è effettivamente
possibile creare una singola connessione

00:23:01.370 --> 00:23:08.270
un singolo effetto significativo, un singolo socket,
tutti gli altri collegamenti in e il

00:23:08.320 --> 00:23:13.320
Contesto AMQP è un multiflexed di collegamenti
su tale singola connessione HTTP.

00:23:14.500 --> 00:23:18.740
Così di ottenere molti vantaggi da
non è necessario effettuare l'handshake

00:23:18.790 --> 00:23:22.680
e di non dover stabilire tale socket
e per ogni singola

00:23:22.730 --> 00:23:26.880
che pagamento di entità invece che...
costo di una sola volta e quindi riutilizzare

00:23:26.930 --> 00:23:29.460
che quando parla
a varie entità.

00:23:30.290 --> 00:23:33.900
Tenere presente tale scenario. A volte
Quando si scrivono i gateway di campo

00:23:33.950 --> 00:23:37.240
o i gateway personalizzati dove ti
fronting un lotto di dispositivi, questo

00:23:37.290 --> 00:23:40.690
sarà un fattore molto importante.

00:23:43.280 --> 00:23:48.250
L'altra parte è lunga fruibili.
Pertanto non esiste questa costante

00:23:48.300 --> 00:23:51.400
sulle code, destra, tirando
di hey, ho un messaggio?

00:23:51.450 --> 00:23:55.160
Si dispone di un messaggio? È necessario
viene visualizzato un messaggio? Qui, perché è

00:23:55.210 --> 00:24:01.040
una connessione sul protocollo AMQP
Abbiamo mantenere attiva la connessione.

00:24:01.090 --> 00:24:04.370
Non è necessario eseguire alcuna operazione
è diverso da un in sospeso

00:24:04.420 --> 00:24:09.120
ricezione che può essere impostato per un
timeout infinito. È Impossibile

00:24:09.170 --> 00:24:12.110
liquidare, per un giorno, una settimana. In genere
non liquiderà

00:24:12.160 --> 00:24:16.090
per infinito. Essa verrà impostata per tutti i valori
le caratteristiche di arresto

00:24:16.140 --> 00:24:19.560
l'aspetto, forse 20 minuti o
un nome simile che. Ma è

00:24:19.610 --> 00:24:24.920
può avere un pull lungo in attesa di ricezione
e non deve preoccuparsi

00:24:24.970 --> 00:24:27.640
sfornare continuamente cicli della CPU e materiale di

00:24:29.370 --> 00:24:33.080
recupero delle informazioni. Vi terremo
la connessione attiva tramite

00:24:33.130 --> 00:24:37.040
ping o altro sistema di bilanciamento del carico
è necessaria e verranno fornite

00:24:37.090 --> 00:24:41.640
è la risposta di bassa latenza
ogni volta che un messaggio viene visualizzato.

00:24:42.360 --> 00:24:45.820
In modo che questa diventi un'altra molto importante
esame in termini di

00:24:45.870 --> 00:24:50.380
di costo, nonché l'impatto sulla
il dispositivo. Protocolli binari così

00:24:50.430 --> 00:24:53.310
fare la differenza in termini di
gli scenari.

00:24:56.240 --> 00:24:59.820
L'altra considerazione che protocolli
porta sono in SDK.

00:24:59.870 --> 00:25:03.520
Si desidera ottenere la produttività. Desidera
Per utilizzare core tinta unita. Desidera

00:25:03.570 --> 00:25:08.220
Utilizzare librerie tinta unite. Così è davvero
Per poter scegliere

00:25:08.270 --> 00:25:11.010
il protocollo corretto con
il SDK di destra.

00:25:12.880 --> 00:25:13.950
Questa operazione per Bus di servizio,

00:25:15.670 --> 00:25:19.750
Se si utilizza .NET, quindi l'impostazione predefinita
Protocollo SBMP è l'impostazione predefinita.

00:25:19.800 --> 00:25:24.130
Che viene utilizzato. È possibile passare
per AMQP in qualsiasi momento e

00:25:24.180 --> 00:25:25.170
troppo va bene.

00:25:25.850 --> 00:25:28.980
Esistono alcuni meccanismi di difesa in primo piano
ora, ma ci stiamo chiusura

00:25:29.030 --> 00:25:33.730
tale lacuna presto. Ma se si è
con .NET, è SBMP quindi

00:25:33.780 --> 00:25:36.010
specie di default scenario oggi.

00:25:37.560 --> 00:25:42.400
Se si utilizza HTTP, se tale del
un caso, abbiamo wrapper HTTP su un lotto

00:25:42.450 --> 00:25:46.160
dei sistemi operativi disponibili e
molte librerie disponibili.

00:25:47.010 --> 00:25:50.510
E quindi con AMQP si avvia
Per visualizzare una grande quantità di Comunità

00:25:50.560 --> 00:25:51.700
librerie ad avviarsi.

00:25:52.940 --> 00:25:59.670
È stato AMQP da uno standard aperto
progettato e sviluppato tutti con

00:26:00.690 --> 00:26:05.690
tenendo presente efficiente e affidabile,
sono portabile ordinamento dei dati

00:26:05.740 --> 00:26:10.310
rappresentazione e flessibilità
in considerazione. Flessibilità in termini di

00:26:10.360 --> 00:26:13.470
Se sia da client
librerie o i client al broker

00:26:13.520 --> 00:26:15.120
o interrotto annullino librerie.

00:26:16.680 --> 00:26:20.260
Così si inizia a vedere con la AMQP
Inoltra lo spostamento di standardizzazione...

00:26:20.310 --> 00:26:26.370
a proposito, AMQP è stato standard OASIS ultimo
Ottobre. Semplicemente cancellato ISO/IEC.

00:26:27.560 --> 00:26:32.950
A questo punto è internazionale riconosciuto
standard, troppo. In modo che del

00:26:33.210 --> 00:26:35.180
freschi di stampa.

00:26:36.990 --> 00:26:41.560
Ma cosa significa si è che è
verrà visualizzato un elenco di librerie

00:26:42.230 --> 00:26:47.750
sviluppato da Apache Qpid libreria
set o la libreria proton

00:26:47.800 --> 00:26:51.010
client in linguaggi diversi.

00:26:51.890 --> 00:26:55.240
C, Java, è disponibile un'implementazione JMS.

00:26:56.110 --> 00:27:00.670
Di PHP. Tutti questi saranno disponibili
con la Comunità

00:27:00.720 --> 00:27:05.970
libreria di aprire il supporto di origine per l'utilizzo
e lo sviluppo e il contributo

00:27:06.020 --> 00:27:06.740
a e

00:27:07.970 --> 00:27:12.310
con il servizio più o con qualsiasi altro
provider che supporta il

00:27:12.360 --> 00:27:14.070
Portale AMQP in tale posizione.

00:27:14.820 --> 00:27:18.400
Quindi, se si sta tentando di accedere ai Bus di servizio,
è possibile visualizzare i diversi protocolli.

00:27:18.450 --> 00:27:22.940
Si dispone di molta scelta di cosa
SDK è possibile utilizzare le librerie e

00:27:22.990 --> 00:27:34.850
si utilizza e non è necessario essere
limitato in alcun modo particolare.

00:27:34.900 --> 00:27:36.150
Sincronizzazione, asincrono e batch.

00:27:37.150 --> 00:27:40.650
Ora che sappiamo quali sono
i vari tipi di protocollo, penso

00:27:40.700 --> 00:27:45.840
dovremmo parleremo quando necessario
scriviamo un codice di sincronizzazione, async

00:27:45.890 --> 00:27:49.170
codice e il codice batch e quali sono
le differenze in termini reali

00:27:49.220 --> 00:27:54.100
delle prestazioni che è Impossibile vedere
In questi scenari diversi.

00:27:55.890 --> 00:27:58.710
Divisione in batch chiaramente aumenta la velocità di trasmissione.

00:27:59.460 --> 00:28:04.620
È sempre molto buona norma
in termini di eventuale

00:28:04.670 --> 00:28:09.260
sul lato ricezione o anche in
il lato di invio per utilizzare i batch.

00:28:09.310 --> 00:28:13.190
L'interesse negativo solo per amministratori
a volte è una latenza con cui

00:28:13.240 --> 00:28:17.490
e vedremo come che può essere
interessati ma non eccessiva.

00:28:17.540 --> 00:28:18.880
Parleremo che.

00:28:21.250 --> 00:28:24.830
Async in generale è sempre il
procedura consigliata. Si desidera sempre

00:28:24.880 --> 00:28:28.620
Per utilizzare, quando possibile. Con la differenza
che si desidera associare

00:28:28.670 --> 00:28:31.760
il numero di chiamate affiancate. Si
non desidera avere una stretta

00:28:31.810 --> 00:28:34.720
ciclo che effettua un numero infinito
di chiamate e vedremo come

00:28:34.770 --> 00:28:37.660
Bus di servizio semplifica tale scenario.

00:28:40.160 --> 00:28:44.110
E quindi infine è presente il file binario
protocolli significativamente più elevate

00:28:44.160 --> 00:28:47.980
la possibilità di raggiungere la velocità di trasmissione
solo perché questi protocolli,

00:28:48.030 --> 00:28:54.290
è stato sviluppato il protocollo AMQP
con efficienza presente con

00:28:55.260 --> 00:28:58.750
il controllo di flusso e tutto ciò
incorporate nel livello di protocollo

00:28:58.800 --> 00:29:03.950
stesso presenti molti vantaggi
visualizzate. Pertanto è possibile effettivamente

00:29:04.000 --> 00:29:08.550
Mostra alcuni numeri. Alcuni in esecuzione
numeri, è possibile confrontare

00:29:08.600 --> 00:29:10.090
Queste informazioni per se stessi.

00:29:20.030 --> 00:29:24.820
Qui ho un codice che è
Se si tenta di inviare messaggi in corso.

00:29:26.190 --> 00:29:28.970
Ed è possibile vedere che ho suddiviso
il backup in tre parti.

00:29:29.850 --> 00:29:32.930
Primo sta eseguendo un invio di sincronizzazione.

00:29:33.690 --> 00:29:38.660
Ecco le righe di chiave. Per ogni
i messaggi, non un qClient e invia

00:29:38.710 --> 00:29:44.060
disattivare il messaggio. Si tratta di una sincronizzazione molto
chiamare il metodo. Pesi per uno per il completamento.

00:29:44.110 --> 00:29:48.030
Rimane in attesa di conferma in futuro
dal server, è possibile raggiungere

00:29:48.080 --> 00:29:51.200
dal client, un completo
loop e quindi viene spostata.

00:29:52.910 --> 00:29:56.650
Seconda operazione viene effettuata
in modo asincrono.

00:29:57.900 --> 00:30:02.780
Dove essenzialmente creazione
Attività asincrona per tutti questi

00:30:03.350 --> 00:30:04.470
operazioni di invio.

00:30:05.700 --> 00:30:09.150
E quindi in attesa per tutti
completamento delle attività.

00:30:11.410 --> 00:30:15.170
E infine, non sarà presente in un batch
Invia e si chiama ordinati

00:30:15.220 --> 00:30:19.430
invio in blocco perché con Async, in genere
i potrebbe venire in mente

00:30:19.480 --> 00:30:22.840
uno scenario in cui si dice, hey, con
Async, si perde l'ordine. Non credo

00:30:22.890 --> 00:30:25.800
sapere quale dei due si verificherà in primo luogo,
quale verrà eseguita successivamente.

00:30:26.300 --> 00:30:29.430
Questo motivo è invio batch
che è sorta di qualità superiore

00:30:29.480 --> 00:30:32.300
in entrambi i casi perché mantiene
tutti il... le intere

00:30:32.350 --> 00:30:35.920
batch viene fornito tramite la totalità o
batch viene restituita e sarà

00:30:35.970 --> 00:30:38.910
vedere la quantità delle prestazioni dopo
impatto che questo può avere.

00:30:40.310 --> 00:30:45.300
Così ho tutti questi scegliendo
un semplice nella coda di messaggi campione.

00:30:45.350 --> 00:30:47.900
È possibile vedere subito il
conteggio della coda è uguale a zero.

00:30:48.910 --> 00:30:52.560
Ed è impostato il numero di messaggi
in un numero ridotto di 100.

00:30:53.660 --> 00:30:54.780
Possibile eseguire questa operazione.

00:30:57.310 --> 00:30:59.530
E vediamo quanto succede.

00:31:00.250 --> 00:31:04.670
Prima esegue Invia utilizzando
sincronizzazione. Rendendo così in modo sincrono

00:31:04.720 --> 00:31:09.020
100 chiamate dal mio portatile tutte le
modo al servizio e viceversa.

00:31:09.550 --> 00:31:13.970
Ha impiegato circa dieci secondi in termini di
di che. E solo per illustrare

00:31:14.020 --> 00:31:18.360
è sempre possibile tornare, controllare sul
il numero di messaggi che deve

00:31:18.410 --> 00:31:21.860
essere pari a 100. Tutti i 100
i messaggi hanno reso qui.

00:31:23.160 --> 00:31:26.940
Ora vediamo cosa accade quando
Eseguire la stessa operazione asincrona.

00:31:29.190 --> 00:31:30.590
Stessa cosa con Async.

00:31:31.940 --> 00:31:36.120
E nessuna differenza in termini di
i messaggi perché

00:31:37.540 --> 00:31:40.460
i messaggi hanno tutti reso
di seguito. È ora 200 messaggi.

00:31:41.250 --> 00:31:46.450
. 3 secondi impiegato. Per tutti i
messaggi per ottenere in tale posizione.

00:31:50.260 --> 00:31:52.620
Batch, è ancora più veloce.

00:31:53.370 --> 00:31:54.990
È effettivamente ancora più veloce.

00:31:56.080 --> 00:31:58.880
E il motivo è nuovo, che
sotto il coperchio, Bus di servizio

00:31:58.930 --> 00:32:04.440
utilizza un protocollo binario conseguenza quando
si ci messaggi in modo asincrono,

00:32:04.490 --> 00:32:09.600
Siamo tabella di suddividere tra loro e
invio tramite con la divisione in batch implicita.

00:32:10.260 --> 00:32:13.630
È possibile impostare il valore. Il
intervallo di cancellazione batch, ciò che si

00:32:13.680 --> 00:32:17.710
Impostare su una factory di messaggistica, consente di
è possibile impostare tale finestra.

00:32:18.310 --> 00:32:21.010
È possibile impostarla su una finestra più ampia.
Si vedrà più latenza,

00:32:21.060 --> 00:32:23.690
ma si noterà molto più meglio
velocità di trasmissione end-to-end. È possibile

00:32:23.740 --> 00:32:27.310
impostarlo su una finestra di dimensioni molto più piccola
si vedrà latenza migliore

00:32:27.360 --> 00:32:32.110
e forse un po' di throughput inferiore.
Ma è possibile vedere il

00:32:32.160 --> 00:32:36.660
ordine di grandezza di differenza qui
rende in termini di utilizzo di sincronizzazione

00:32:36.710 --> 00:32:38.410
confronto Async e batch.

00:32:45.080 --> 00:32:49.310
Rapidamente vediamo, ora che
sia il nostro 300 messaggi,

00:32:49.360 --> 00:32:51.110
cosa si può fare sul lato ricezione?

00:33:02.730 --> 00:33:06.700
In ricezione, si noti qui che non mi
utilizzando il messaggio su API.

00:33:08.710 --> 00:33:12.460
Questo è solo per illustrare un mele
confronto di mele di cosa

00:33:12.510 --> 00:33:15.560
sincronizzazione che API sorta di aspetto
e quindi spiegherò come il

00:33:15.610 --> 00:33:18.370
nel messaggio API fa tutto
di questo per voi.

00:33:20.100 --> 00:33:23.620
Si tratta di una sincronizzazione di ricezione.

00:33:24.300 --> 00:33:28.740
In modo da due chiaramente chiama fase
al server in modo che questo

00:33:28.790 --> 00:33:33.600
sono in termini di elaborazione dei messaggi.
Mai, mai perderai

00:33:33.650 --> 00:33:38.280
un messaggio in transito o in transito
Poiché fino a quando non viene chiamata

00:33:38.330 --> 00:33:41.950
completo su di esso, viene inviato
eseguire lo stesso messaggio.

00:33:43.810 --> 00:33:48.260
La successiva è asincrono e si
possibile vedere cosa scostamenti

00:33:49.430 --> 00:33:56.230
è un'attività con una continua con per
Chiamare quindi il completo in tale posizione.

00:34:01.730 --> 00:34:05.290
E nuovamente attenderà per tutti i
Intaglio in attività per completare

00:34:05.340 --> 00:34:07.770
prima di chiamare il cronometro fatto.

00:34:09.300 --> 00:34:10.660
E infine esiste batch.

00:34:11.330 --> 00:34:12.950
Batch è un po' più interessante.

00:34:13.890 --> 00:34:19.030
In questo caso, è ancora più semplice poiché è
batch di ricezione, si noti un passaggio

00:34:19.080 --> 00:34:21.370
un numero di messaggio
è 100.

00:34:22.040 --> 00:34:24.860
Dopo aver chiamato ricevono ora batch
con centinaia non significa che abbiamo

00:34:24.910 --> 00:34:28.830
assegnare un centinaio messaggi
back. Questa operazione verrà eseguita qualsiasi

00:34:28.880 --> 00:34:32.660
è la soluzione più ottimale per il filo di base
via competere da consumer,

00:34:32.710 --> 00:34:35.970
su quanti altri nodi
dispone di estrarre il messaggio per vedere

00:34:36.020 --> 00:34:38.800
creare un batch ottimale
e inviare che.

00:34:39.610 --> 00:34:43.320
Questo motivo sapere che ho un
ciclo esterno che mantiene la chiamata

00:34:43.370 --> 00:34:47.620
batch di ricezione fino a quando non viene non raggiunto
miei centinaia messaggi. È necessario

00:34:47.670 --> 00:34:51.430
Per eseguire questo calcolo batch fino al
Viene raggiunto un centinaio messaggi.

00:34:53.920 --> 00:34:59.030
E in questo caso, verrà
contenere solo al relativo token bloccato.

00:34:59.080 --> 00:35:01.160
Questo è tutto che dal messaggio.
Di non è necessario mantenere

00:35:01.210 --> 00:35:04.440
l'intero messaggio. Una volta che sono utilizzati
il messaggio, è stato elaborato

00:35:04.490 --> 00:35:07.710
in è solo necessario mantenere
il token di blocco e quindi chiamare

00:35:07.760 --> 00:35:12.940
il processo batch Async completo con tutti
i token bloccati in tale posizione.

00:35:14.060 --> 00:35:16.940
Ed eseguo questa in modo batch
anche in questo caso, non sto quando iniziare

00:35:16.990 --> 00:35:19.490
completamente fino alla fine di
completare tutti i messaggi?

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


00:35:21.660 --> 00:35:22.750
... .subset in tale posizione?


00:35:23.510 --> 00:35:24.840
>> Il Qual era la domanda?


00:35:24.890 --> 00:35:28.400
>> Se è in grado di elaborare alcune delle
messaggi, Impossibile completare

00:35:28.450 --> 00:35:30.520
tale test, condurre un sottoinsieme?

00:35:30.860 --> 00:35:34.510
>> In modo assoluto. In modo assoluto.
Batch completato in modo asincrono.

00:35:35.250 --> 00:35:39.040
È possibile chiamare con un singolo token bloccato
due bloccato token, qualsiasi

00:35:39.090 --> 00:35:42.720
l'insieme è. È sufficiente che sarà
inviare tutti i token bloccato

00:35:42.770 --> 00:35:46.250
in un batch e get è possibile eseguire il
risultati in un batch. Quindi presenta

00:35:46.300 --> 00:35:50.010
salvataggio di tale latenza e che
andata e ritorno per l'esecuzione di tutto questo

00:35:50.060 --> 00:35:52.540
e rendendo molto efficiente.

00:35:54.300 --> 00:35:56.070
Vediamo cosa che consente di aggiungere fino a.

00:35:58.400 --> 00:36:03.230
Qui ho lo stesso caso. Mi
Innanzitutto verrà utilizzata la sincronizzazione e

00:36:03.280 --> 00:36:07.440
Se si tenta di ricevere tutte le centinaia...
i messaggi innanzitutto centinaia

00:36:07.490 --> 00:36:11.190
in tale posizione. Ora nota che sarà peggio
prestazioni più inviare perché

00:36:11.240 --> 00:36:14.080
due volte il numero di operazioni in corso
in modo che si desidera ricevere

00:36:14.130 --> 00:36:16.460
ogni messaggio, completare tutti i messaggi.
Ricevere ogni messaggio

00:36:16.510 --> 00:36:20.110
completare ogni messaggio. E
quindi procedere. In tal caso 18 secondi.

00:36:20.160 --> 00:36:24.220
Invece di dieci Invia che avevamo visto
per l'invio, impiega 18 secondi

00:36:24.270 --> 00:36:28.760
a tali messaggi e completa
li. In modo assolutamente non funzionante.

00:36:30.090 --> 00:36:35.330
Con Async perché si sta eseguendo una serie
di essi in parallelo, ora ottenere verso il basso per

00:36:35.380 --> 00:36:38.880
circa i 2,8 secondi. A questo punto,
Questi numeri sono appena...

00:36:39.410 --> 00:36:43.230
portarli sempre con un grano di sale,
sono in esecuzione su una rete di seguito,

00:36:43.940 --> 00:36:47.470
Tuttavia è possibile visualizzare solo l'ordine di grandezza
della differenza. È possibile visualizzare

00:36:47.520 --> 00:36:49.620
la quantità di questo miglioramento.

00:36:50.830 --> 00:36:52.580
E ora vediamo cosa
si verifica con i batch.

00:36:55.730 --> 00:37:00.720
Siamo indietro. Siamo in grado di eseguire la stessa
quasi caratteristiche come

00:37:00.770 --> 00:37:04.590
per tutte le centinaia di 0,1 secondi
operazioni che avevano preso...

00:37:05.410 --> 00:37:07.930
solo perché utilizziamo
batch in tale posizione.

00:37:11.380 --> 00:37:16.640
Ora, non solo visualizzare tutti questi
vantaggi in questa posizione, ma il servizio

00:37:16.690 --> 00:37:21.680
Bus effettivamente è molto facile
per l'utente scrivere questo codice particolare.

00:37:21.730 --> 00:37:26.700
Il codice che ho illustrato non è molto
complesso, ma è effettivamente scattata

00:37:26.750 --> 00:37:29.280
è un passo avanti e si
reso ancora più semplice.

00:37:30.200 --> 00:37:33.470
In tal caso per il... dal modo in cui, appena
preferito dimostrare qui sul

00:37:33.520 --> 00:37:37.280
messaggi visualizzati questi messaggi di 300
a questo punto, se si aggiorna, esso

00:37:37.330 --> 00:37:41.920
dovrebbe tornare a zero indica
Non sto che si trovano. Tutti i 300

00:37:41.970 --> 00:37:43.380
i messaggi sono stati elaborati.

00:37:47.270 --> 00:37:54.910
OK (Okay). Pertanto esamineremo il messaggio via
API, ma di interesse

00:37:54.960 --> 00:37:57.880
tempo andrò a velocità
il backup di un po' qui.

00:38:00.480 --> 00:38:04.820
In modo che si è visto che la differenza tra
sincronizzazione asincrona e batch, e

00:38:04.870 --> 00:38:10.330
Spero che [Indiscernible] sempre utilizzo invio in batch. La cosa successiva sulla velocità effettiva.

00:38:10.380 --> 00:38:14.100
Code partizionate e argomenti.
Pertanto sono stati rilasciati 2.2 SDK.

00:38:15.680 --> 00:38:19.590
Partizionare essenzialmente code e argomenti
richiedere una coda e partizione

00:38:19.640 --> 00:38:21.830
essa attraverso diversi nodi di elaborazione.

00:38:23.240 --> 00:38:26.950
Questo non solo offre molto più
potenza di velocità effettiva in termini di

00:38:27.000 --> 00:38:31.900
la possibilità di elaborare più messaggi, ma
offre maggiore capacità di archiviazione.

00:38:32.410 --> 00:38:35.820
Offre la possibilità di avere
code di dimensioni molto maggiori. Offre

00:38:35.870 --> 00:38:38.170
è la possibilità di essere più resistente.

00:38:39.270 --> 00:38:42.290
Se una partizione non è disponibile,
procedere con un'altra partizione

00:38:42.340 --> 00:38:43.580
per elaborare i messaggi.

00:38:44.640 --> 00:38:49.270
Quindi partizionare le code da e dall'estrema
per la maggior parte degli scenari

00:38:49.320 --> 00:38:52.990
è un throughput molto, molto migliore
disponibilità e capacità di recupero

00:38:53.040 --> 00:38:58.570
caratteristica, vedere. Dalla casella.
È così facile creare e

00:38:58.620 --> 00:39:02.700
Utilizzare le code di partizione è
appena il suggerimento

00:39:02.750 --> 00:39:06.470
Utilizzare sempre questi. Utilizzare solo sempre
Queste proprietà. Infatti, nel prossimo

00:39:06.520 --> 00:39:11.000
Versione di SDK, abbiamo una traccia per apportare
è il valore predefinito che per impostazione predefinita,

00:39:11.050 --> 00:39:13.380
Quando si crea una coda è possibile
ottenere una coda partizionata.

00:39:15.690 --> 00:39:20.650
A questo punto, è necessario tenere conto del fatto
cosa succede quando si scattano

00:39:20.700 --> 00:39:22.590
una coda e partizionarlo in.

00:39:24.060 --> 00:39:26.530
Se non si utilizza le sessioni, è possibile
molto parlare di sessioni

00:39:26.580 --> 00:39:30.340
in dettaglio ma se non si utilizza
sessioni, quindi, essenzialmente,

00:39:31.060 --> 00:39:33.050
è necessario essere...

00:39:34.220 --> 00:39:38.380
è necessario tenere presente che i messaggi
potrebbero essere visualizzate in ordine

00:39:38.430 --> 00:39:41.830
ora perché essenzialmente possono
Vai in partizioni diverse

00:39:41.880 --> 00:39:46.770
e se una partizione non è disponibile,
quindi verrà visualizzato il messaggio

00:39:46.820 --> 00:39:47.720
nell'ordine.

00:39:48.460 --> 00:39:51.270
E questo è un aspetto da tenere in considerazione
ma se si utilizza le sessioni,

00:39:51.320 --> 00:39:54.720
quale parleremo ora, quindi
tutti la semantica di ordinamento

00:39:54.770 --> 00:39:56.100
vengono mantenuti completamente.

00:39:57.120 --> 00:40:02.330
E vedremo come. Solo per mostrarvi
il codice qui, ogni volta che sta

00:40:02.380 --> 00:40:05.590
creazione di una coda non esiste un unico
proprietà EnablePartitioning.

00:40:05.640 --> 00:40:08.720
Oggi è impostata su false per impostazione predefinita.
Come detto nel prossimo

00:40:08.770 --> 00:40:10.040
SDK è true.

00:40:10.780 --> 00:40:13.750
Pertanto è necessario impostare che. Da
il modo in cui non so come si

00:40:13.800 --> 00:40:18.770
coloro che si occupano in genere si ma la mia filosofia
In generale non è mai copia

00:40:18.820 --> 00:40:20.730
codice disponibile in PowerPoint.

00:40:21.330 --> 00:40:24.470
Non so se funziona per
voi ragazzi. Mai, mai copia

00:40:24.520 --> 00:40:28.150
codice disponibile in PowerPoint perché
sarà il più semplice

00:40:28.590 --> 00:40:32.710
e tipo di codice che chiunque basic
possibile inserire il paese. In questo

00:40:32.760 --> 00:40:35.500
caso che costituisce un problema. Si sta impostando semplicemente
una proprietà, sono in modo che va bene.

00:40:35.550 --> 00:40:38.540
Ma se ho mai illustrato che del codice
in PowerPoint, non copiare.

00:40:40.650 --> 00:40:46.660
In tal caso velocità di connessione. Si parla di
sui mittenti. Abbiamo visto

00:40:46.710 --> 00:40:50.290
modalità binarie connessioni sono in realtà,
molto importante. Sono disponibili

00:40:50.340 --> 00:40:55.090
alcuni casi in cui si potrebbe inviare
utilizzando una pipe molto fat.

00:40:55.660 --> 00:40:58.340
Considerarlo come back-end in modo da avere
Tentativo in una coda di messaggi.

00:40:58.390 --> 00:41:03.370
Ci sono moltissimi i registri da
per il push up e cose simili a quelle.

00:41:04.400 --> 00:41:08.450
Anche a un certo punto, creazione di ulteriori
le connessioni TCP fisiche può

00:41:08.500 --> 00:41:12.630
essere effettivamente una buona idea ed è possibile
farlo facilmente. Ogni messaggi

00:41:12.680 --> 00:41:16.220
Nell'istanza di una classe della factory
istanza della factory di messaggistica

00:41:16.270 --> 00:41:18.390
corrisponde a un'unica connessione PCP.

00:41:19.390 --> 00:41:22.550
Ulteriori così il numero di client di coda
e ciò che si sta creando

00:41:22.600 --> 00:41:25.680
disattivare la factory stessa, come illustrato
è, si sta multiplexing tutti

00:41:25.730 --> 00:41:31.430
connessioni su stesso socket TCP.
Quindi creare ulteriori factory di messaggistica.

00:41:31.480 --> 00:41:33.700
E se si crea ulteriori messaggistica
factory, verrà solo visualizzato ulteriori

00:41:33.750 --> 00:41:38.720
tubi e altri dati possono essere inseriti.
tramite pertanto un fattore chiave

00:41:38.770 --> 00:41:42.540
per tale oggetto. Capacità di recupero livello connessione
è incorporato. Dopo aver

00:41:42.590 --> 00:41:46.140
creare una factory di messaggistica, è
non è necessario annullare le modifiche.

00:41:46.190 --> 00:41:49.320
Se si interrompe la connessione, è possibile
ricostruirlo. Se si interrompe il collegamento

00:41:49.370 --> 00:41:52.740
per una coda, si sarà Rigenera. Tutti i valori
Consente di ricostruire è

00:41:52.790 --> 00:41:54.860
in termini di così che non viene mai
necessario effettuare questa operazione...

00:41:55.370 --> 00:41:58.030
necessario eliminare questo oggetto
e ricreare questo oggetto.

00:41:58.310 --> 00:42:02.780
È sufficiente creare più di essi e riutilizzare
Per quanto necessario.

00:42:05.910 --> 00:42:07.540
In modo che ci porta a sessioni.

00:42:08.520 --> 00:42:11.670
Poiché sto che richiede di prendere
tutti questi mittenti numerosi

00:42:11.720 --> 00:42:14.910
dei mittenti ed eseguire il multiplexing tutti
in un numero molto piccolo

00:42:14.960 --> 00:42:17.850
di code, come verranno
Per eseguire effettivamente il?

00:42:17.900 --> 00:42:21.110
Abbiamo visto tipo Orleans di framework
e interessanti, sono tutti

00:42:21.160 --> 00:42:23.460
tentativo di demultiplexing di flusso,

00:42:24.720 --> 00:42:26.530
demultiplexing nel flusso.

00:42:28.490 --> 00:42:33.070
Sessioni è incorporato un awesome
funzionalità di servizio Bus che

00:42:33.120 --> 00:42:37.130
essenzialmente consente di creare le code secondarie.
Pertanto ogni sessione può essere considerato

00:42:37.180 --> 00:42:40.290
di come una coda secondaria quando una coda piena.

00:42:41.480 --> 00:42:44.860
E la natura originale solo
è necessario impostare l'ID di sessione.

00:42:44.910 --> 00:42:46.840
Che è una proprietà singola
è necessario impostare.

00:42:48.090 --> 00:42:51.240
Il ricevitore è dove il
paradigma modificata realmente.

00:42:52.050 --> 00:42:56.090
Il ricevitore non va e
dice Buongiorno, mi messaggio successivo.

00:42:56.140 --> 00:42:59.670
Il ricevitore afferma mi successivo
sessione. Mi successivo

00:42:59.720 --> 00:43:02.690
coda secondaria che dispone di alcuni messaggi
e presenterò elaborarli in

00:43:02.740 --> 00:43:06.760
ordine che presenterò elaborarli con
uno stato, è possibile memorizzare

00:43:06.810 --> 00:43:10.600
per tale destinatario. Quindi, se si ritiene che
su milioni di dispositivi,

00:43:10.650 --> 00:43:13.290
a questo punto si può pensare che su una sola
coda, si può avere tutti questi

00:43:13.340 --> 00:43:18.620
milioni di code secondarie e archivio
stato per ogni coda secondaria. In modo molto

00:43:18.670 --> 00:43:20.410
molto potente in tal senso.

00:43:21.050 --> 00:43:24.400
È possibile eseguire lavoro imposta lavoro imposta il blocco.
Che significa che è possibile pronunciare

00:43:24.450 --> 00:43:29.230
ricevitore uno, che desidera localizzare
dispositivi tra 1 e 100. Pertanto esso

00:43:29.280 --> 00:43:32.810
Vai e si richiedono sessioni 1
a 100 e verranno bloccati

00:43:32.860 --> 00:43:33.440
a quella.

00:43:35.000 --> 00:43:39.680
E naturalmente è possibile archiviare
stato. In modo che vi mostreremo il

00:43:39.730 --> 00:43:43.490
codice per questo. Essenzialmente si inserisce
la sessione hiedi su true quando

00:43:43.540 --> 00:43:45.270
si sta creando la coda.

00:43:45.790 --> 00:43:49.670
Sul lato invio è sufficiente
impostare una proprietà, l'ID di sessione.

00:43:50.530 --> 00:43:55.720
E quindi alla ricezione lato, tutti i
stesso tipo di parametri si applicano

00:43:55.770 --> 00:43:59.840
come ho illustrato, il messaggio di accettazione
sessione, è possibile accettare

00:43:59.890 --> 00:44:03.730
sessione con l'ID del messaggio o ora
Ciò che Microsoft ha appena rilasciato

00:44:03.780 --> 00:44:08.760
è un modo molto semplice
di essere in grado di eseguire

00:44:11.810 --> 00:44:13.010
ricevitori di sessione.

00:44:14.920 --> 00:44:18.080
In modo che aprirà un mittente di sessione.

00:44:18.970 --> 00:44:21.810
Abbiamo già abbiamo capito tale divisione in batch
è il modo migliore di invio

00:44:21.860 --> 00:44:25.740
in modo che tutto il mittente viene effettuata da
per ogni sessione ID in corso

00:44:25.790 --> 00:44:30.240
Per inviare tutti i messaggi come il
ID di sessione più uno. Quindi, se si dispone di

00:44:30.290 --> 00:44:33.480
ID di sessione, voglio inviare
due messaggi. Se la sessione

00:44:33.530 --> 00:44:36.070
ID due, è possibile utilizzare per l'invio
tre messaggi e così via.

00:44:37.350 --> 00:44:38.920
In modo inizierò solo al mittente.

00:44:39.880 --> 00:44:43.910
E in questo caso, se si esamina questa coda,
esempio di coda di messaggi,

00:44:44.580 --> 00:44:49.140
creazione di questa coda, il
solo una proprietà aggiuntiva che è possibile impostare

00:44:49.190 --> 00:44:55.090
via, era la richiedono proprietà session.
Che è l'unica differenza.

00:44:55.670 --> 00:44:59.940
A questo punto quando si passa a questo particolare
coda e si è presente

00:44:59.990 --> 00:45:02.440
proprietà, è possibile

00:45:08.230 --> 00:45:09.410
vedere che...

00:45:11.710 --> 00:45:16.480
richiede proprietà di sessione è
false. Non è valida.

00:45:16.530 --> 00:45:20.780
OK (Okay). Consenti all'utente di eliminare quindi questa coda.

00:45:24.670 --> 00:45:34.390
Creare sul campione di sessione del messaggio.

00:45:37.280 --> 00:45:38.780
Richiedono la sessione.

00:45:45.040 --> 00:45:47.020
Verrà letto il mio mittente.

00:45:51.490 --> 00:45:53.840
Verrà così avviato l'invio di messaggi.

00:46:09.430 --> 00:46:18.880
Immagino che non vengono rilevate che
Questo nome di coda.

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

00:46:20.870 --> 00:46:27.580
>> Oh, è stato? Le sessioni di messaggio...
Oh, ecco fatto.

00:46:29.640 --> 00:46:36.750
Perfetto. Così abilita la modifica che
esempio di sessione a via messaggio.

00:46:39.450 --> 00:46:40.630
Ringraziamento tanto.

00:46:42.100 --> 00:46:43.360
A questo punto eseguiamo questo guy.

00:46:46.770 --> 00:46:49.710
Ecco fatto. Ha dichiarato l'invio di tutti i
messaggi. Ora vediamo di spiegare

00:46:49.760 --> 00:46:54.350
è il codice di ricezione
aspetto per questo.

00:46:55.510 --> 00:46:59.710
Questa è la nuova API che
Microsoft ha appena rilasciato, il su

00:46:59.760 --> 00:47:02.010
API di elaborazione del messaggio.

00:47:03.430 --> 00:47:07.500
Questa operazione nel ruolo di lavoratore Azure,
è possibile modificare questa impostazione troppo.

00:47:10.890 --> 00:47:14.690
Nel ruolo di lavoratore Azure sul
metodo start farebbe

00:47:14.740 --> 00:47:19.540
lo stesso, controllare se la coda esista
e si crea la qClient.

00:47:20.250 --> 00:47:24.120
Nella regola di esecuzione, è possibile notare il
il codice ottiene ancora più semplice.

00:47:25.610 --> 00:47:29.270
Tutto ciò che si sta eseguendo è questo
chiamata di un registratore di cassa.

00:47:29.900 --> 00:47:32.770
Per registrare un gestore di sessione.

00:47:33.670 --> 00:47:36.500
E questo è tutto. Nessun deceive
cicli di scrittura.

00:47:37.120 --> 00:47:38.950
Nessuna durata per la gestione.

00:47:39.580 --> 00:47:43.920
Tutto ciò viene preso in considerazione da
la libreria client per l'utente.

00:47:43.970 --> 00:47:48.540
È sufficiente incapsulare tutte
la logica di come

00:47:48.590 --> 00:47:53.790
per l'elaborazione di quell'unico flusso in uno
classe denominata il mio gestore di sessione.

00:47:54.700 --> 00:47:57.450
Passiamo a esaminare questa classe
e vedere la procedura che qui.

00:47:58.700 --> 00:48:02.660
La prima cosa è che cosa fare quando
Effettivamente, viene visualizzato il messaggio?

00:48:05.430 --> 00:48:09.430
Nel messaggio, verrà eseguita solo la stampa
che viene visualizzato il messaggio e

00:48:09.480 --> 00:48:10.870
Sta aumentando il conteggio.

00:48:11.610 --> 00:48:15.320
Questo è tutto che scostamenti in questa classe.
Count è un membro privato

00:48:15.370 --> 00:48:19.860
di seguito e ci stiamo solo salvare tale valore.

00:48:21.090 --> 00:48:22.960
È necessario impostare conteggio

00:48:24.710 --> 00:48:28.550
uguale a zero e abbiamo appena tenere un conteggio
è in modo che tutta l'elaborazione.

00:48:29.270 --> 00:48:34.550
Sessione chiusa, chiusura sessione
viene chiamato quando non vi sono Nessuna

00:48:34.600 --> 00:48:38.750
più messaggi disponibili per tale
sessione o è stato raggiunto

00:48:38.800 --> 00:48:42.360
il numero massimo in valuta. Abbiamo parlato
su quanti contemporaneamente

00:48:42.410 --> 00:48:43.630
si desidera disporre.

00:48:44.260 --> 00:48:48.230
Quindi, se è stato raggiunto il numero massimo
conteggio di concorrenza di quanti

00:48:48.280 --> 00:48:53.040
sessioni di elaborazione, ti contatteremo
Chiudere tale sessione e aprire

00:48:53.090 --> 00:48:57.610
una nuova sessione, a seconda di quali messaggi
sono disponibili. Pertanto, la chiusura

00:48:57.660 --> 00:49:00.700
la possibilità di pronunciare che avere
utilizzato un insieme di messaggi, stato

00:49:00.750 --> 00:49:03.900
il trattamento di detti per questo particolare
sessione e a questo punto si dovrebbe

00:49:03.950 --> 00:49:05.580
salvare lo stato del.

00:49:07.140 --> 00:49:10.730
E qui è possibile visualizzare tutti che scostamenti
chiamare lo stato di set e get

00:49:10.780 --> 00:49:15.250
stato che si trova in opposizione la sessione.
Si tratta essenzialmente di flussi.

00:49:16.050 --> 00:49:20.770
E archiviare immediatamente il valore di conteggio
ogni volta che la sessione viene chiusa.

00:49:21.780 --> 00:49:26.130
E quella finale è l'errore
caso di quando si perde una sessione.

00:49:27.420 --> 00:49:31.050
A questo punto è importante ricordare che il motivo in grado
per correlare tutti questi messaggi

00:49:31.100 --> 00:49:34.310
perché abbiamo bloccare una sessione per
è. Occorre assicurarsi che sia attiva

00:49:34.360 --> 00:49:38.790
il ricevitore solo chi sta
messaggi per tale coda secondaria,

00:49:38.840 --> 00:49:40.510
tale sottosessione.

00:49:41.190 --> 00:49:43.780
Ed è sempre possibile perdere un blocco.
Un blocco vengono perso perché

00:49:43.830 --> 00:49:47.660
di un errore sul server. Impossibile
essere persi a causa della connessione

00:49:47.710 --> 00:49:51.410
Forse il processore o problemi
appena bloccato e più del blocco

00:49:51.460 --> 00:49:55.290
Perché eseguire un'operazione
in tale posizione è sempre possibile ottenere

00:49:55.340 --> 00:49:58.940
Questo errore è stato chiamato. In questo caso,
sarà sufficiente è abandon il

00:49:58.990 --> 00:50:03.500
impostazione locale delle modifiche e spostamento
su. In termini di che.

00:50:04.870 --> 00:50:07.150
Vediamo come funziona.

00:50:07.670 --> 00:50:08.790
Un'effettiva esecuzione.

00:50:10.210 --> 00:50:10.800
È stata una domanda?

00:50:10.850 --> 00:50:11.930
>> Funziona lo stesso?


00:50:13.740 --> 00:50:17.500
>> Così la domanda è stata: questo funzionerà lo stesso per le sottoscrizioni? Duecento percento.

00:50:17.550 --> 00:50:21.170
È completamente simmetrico. Se
viene visualizzato da una coda

00:50:21.220 --> 00:50:24.130
o viene visualizzato da una sottoscrizione.

00:50:25.440 --> 00:50:28.920
In modo Ecco il mio ruolo di lavoro. Let
controllo effettivamente rapidamente ciò che

00:50:28.970 --> 00:50:30.850
il numero di coda cercato
ad esempio dopo il

00:50:32.060 --> 00:50:36.390
ruolo è stato effettuato l'invio. L'aspetto
ha 3,700 messaggi destro

00:50:36.440 --> 00:50:40.610
elaborazione a questo punto, 33, aspetto
ha espulso.

00:50:41.650 --> 00:50:56.690
Consenti all'utente di passare all'interno di tale posizione...
Andiamo. Esso successiva.

00:50:56.740 --> 00:51:03.350
Buona. Così ora, sono del mio computer
affrontando e si

00:51:03.400 --> 00:51:06.090
può vedere migliaia di elaborazione
e migliaia di messaggi.

00:51:06.890 --> 00:51:10.740
E il codice di cui ho scritto
concetto molto semplicistico

00:51:10.790 --> 00:51:15.170
su solo una semplice sessione, un singolo
sessione e non ha

00:51:15.220 --> 00:51:18.800
per scrivere un ciclo unico di ricezione. Mi basta
era necessario registrare il gestore della pipe.

00:51:19.200 --> 00:51:23.370
Il gestore che ho illustrato è
il caso semplicistico dove si

00:51:23.420 --> 00:51:28.420
può disporre di istanze di questo creato e
non si sta eseguendo le operazioni di inizializzazione.

00:51:28.450 --> 00:51:32.020
Abbiamo una factory che backup
è disponibile. È possibile eseguire

00:51:32.070 --> 00:51:36.960
una factory del gestore di registro e che
metodo per che controllare la creazione

00:51:37.010 --> 00:51:38.700
semantica di che anche.

00:51:40.370 --> 00:51:43.560
Ma in questo caso, è possibile vedere mantenere
sessione chiusa e dello stato.

00:51:44.420 --> 00:51:48.340
Consenti all'utente di ingrandire qui in modo che utenti
vedere chiaramente che cosa è successo qui.

00:51:49.070 --> 00:51:54.740
Se viene visualizzato ogni sessione sessione
stato era 22 per sessione 21.

00:51:54.790 --> 00:51:57.810
Lo stato sessione è stato 46
per sessione 45.

00:51:58.620 --> 00:52:03.770
Poiché la classe ha ricevuto solo i messaggi
che appartenevano a tale sessione.

00:52:04.200 --> 00:52:08.320
Tutto ciò che è stato demuxing e muxing
facile e tutto ciò che è stato gestito

00:52:08.370 --> 00:52:12.410
dal Bus di servizio per l'utente. Conseguenza quando
si pensa di multiplexing

00:52:12.460 --> 00:52:15.990
un gran numero di mittenti in
un piccolo numero di code, sapere

00:52:16.040 --> 00:52:19.260
che non hanno perso la semplicità
di essere in grado di elaborare

00:52:19.310 --> 00:52:23.800
li sul back-end utilizzando
i singoli flussi

00:52:30.570 --> 00:52:34.260
in tale posizione.

00:52:37.740 --> 00:52:41.000
Abbiamo parlato di stato della sessione.
Correlazione utilizzo di sessioni.

00:52:41.350 --> 00:52:46.020
Questa operazione solo per riepilogare, effettivamente
prima si riassumono, accedere.

00:52:46.590 --> 00:52:49.230
In modo che un altro fattore chiave è
Quando si dispone di queste molto

00:52:49.280 --> 00:52:52.530
elevato numero di mittenti, qual è il
modello di autenticazione? Che cos'è la protezione

00:52:52.580 --> 00:52:55.750
modello che si desidera utilizzare?
Così direi accesso condiviso

00:52:55.800 --> 00:52:58.420
la firma è senza dubbio il
consiglia il modello di autenticazione.

00:52:59.010 --> 00:53:02.150
Non c'è molto più dettagliatamente. In realtà
il deck ha maggiori dettagli

00:53:02.200 --> 00:53:08.190
come impostare le firme di accesso condiviso.
È possibile accedere al portale

00:53:08.540 --> 00:53:10.040
e la gestione delle code.

00:53:10.910 --> 00:53:15.270
Qui ho la IOT quale è in coda
Guy utilizza dal sito Web.

00:53:16.050 --> 00:53:18.850
E posso semplicemente accedere qui e configurare.

00:53:19.420 --> 00:53:23.650
Si noti che ho dovuto Oh,...

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

00:53:23.700 --> 00:53:25.290
>> Sono spiacente. Mi dispiace così.

00:53:28.330 --> 00:53:33.790
In modo che è avvenuto un salto nel portale di Azure
e selezionato la coda IOT.

00:53:34.890 --> 00:53:38.340
In questo modo, quando passa a configurazione
scheda, vedere mio condivisa

00:53:38.390 --> 00:53:42.420
accedere qui i nomi dei criteri. Questa operazione in
tale esempio di sito Web che si

00:53:42.470 --> 00:53:45.240
è stato illustrato, richiamandola una ricezione
è la seguente stringa verrebbe effettivamente

00:53:45.290 --> 00:53:49.650
esito negativo perché attualmente, l'unico
è l'autorizzazione su questo invio.

00:53:50.890 --> 00:53:54.310
Ma posso accedere facilmente e aggiungere l'ascolto
autorizzazione a tale regola.

00:53:55.730 --> 00:53:56.440
Premere Salva.

00:53:57.340 --> 00:53:58.640
Che informa che l'aggiornamento della coda.

00:53:59.190 --> 00:54:00.050
E ora qualsiasi

00:54:01.700 --> 00:54:06.780
token che è stato generato per questo
regola avrà la possibilità

00:54:06.830 --> 00:54:11.480
Per inviare e ricevere. A questo punto
Qui è possibile accedere e di ricezione, fare clic su

00:54:12.880 --> 00:54:15.660
bene, ecco fatto. L'aspetto personale
hanno inviato messaggi.

00:54:15.710 --> 00:54:18.320
A questo punto si passa alla sessione di chat dovrà,
voi ragazzi può sempre in contatto

00:54:18.370 --> 00:54:20.210
tra loro in linea.

00:54:21.490 --> 00:54:24.220
Firma di accesso in modo condiviso, è molto,
molto leggera, sono molto

00:54:24.270 --> 00:54:28.290
modello di facile utilizzo. Se è necessario
Passare all'interno di un tipo di SDS del modello,

00:54:28.340 --> 00:54:35.540
sono che ACS è pienamente supportato. ACS è
ancora l'opzione più adatta è presente.

00:54:35.590 --> 00:54:37.660
Si è visto solo con le code.


00:54:39.580 --> 00:54:43.390
Talmente riepilogare, abbiamo visto protocolli.
Perché sono rilevanti.

00:54:43.650 --> 00:54:47.970
Siamo andati a correlazione flusso,
Per questo motivo non è necessario che

00:54:48.020 --> 00:54:50.860
si crea una coda per ogni periferica.
Non si desidera essere gestione

00:54:50.910 --> 00:54:53.980
code di un milione. Ma non si
desidera essere scrittura di codice che

00:54:54.030 --> 00:54:57.760
deve essere troppo complesso super. Così
entrambe queste sono molto, molto

00:54:57.810 --> 00:55:00.840
supportato facilmente con il servizio
Bus di messaggistica.

00:55:01.900 --> 00:55:05.320
Code argomenti, le sottoscrizioni.
Simmetrica in tutte.

00:55:05.370 --> 00:55:08.990
Tutto ciò che ho illustrato in termini
Ciò che funziona con le code per

00:55:09.040 --> 00:55:12.280
sessioni funziona allo stesso modo esatto
con gli argomenti e le sottoscrizioni

00:55:12.330 --> 00:55:16.290
e filtri. Quando si crea una sottoscrizione
è sufficiente pronunciare richiede

00:55:16.340 --> 00:55:18.360
sessione su di esso è uguale a true o non.


00:55:21.680 --> 00:55:22.910
Modificare la scala su ricevitori.


00:55:27.210 --> 00:55:30.850
Visual Studio era questa sfida
dove è possibile avviare una miriade di

00:55:30.900 --> 00:55:34.520
istanze dell'IDE e quindi
si potrebbe passare e si modifica il

00:55:34.570 --> 00:55:37.840
profilo su uno di essi e si
utile per sincronizzare.

00:55:38.640 --> 00:55:41.980
Come si prevede di passare a comunicare
Per queste istanze?

00:55:42.490 --> 00:55:45.600
E sono istanze dinamiche
troppo perché il numero di VS

00:55:45.650 --> 00:55:49.910
istanze in cui è stata avviata varia
a seconda del giorno della settimana.

00:55:49.960 --> 00:55:53.530
Abbiamo già statistiche
per dimostrare che, tra l'altro.

00:55:53.580 --> 00:55:57.170
Persone aprono modo ulteriori istanze mercoledì
rispetto a quelle aperte venerdì.

00:55:57.220 --> 00:56:04.740
In modo che la produttività è tanking entro il venerdì. 
 In ogni caso, il problema può nuovamente

00:56:04.790 --> 00:56:07.440
essere risolti con argomenti in cui si
disporre di milioni e milioni di

00:56:07.490 --> 00:56:11.110
punti finali. E si desidera che tutti
essi ascoltare il proprio uno

00:56:11.160 --> 00:56:14.070
sola sottoscrizione per i messaggi.

00:56:15.150 --> 00:56:19.140
Di fatto tali messaggi vengono generati
per il back-end basato

00:56:19.190 --> 00:56:22.840
alcune modifiche nel sistema o
un'operazione ad esempio si desidera inviare

00:56:22.890 --> 00:56:26.270
notifica a un utente, che si desidera
per informarli in un Windows

00:56:26.320 --> 00:56:30.510
casella 7 di cui non si dispone di alcuna notifica
servizio. Si desidera notificare

00:56:30.560 --> 00:56:34.520
essi e pronunciare Ehi è disponibile un nuovo aggiornamento
disponibili in Visual Studio

00:56:34.570 --> 00:56:39.970
Vai a scaricarlo. O ancora più importante
assegnare loro una sorta di bassa latenza

00:56:40.020 --> 00:56:43.890
di pipe dove se vengono effettuate modifiche
in un'istanza di Visual Studio, l'altro

00:56:43.940 --> 00:56:45.430
Sincronizzare le istanze di Visual Studio.

00:56:46.140 --> 00:56:48.340
È possibile sues gli argomenti e
sottoscrizioni per cui.

00:56:49.760 --> 00:56:52.470
Pertanto essere considerato concettualmente
come utente argomento per VS.

00:56:53.200 --> 00:56:58.800
È disponibile un'istanza di sottoscrizione per VS
sempre connessi utilizzando MQP.

00:56:58.850 --> 00:57:03.260
In modo MQP ci offre una grande quantità di connessione
efficienza di cui è stato

00:57:03.310 --> 00:57:07.830
in statunitensi milioni e milioni di
simultanea delle sezioni con molto,

00:57:07.880 --> 00:57:12.350
sovraccarico molto basso, in attesa
per le notifiche occasionali.

00:57:12.380 --> 00:57:14.840
Che è la differenza sulle notifiche.
Sono molto occasionali

00:57:14.890 --> 00:57:18.080
in natura. Con quale frequenza si hanno
modificare il colore del profilo?

00:57:19.770 --> 00:57:20.260
Un giorno?

00:57:20.310 --> 00:57:22.960
Settimana? È auspicabile che non tutti i giorni.

00:57:23.790 --> 00:57:25.160
Dipende il tuo umore che immagino.

00:57:26.260 --> 00:57:29.100
Ma non accade molto spesso.
La frequenza hanno gli aggiornamenti

00:57:29.150 --> 00:57:33.660
Per eseguire il push out? Non molto spesso. Ma
hai questo tipo BNS

00:57:33.710 --> 00:57:38.290
dell'infrastruttura disponibile per
si cui si dispone di connessioni

00:57:38.340 --> 00:57:41.780
in attesa di tale notifica, poiché
Quando la notifica

00:57:41.830 --> 00:57:45.170
diventa disponibile, si desidera ottenere in
un istante. Si desidera destro

00:57:45.220 --> 00:57:46.040
quindi e là.

00:57:51.000 --> 00:57:54.990
Qui è necessario immaginare
su ed è necessario pensare

00:57:55.040 --> 00:57:59.320
sui flussi di messaggi. Poiché oggi
argomenti consentono fino a 2000

00:57:59.370 --> 00:58:03.170
le sottoscrizioni e quando state pensando
di scala per il numero

00:58:03.220 --> 00:58:07.420
di ricevitori, 2000 può essere sufficiente
o 2000 potrebbe non essere sufficiente.

00:58:07.980 --> 00:58:10.910
Se si pensa di Visual Studio,
una sola persona avente più

00:58:10.960 --> 00:58:13.700
di istanze di 2000 del
l'IDE in esecuzione è

00:58:16.030 --> 00:58:20.210
praticamente impossibile. Non so forse
è possibile, ma non accade.

00:58:20.520 --> 00:58:24.520
Questa operazione per loro, un utente di argomento per VS
è bene, ma si che può

00:58:24.570 --> 00:58:27.660
essere che chiunque è in ascolto
per il feed stesso. Desidera

00:58:27.710 --> 00:58:30.790
essere in grado di inviare tutti gli utenti di inviare...
un singolo messaggio e inviarlo

00:58:30.840 --> 00:58:34.790
ampio cast a tutti gli utenti. Beh,
si desidera concatenare gli argomenti.

00:58:35.250 --> 00:58:38.680
E si è che l'utilizzo automatico di inoltro.

00:58:39.850 --> 00:58:43.350
Non si intende passare all'interno del gruppo
di questi dettagli del modello in

00:58:43.400 --> 00:58:45.280
termini di come impostare i filtri.

00:58:45.800 --> 00:58:48.520
Tutti questi sono esempi di MSDN.com.

00:58:49.130 --> 00:58:55.380
L'esempio viene chiamato
elenco. Non vi è un esempio di chiamata

00:58:55.430 --> 00:58:58.720
pubblicazione di sottoscrizione. Il codice completo
Per questo motivo è disponibili.

00:58:58.770 --> 00:59:02.570
Incoraggiare realmente voi ragazzi per andare a prendere
un aspetto, ma con questi argomenti

00:59:02.620 --> 00:59:06.190
è possibile liquidare veramente di queste RTF
i flussi sono dove ogni messaggio

00:59:06.240 --> 00:59:09.930
non è necessario ottenere indirizzato a tutti
tutte le 2 milioni di persone e quindi

00:59:09.980 --> 00:59:14.280
ottenere eliminato ogni volta. È possibile ottenere
indirizzato a una persona, a-molti

00:59:14.330 --> 00:59:18.680
persone, o in un tipo di caso infinito
cui è possibile scrivere solo indirizzo.

00:59:18.730 --> 00:59:19.660
Come la posta elettronica.

00:59:20.190 --> 00:59:23.130
In questo caso è come dire
il messaggio che è possibile dire in primo luogo,

00:59:23.180 --> 00:59:24.230
virgola, il secondo.

00:59:25.130 --> 00:59:27.850
E sono l'indirizzamento di due periferiche,
il primo dispositivo e il secondo

00:59:27.900 --> 00:59:30.770
dispositivo o due sottoscrizioni
il primo e il secondo.

00:59:30.820 --> 00:59:35.390
Poiché hanno regole impostate come
prima e come secondo in tale posizione.

00:59:36.390 --> 00:59:40.470
Visualizzare quindi molto queste
sub pub (indiscernible)

00:59:42.610 --> 00:59:47.050
inoltro automatico. Molto, molto facile
Per utilizzare. Creare siti

00:59:47.100 --> 00:59:52.150
coda di destinazione prima e
quindi, nella coda di origine, si

00:59:52.200 --> 00:59:55.970
aggiungere una singola proprietà. La singola proprietà
viene chiamato il codice sorgente.ForwardTo,

00:59:57.220 --> 01:00:00.600
alla coda di destinazione e di
esso. Tutti i messaggi in arrivo

01:00:00.650 --> 01:00:03.280
nella coda di origine entrano in
la coda di destinazione.

01:00:03.330 --> 01:00:10.030
Origini possono essere le sottoscrizioni e
code. I controlli possono essere argomenti

01:00:10.080 --> 01:00:10.960
e le code.

01:00:13.190 --> 01:00:16.800
Completamente simmetrico, impostare i tanti
scusiamo del carattere come si sarebbe

01:00:16.850 --> 01:00:18.810
ad esempio e vedere che.

01:00:19.400 --> 01:00:22.540
Se si dispone di casi temporanei dove
si hanno sottoscrizioni che

01:00:22.590 --> 01:00:23.390
cadendo in disuso,

01:00:24.660 --> 01:00:28.430
è possibile utilizzare l'eliminazione automatica su inattivo. Così
si tratta anche di funzionalità ottimale.

01:00:28.480 --> 01:00:32.570
Supponiamo di gestire un numero elevato di
connessioni temporanee. In realtà

01:00:32.620 --> 01:00:35.640
uno degli scenari principali è
in uso è da SignalR e

01:00:35.690 --> 01:00:38.590
Socket dei / o. Sono molto,
molto temporaneo in natura.

01:00:38.640 --> 01:00:40.200
Connessioni disponibili, connessioni Vai.

01:00:41.380 --> 01:00:43.700
Carichi aggiunti e rimossi nodi.

01:00:44.600 --> 01:00:48.680
In modo che utilizzino il Bus di servizio come
riprodurre cui essenzialmente è

01:00:48.730 --> 01:00:52.540
scrittura di una sottoscrizione per ogni nodo ogni volta che
è disponibile una nuova sottoscrizione

01:00:52.590 --> 01:00:56.160
non una nuova connessione viene visualizzata
un nuovo nodo diventa attivo, quando essi

01:00:56.210 --> 01:00:57.260
aggiungere server.

01:00:58.320 --> 01:01:03.210
E quindi utilizzano argomenti e sottoscrizione
come il tubo posteriore per

01:01:03.260 --> 01:01:05.970
trasferimento di messaggi tra i nodi
e ottenere la scala più ampia.

01:01:07.010 --> 01:01:10.090
E quindi quando un nodo non viene più visualizzato,
scadenza dell'abbonamento, quelli

01:01:10.140 --> 01:01:17.490
i messaggi sono andati vi. Entrambi
di tali codice sono codice aperto.

01:01:17.540 --> 01:01:20.240
Entrambi sono disponibili se si desidera
scalabilità orizzontale, segnale di uscita o Socket

01:01:20.290 --> 01:01:24.720
I/o perché è necessario una messaggistica durevole
pipe alla fine, servizio

01:01:24.770 --> 01:01:27.980
Bus dispone di implementazioni
per entrambe queste.

01:01:29.920 --> 01:01:33.050
Voglio parlare un po' compilato
sulla disponibilità così let me

01:01:33.100 --> 01:01:36.780
che coprono rapidamente. So
Siamo quasi nel tempo

01:01:38.830 --> 01:01:42.440
codice deve essere flessibile per operazione
errori, nonché di connessione

01:01:42.490 --> 01:01:43.470
con i problemi.

01:01:43.990 --> 01:01:46.750
Code di messaggi non recapitabili, come detto
davvero aiutarvi. Consentono di

01:01:46.800 --> 01:01:50.790
posizione in cui è in applicazione di livello
decivilization di un messaggio o

01:01:50.840 --> 01:01:51.830
un'operazione non riesca.

01:01:52.980 --> 01:01:57.440
Ogni messaggio genera Bus di servizio
dispone di una proprietà temporanea in

01:01:57.490 --> 01:01:58.020
su di esso

01:01:59.480 --> 01:02:02.780
chiara e semplice consente di
è possibile sapere se è

01:02:02.830 --> 01:02:04.350
debbano riprovare a o non.

01:02:05.090 --> 01:02:08.560
Per impostazione predefinita, effettivamente siamo automaticamente
un nuovo tentativo. Così parlato

01:02:08.610 --> 01:02:12.090
sul timeout operazione fondamentalmente
timeout. Per impostazione predefinita

01:02:12.140 --> 01:02:15.190
Timeout operazione sono impostate su
60 secondi, se si

01:02:15.240 --> 01:02:19.720
effettuare un'operazione di invio chiamata, potrebbe non riuscire una volta,
cercheremo viene nuovamente dopo

01:02:19.770 --> 01:02:22.980
tre secondi. Può presentare due volte. È possibile
Provare nuovamente dopo dieci secondi.

01:02:23.030 --> 01:02:27.840
In quanto i 60 secondi per avere a disposizione, ci sarà
Provare a eseguire tale chiamata abbia esito positivo.

01:02:27.890 --> 01:02:29.740
In caso contrario, vi verrà inviato
viene nuovamente.

01:02:31.320 --> 01:02:33.650
Se si dispone di un altro punto
Per rendere permanenti, che va bene.

01:02:33.700 --> 01:02:36.920
In caso contrario verificare come temporaneo e
quindi inviarlo nuovamente, indovinare.

01:02:38.160 --> 01:02:42.430
E dispongono di argomenti e le code di partizione
disponibilità migliorata in modo significativo.

01:02:43.080 --> 01:02:48.230
Miglioramento dell'ordine di grandezza. Così
altamente, altamente consigliabile utilizzare

01:02:48.280 --> 01:02:49.710
Questa funzionalità.

01:02:51.830 --> 01:02:55.280
Riprova criteri in base all'impostazione predefinita.
Non disattivare questa funzionalità,.

01:02:57.200 --> 01:02:59.970
Spazi dei nomi abbinati. L'ultimo
cosa parlerò oggi.

01:03:00.490 --> 01:03:03.540
Se si dispone di un Bus di servizio denominato spazio,
ben scorrono i messaggi

01:03:03.590 --> 01:03:08.210
tramite e quindi tutti i dati
Centro va caput o almeno

01:03:08.260 --> 01:03:13.570
lo spazio dei nomi intera passa un caput.
Verrà creato lo spazio dei nomi non valido

01:03:13.620 --> 01:03:15.790
il backup dello spazio dei nomi. È possibile creare
il backup dello spazio dei nomi.

01:03:15.840 --> 01:03:19.190
È sufficiente fornire a noi e ci sarà
avviare l'archiviazione dei messaggi in

01:03:19.240 --> 01:03:23.440
il backup dello spazio dei nomi. Pertanto qualsiasi
messaggio che fallisce entrare

01:03:24.140 --> 01:03:25.350
verrà eseguito con la parte posteriore.

01:03:26.210 --> 01:03:29.450
A un certo punto inizierà a messaggi
che passa attraverso. Il sistema

01:03:29.500 --> 01:03:30.340
verrà nuovamente.

01:03:31.350 --> 01:03:35.150
A questo punto abbiamo un sifone
avranno i messaggi provenienti da questi

01:03:35.200 --> 01:03:39.110
code di trasferimento e reenqueue
li alla coda originale.

01:03:40.650 --> 01:03:43.590
Questa operazione per tutto questo, il codice del mittente
non cambia, il ricevitore

01:03:43.640 --> 01:03:46.370
non modifica il codice. Il mittente
e il destinatario, come se fossero

01:03:46.420 --> 01:03:48.470
parlare sempre al servizio
Spazio dei nomi bus.

01:03:49.240 --> 01:03:54.700
Dietro le quinte, viene creata
le code di trasferimento, lo spostamento

01:03:54.750 --> 01:03:57.870
i messaggi presenti e quindi tirare
li tornare indietro per voi.

01:03:58.720 --> 01:04:03.160
E questo è l'unica informazione di
codice da modificare.

01:04:03.740 --> 01:04:06.070
Questo non è il solo lavoro che è
a tale. Parleremo della

01:04:06.120 --> 01:04:08.520
Considerazioni ma è il
solo la porzione di codice da

01:04:08.570 --> 01:04:13.330
modificare il quale è che quando si crea
una factory, che è il

01:04:13.380 --> 01:04:17.690
eseguire ora inviare e ricevere il codice
classe, è utilizzato in combinazione con un nome

01:04:17.740 --> 01:04:21.230
spazio, si supponga hey che esiste un secondo
factory, un secondo spazio dei nomi

01:04:21.280 --> 01:04:24.130
Manager che desidera utilizzare
a è essere abbinata a.

01:04:24.660 --> 01:04:28.600
E tutto il resto avviene mediante il
sul lato client. Nessuna modifica del mittente.

01:04:28.650 --> 01:04:31.470
Nessuna modifica del ricevitore. Codice
rimane invariata.

01:04:36.210 --> 01:04:41.520
A questo punto, è supportato il mittente disponibili.
Come illustrato nel diagramma,

01:04:41.570 --> 01:04:44.590
il ricevitore non verrà visualizzato il messaggio
fino a quando il nome originale

01:04:44.640 --> 01:04:45.760
lo spazio viene restituita.

01:04:46.330 --> 01:04:49.340
Pertanto si tratta di disponibilità di una trasmissione.
Ora Ecco perché

01:04:49.390 --> 01:04:54.000
viene chiamato con opzioni di disponibilità di invio.
Ordinamento potrebbe andare persa perché

01:04:54.050 --> 01:04:57.910
messaggi che sono nel trasferimento
coda non verrà visualizzato.

01:04:58.630 --> 01:05:02.360
E quindi fine alle estremità di ricezione latenza
Naturalmente possono essere elevati.

01:05:02.410 --> 01:05:06.420
Sono quindi presenti alcune considerazioni
ma ragionare di questo oggetto come

01:05:06.470 --> 01:05:10.730
uno scenario fondamentale di fabbricazione
tipo di ripristino di emergenza

01:05:12.070 --> 01:05:14.770
mai scenari.

01:05:15.810 --> 01:05:18.710
Per chiudere, ci sono solo visto Azure
Bus di servizio possibile risolve il problema

01:05:18.760 --> 01:05:21.870
in tutte le dimensioni. Molti mittenti.
Grandi quantità di velocità effettiva.

01:05:21.920 --> 01:05:23.080
Grandi quantità di ricevitori.

01:05:23.730 --> 01:05:27.420
E migliorare l'affidabilità
entrambi utilizzando le nuove funzionalità out

01:05:27.470 --> 01:05:31.950
della casella come le code di partizione
e abbinata di spazi dei nomi o da

01:05:32.000 --> 01:05:37.320
rendere il codice di utilizzare i modelli come
Async e batch e interessanti.

01:05:38.100 --> 01:05:41.750
Tantissimi collegamenti. Tonnellate di risorse.
È possibile accedere a tutto questo.

01:05:41.800 --> 01:05:44.130
Ringraziamento tanto. Ci scusiamo
per tutti i valori.