WEBVTT 00:00:01.460 --> 00:00:02.340 Guten Tag. 00:00:04.930 --> 00:00:05.880 Wie werden Leute? 00:00:08.810 --> 00:00:14.600 Gut? Ihr habt haben es fast geschafft an das Ende der Konferenz. 00:00:15.630 --> 00:00:17.150 Wie ist die Erfahrung Bisher wurden? 00:00:17.160 --> 00:00:19.360 [Beifall] 00:00:19.520 --> 00:00:20.120 >> Gut. 00:00:20.170 --> 00:00:24.940 Richtig! Nun, wie sie sagen, sie Speichern Sie die beste zum Schluss. 00:00:26.240 --> 00:00:32.190 Ich hoffe, dass wird ich nicht enttäuschen Euch. Ich schätze 00:00:32.240 --> 00:00:34.450 Ihr macht es heute Nachmittag. 00:00:35.200 --> 00:00:40.360 Ich bin Abhishek Lal. Programm-manager mit dem Team Azure-Plattform. 00:00:41.090 --> 00:00:45.840 Dies ist das Team das PaaS aufbaut. Dienste wie Mobile Dienste, 00:00:45.890 --> 00:00:48.550 Service Bus, Azure-Cache. 00:00:49.240 --> 00:00:51.080 Und Media-Dienste. 00:00:51.720 --> 00:00:54.320 Welche sind Dienste Das Team besitzt. 00:00:54.830 --> 00:00:58.940 Und insbesondere ich gearbeitet habe für die letzten drei Jahre plus 00:00:58.990 --> 00:01:05.100 zum Erstellen von vermittelten messaging Stück. Das ist also Warteschlangen, 00:01:05.150 --> 00:01:08.720 Themen sind Sub Pub, die Teile davon. 00:01:09.470 --> 00:01:15.150 Heute wir über sprechen Messaging-Maßstab. 00:01:17.010 --> 00:01:22.030 Warteschlangen und Themen. Jetzt sind Leute mit Service Bus vertraut. 00:01:22.840 --> 00:01:26.920 Er Relay umfassen. Es ist umfassen Sie Benachrichtigung Hub, 00:01:27.780 --> 00:01:29.010 Warteschlangen und Themen. 00:01:29.560 --> 00:01:34.840 So ist es irgendwie ein ganzes Spektrum messaging-bezogene Dienste. 00:01:35.710 --> 00:01:39.560 Wird dieser bestimmten Sitzung sich in erster Linie auf Warteschlangen 00:01:39.610 --> 00:01:46.260 Damit ist der primäre Themen und Bereich. Wenn Sie Fragen haben 00:01:46.310 --> 00:01:50.120 oder Sie möchten etwas wissen besonders im Hinblick auf Relay oder 00:01:50.170 --> 00:01:55.150 Benachrichtigung Hubs, bin ich glücklich beantworten, oder zumindest 00:01:55.200 --> 00:01:57.410 Sie in die richtige Richtung. 00:01:58.820 --> 00:02:00.930 Es gibt viele Dinge Ich möchte heute abdecken. 00:02:01.710 --> 00:02:04.730 Sprechen Sie über verschiedene Aspekte der Skala. Ich möchte 00:02:04.780 --> 00:02:08.490 über Sender und Empfänger und die verschiedenen Durchsatz 00:02:08.540 --> 00:02:11.630 Muster als auch der Besonderheiten des Codes. 00:02:12.390 --> 00:02:14.870 Wie Sie Skalieren erreichen können. 00:02:15.810 --> 00:02:19.040 So werde ich versuchen, zügig zu halten. 00:02:19.640 --> 00:02:24.190 Fragen sind groß. Wenn Sie mir So schneiden Sie Fragen starten 00:02:24.240 --> 00:02:27.780 nur ein wenig höher, so dass ich kann alles abdecken, werden soll 00:02:27.830 --> 00:02:31.490 um zu decken. Ich werde nach verfügbar sein die Sitzung, und Sie können immer 00:02:31.540 --> 00:02:36.200 erreichen Sie mich, aber lassen Sie es interaktive. Alles, was Sie haben, 00:02:36.250 --> 00:02:41.270 Hier sind die Mikrofone. Brauchen Sie nur, und ich nenne aus. 00:02:43.930 --> 00:02:48.720 Zunächst spricht über das, was die neue. Nur Sortierung eines Updates 00:02:48.770 --> 00:02:51.210 auf was wir als SDK 2.3 angekündigt haben. 00:02:52.250 --> 00:02:56.290 Wir müssen reden, wechseln die Dimensionen der Skala. 00:02:56.340 --> 00:03:00.420 Wir sprechen über Absender, Empfänger, Durchsatz, wie Sie das erreichen. 00:03:01.800 --> 00:03:05.770 Und wir werden dann einige Zeit verbringen, auf Überlegungen zur Verfügbarkeit. 00:03:05.820 --> 00:03:07.850 D. h. Allgemein Nur Verfügbarkeit 00:03:09.190 --> 00:03:14.340 bessere SLAS der Stabilität und wie Entwerfen Sie Ihre Anwendung 00:03:14.390 --> 00:03:19.520 immer werden Sie, immer, ausgeführt Damit wir einige Ausgaben vorhanden 00:03:19.570 --> 00:03:20.510 die Zeit auf, die. 00:03:22.060 --> 00:03:25.780 In diesem Fall SDK 2.3. 00:03:26.330 --> 00:03:28.310 Was veröffentlicht wir soeben? 00:03:29.070 --> 00:03:32.540 Auf Messaging-Sitzung. Members usw. die Jury sind ein push 00:03:32.590 --> 00:03:36.970 Stil-API. Es dauert im Wesentlichen Entfernt alle von Ihnen harte Arbeit 00:03:37.020 --> 00:03:42.960 die C-Schleifen oder etwas schreiben Diese Komplexität und 00:03:43.010 --> 00:03:46.420 bietet Ihnen eine sehr Ereignis-andere Modell, Nachrichten zu verarbeiten. 00:03:46.470 --> 00:03:50.110 Dies ist der Receiver-Seite-API. So Wir haben, die für Sitzungen. 00:03:50.160 --> 00:03:52.680 Wir auf jeden Fall behandeln, die Heute genauer. 00:03:53.890 --> 00:03:58.440 Konnektivität-Modus automatisch erkennen. So wie Sie wissen, eine Real 00:03:58.490 --> 00:04:02.520 Schlüsselwert wurde Azure Service Bus Wenn Sie eine Verbindung 00:04:02.950 --> 00:04:07.700 Warteschlangen und Themen in der cloud hinter Firewalls aus 00:04:07.750 --> 00:04:11.450 Ihre eigenen Rechenzentren oder von Ihrem die Rechenzentren Kunden 00:04:11.500 --> 00:04:16.230 sind sitzen hinten sehr gut geschützt Art von Firewalls, Service 00:04:16.280 --> 00:04:19.660 Bus bietet die Möglichkeit, die ausgehende Verbindungen nicht nur auf TCP-Port herzustellen 00:04:19.710 --> 00:04:22.110 aber Anschluss 83 und 443 00:04:23.670 --> 00:04:25.860 während TCP-Ports blockiert werden. 00:04:26.700 --> 00:04:30.790 Diese Funktion wird weiterhin jetzt verfügbar nur wenn Sie direkt festlegen 00:04:30.840 --> 00:04:34.230 das Verzeichnis mit dem TCP-Modus Sie mussten also nie die Wahl. 00:04:34.910 --> 00:04:38.730 Jetzt können in Ihrem Code Sie einfach setzen automatisch erkannt, und wir werden 00:04:38.780 --> 00:04:42.910 festzustellen Sie automatisch, ob TCP-Port verfügbar ist, werden wir das verwenden. 00:04:42.960 --> 00:04:48.410 Wenn die Firewall blockiert wird, werden wir Ziehen Sie sie auf HTTP. In diesem Fall SDK 00:04:48.460 --> 00:04:51.560 2.3, verfügbar ist für messaging auch. 00:04:54.390 --> 00:04:57.980 COR unterstützen. Wie viele Leute Was ist CORS? 00:05:00.360 --> 00:05:04.200 Die meisten Leute wissen. Es im Wesentlichen ermöglicht einfache senden/empfangen 00:05:04.250 --> 00:05:09.370 von Browsern. So der Gedanke steht immer möglich gemacht, Sie haben 00:05:09.420 --> 00:05:14.320 die STPI mit SCTP. Sie erreichen senden Nachrichten, Nachrichten zu empfangen, 00:05:14.370 --> 00:05:18.920 mit COR jetzt macht es viel einfacher Browser und websites 00:05:18.970 --> 00:05:23.650 Integration und wir beschäftigen das heute ausführlich. 00:05:25.010 --> 00:05:29.530 Auf ähnliche Weise Art von Hilfe mit Leistung sowie Skala 00:05:29.580 --> 00:05:34.760 für HTTP-Sender haben wir die Batchverarbeitung ist jetzt verfügbar. 00:05:35.200 --> 00:05:43.980 Und dann Client Side Perf Paar Was ist, wenn Sie sind Leistungsindikatoren 00:05:44.030 --> 00:05:46.900 eine Anwendung wirklich bringen die kompliziert ist, oder Sie sind 00:05:46.950 --> 00:05:50.450 Gehen für die Ausführung in unterschiedlichen Umgebungen, Sie müssen vielleicht 00:05:50.500 --> 00:05:53.340 Debuggen und möglicherweise müssen Sie das Profil sodass wir Client hinzugefügt haben 00:05:53.390 --> 00:05:57.890 Seite Leistungsindikatoren der gesendeten Nachrichten pro Sekunde, Buchstaben pro Sekunde 00:05:57.940 --> 00:06:01.460 und Dinge wie das, was wirklich können, hilfreich, wenn Sie Profile 00:06:01.510 --> 00:06:05.250 Was Sie in Nachrichten Ebene ist tun Sie sind insgesamt gegenüberliegenden 00:06:05.300 --> 00:06:09.020 Gelegenheit macht. So werden die dann manifest für diese Leistungsindikatoren 00:06:09.070 --> 00:06:14.230 Indikatoren als Teil des NuGet-Paket in, sodass es wirklich ermöglicht 00:06:14.280 --> 00:06:17.550 Sie können einige gute debugging ist. 00:06:20.550 --> 00:06:23.340 Und schließlich auf für Warteschlangen für unzustellbare Nachrichten. 00:06:23.880 --> 00:06:27.380 Deadlettering ist ein äußerst leistungsfähiges wo es schützt Feature 00:06:27.430 --> 00:06:30.820 Falls unzustellbar sind, sind Back-ends Nachrichten. In der Regel sind 00:06:30.870 --> 00:06:34.620 als unzustellbar Warteschlange bezeichnet, wenn Sie versuchen eine Nachricht empfangen und der 00:06:34.670 --> 00:06:38.600 Nachricht ist nicht formatiert, oder es ist ein Fehler im Code an einer beliebigen Stelle 00:06:38.650 --> 00:06:42.080 auf in den de Civilizer an einer beliebigen Stelle wo Sie nicht öffnen können 00:06:42.130 --> 00:06:44.560 die Nachricht und die Back-End-abstürzt. 00:06:45.780 --> 00:06:50.390 Service Bus bietet die Möglichkeit Festlegen der maximale Lieferung 00:06:50.440 --> 00:06:54.420 die Standardeinstellung 10, und welche ist Anzahl Es bedeutet, wenn wir finden Sie unter 00:06:54.470 --> 00:06:57.660 dass wir die Nachricht übermittelt haben Sie haben 10 Mal und Sie 00:06:57.710 --> 00:07:01.310 nicht erfolgreich die Nachricht, werden wir sie bewegen 00:07:01.360 --> 00:07:03.240 der Hauptwarteschlange in der Warteschlange für unzustellbare Nachrichten. 00:07:03.870 --> 00:07:07.930 Trägt dazu bei, das buchstäblich Ihrer Anwendungen standardmäßig stabil sein 00:07:08.190 --> 00:07:12.840 ohne dass Sie ein einzelnes schreiben Codezeile und schützen 00:07:12.890 --> 00:07:18.660 Back-End-Servern. In diesem Fall auf ist die Fähigkeit, Kanal 00:07:18.710 --> 00:07:23.810 Nachrichten erstellen automatisch rich. Meldungsflüsse und jetzt 00:07:23.860 --> 00:07:30.000 eine Anwendung dauert nun möglicherweise 6, 8, 10, Warteschlangen und auf 00:07:30.050 --> 00:07:34.450 für alle in Warteschlange für unzustellbare Nachrichten eine einzelne Warteschlange, d. h. 00:07:34.500 --> 00:07:38.530 Jetzt haben zentral jetzt Sie alle nicht verarbeitbare Nachrichten empfangen 00:07:38.980 --> 00:07:42.340 unabhängig davon, wie viele Warteschlangen oder Themen oder Abonnements Sie 00:07:42.390 --> 00:07:46.280 so verwenden, dass ein muss die Funktion zu hinzufügen. 00:07:47.180 --> 00:07:49.910 Wir umfassen, die in etwas genauer. 00:07:51.740 --> 00:07:57.570 Ich möchte schnell auf Wiederholung Wir haben seit im April durchgeführt. 00:07:57.620 --> 00:08:01.400 denn wenn wir heute in sprechen Skalierung und performance 00:08:01.450 --> 00:08:05.780 und Durchsatz sehen Sie eine Menge von Diese Funktionen, auf die verwiesen wird 00:08:06.180 --> 00:08:08.570 Ich wollte nur rufen Sie in Begriffe, ob sind Sie 00:08:08.620 --> 00:08:12.370 bereits heute verfügbar, und sie haben seit einiger Zeit aber 00:08:12.420 --> 00:08:16.250 Sie sind dort noch relevant. 00:08:18.520 --> 00:08:22.290 Das einzige hier dient. unterhalb der Zeile der ersten 00:08:22.340 --> 00:08:26.310 Service Bus Versprechen so im letzten Jahr haben wir den Service Bus 00:08:26.360 --> 00:08:28.900 1.1 für Windows Server-Version. 00:08:29.580 --> 00:08:33.210 Dies ist für vollständig symmetrisch. Warteschlangen- und Themen, in denen bedeutet 00:08:33.260 --> 00:08:37.450 Wenn beispielsweise SDK 2.1 abholen die letzten SDK war 00:08:38.470 --> 00:08:42.010 Sie werden entweder getroffen können der Dienst oder die Prämisse auf alle 00:08:42.060 --> 00:08:45.070 die verfügbaren Funktionen. 00:08:46.760 --> 00:08:51.600 Diese Art von Cloud-Version Trittfrequenz alle drei Monate Sie 00:08:51.650 --> 00:08:55.290 alle drei bis vier Monate sehen und lokal am 00:08:55.340 --> 00:08:59.520 mindestens einmal im Jahr ist, was wir versuchen Verwalten und schalten Sie dann beide 00:08:59.570 --> 00:09:02.680 die Funktion wird in der Parität. 00:09:05.540 --> 00:09:08.740 Daher ist dies für Sie später als Referenz an 00:09:08.790 --> 00:09:10.010 die Funktionen. 00:09:12.110 --> 00:09:13.310 Bisher noch Fragen? 00:09:15.820 --> 00:09:16.720 Ja, bitte. 00:09:16.730 --> 00:09:19.730 [Unverständlich] 00:09:19.950 --> 00:09:23.560 >> So war die Frage: Wann beginnt das nächste Update werden und wo 00:09:23.610 --> 00:09:28.920 2.3, bringen neueste Funktionalität vorhanden. 00:09:28.970 --> 00:09:33.240 Jetzt habe ich keine Datumsangaben rechts für den nächsten Dienst gemeinsam nutzen 00:09:33.290 --> 00:09:36.320 Bus-Version, aber es wird ein 2.2 oder eine 1.2 sein. 00:09:37.800 --> 00:09:42.620 Aber Sie können dies in der Regel denken bestimmte Version dieses Datum 00:09:43.340 --> 00:09:46.900 die Windows Server-Version übereinstimmen in den meisten Fällen versuchen Sie 00:09:46.950 --> 00:09:51.580 Server-Versionen so ausgerichtet Wir erhalten die maximale Plattform 00:09:51.630 --> 00:09:55.010 Nutzen Sie, wodurch wir sorgen dafür, dass wir haben größten Server mit den neuesten 00:09:55.060 --> 00:09:59.310 mit den neuesten-Clustering und ändert das Erscheinungsbild und alles. 00:09:59.360 --> 00:10:03.610 Also in der Regel nur die Führung übernehmen die die gleiche Art von Cadence 00:10:03.660 --> 00:10:05.820 Folgen. Gute Frage. 00:10:08.920 --> 00:10:13.130 Skalieren Sie auf Absender. Beginnen wir mit Dies im Hinblick auf die erste 00:10:13.180 --> 00:10:14.210 der Aspekt der Skala. 00:10:15.570 --> 00:10:18.650 Damit Absender ist nichts, aber irgendwo, wo Sie sind 00:10:18.660 --> 00:10:20.040 [Unverständlich] 00:10:20.000 --> 00:10:22.830 Sie können viele Szenarien vorstellen. Hier. Sie können Geräte vorstellen 00:10:22.880 --> 00:10:24.970 Telemetrie, Benutzeraktionen. 00:10:26.630 --> 00:10:31.030 Und Ihre Systeme, das Generieren von Ereignissen und B, B-Art von Szenario. 00:10:31.080 --> 00:10:32.910 Die Ereignisse generiert. 00:10:33.640 --> 00:10:37.660 Wie Sie Szenarien kümmern Wo haben Sie eine Menge 00:10:37.710 --> 00:10:41.620 oder vielleicht ein Paar von ihnen mit einer Menge Ereignisse oder viele Absender 00:10:41.670 --> 00:10:45.250 mit einer Vielzahl von Ereignissen? Alle diese Gibt mögliche Szenarien. 00:10:46.830 --> 00:10:50.480 Damit wir es konkret eingesetzt werden. Wir werden beginnen Sie mit einem tatsächlichen Szenario 00:10:50.530 --> 00:10:54.510 Welche Kunden werden heute verwenden also, in dem Sie zu haben 00:10:54.560 --> 00:10:58.850 Sammeln von Ereignissen für die Analyse von eine große Anzahl von Geräten. 00:11:00.370 --> 00:11:05.900 Diese Geräte können bekannt vorkommen. aber das ist kein Zufall, 00:11:05.950 --> 00:11:11.000 Ich weder bestätigen noch verweigern. So es ein Gerät sein könnte. 00:11:11.050 --> 00:11:12.350 Es konnte ein Gerät sein. 00:11:13.160 --> 00:11:18.850 Jetzt all dies beginnt mit der Geräte können in Warteschlange 00:11:18.900 --> 00:11:24.250 Nachrichten, die der Lage, ein paar Themen oder ein Thema und push 00:11:24.300 --> 00:11:28.090 in eine Vielzahl von Informationen in diesem Kanal 00:11:29.520 --> 00:11:33.640 haben Sie eine Nachricht in einem Thema Sie können sich vorstellen, Sie können 00:11:34.710 --> 00:11:39.370 haben Sie mehrere Szenarien in der Sie möchten verwenden. 00:11:39.420 --> 00:11:43.330 Echtzeit-Analysen oder was Sie mit Ihrem eigenen Code tun wird 00:11:43.380 --> 00:11:48.570 wirklich immer sehr viel häufiger und beliebt. Machen die Leute 00:11:48.620 --> 00:11:53.840 Damit die Sitzung Orleans, gestern durchgeführt? Nun, wenn 00:11:53.890 --> 00:11:57.080 Sie haben, Haasau, Haasau Stück der Technik versucht 00:11:57.130 --> 00:12:02.580 zur Lösung dieses Problems der Ausführung Ihrer Code in einer verteilten Maßstab 00:12:02.630 --> 00:12:06.190 Mode, ob Sie zu tun haben Ereignisse, die gerade generiert werden 00:12:06.240 --> 00:12:10.830 durch eine große Anzahl von Absendern und sind korreliert jede Richtung. 00:12:12.020 --> 00:12:15.930 Wie stellen Sie sicher, dass diese sind Back-End-Systeme voneinander getrennt. 00:12:15.980 --> 00:12:18.590 Wie stellen Sie sicher, dass diese Back-End-Systeme sind in der Lage 00:12:18.640 --> 00:12:24.640 Verarbeiten von Nachrichten mit dieser Geschwindigkeit und handeln Möglichkeiten, in dem sie stabil sind? 00:12:25.950 --> 00:12:29.560 Und für die Sie Themen in die mittleren. In diesem Fall Themen nicht nur 00:12:29.610 --> 00:12:33.440 Geben Sie die Pufferung, wie eine Warteschlange würde, d. h. 00:12:33.490 --> 00:12:35.950 die Back-End kann ausgeführt werden, um ein paar Stunden und Sie nicht 00:12:36.000 --> 00:12:39.060 verlieren Sie eines der Ereignisse. Die Ereignisse weiterhin dort bleiben jedoch 00:12:39.110 --> 00:12:40.490 Darüber hinaus stellt Ihnen Sub Pub. 00:12:41.470 --> 00:12:45.530 Das bedeutet, dass, wenn Sie andere Systeme, die gerade dabei sind 00:12:45.580 --> 00:12:51.310 Statusverfolgung, sagen wir setzen Werte in Azure Kabel oder 00:12:51.360 --> 00:12:56.520 Sie machen Analytics mit batch Verknüpfen Sie die Dateistruktur in 00:12:56.570 --> 00:13:00.330 AUF und führen Sie dann Hadoop Aufträge auf. 00:13:01.400 --> 00:13:05.850 Oder sie Höhe setzen Sie sind Daten in einem Datawarehouse SQL 00:13:05.900 --> 00:13:09.170 und BI-Abfragen ausführen hinzu kommt, dass. 00:13:09.790 --> 00:13:13.980 Diese Systeme können Schau Bei den gleichen Ereignisstream. 00:13:15.280 --> 00:13:18.350 Und nicht nur denselben Stream von Ereignissen, Sie können betrachten Ereignis 00:13:18.400 --> 00:13:21.780 Stream, zu. Vielleicht die BI Warehouse arbeiten, Sie möchten nicht verarbeiten 00:13:21.830 --> 00:13:25.870 alle Ereignisse. Nichts mit Bezug Ereignisse gehören nicht vorhanden. 00:13:25.920 --> 00:13:29.420 Sie gehören nur für das Material Code. Sie können die Datenströme aufteilen. 00:13:29.470 --> 00:13:30.210 auf diese Weise. 00:13:32.750 --> 00:13:36.990 Und dann aus der Back-End, ob Sie lesen Ihre Azure 00:13:37.040 --> 00:13:41.730 Tabellen oder SQL Datawarehouse Sie können Ihre Bash generieren. 00:13:41.780 --> 00:13:43.200 Karten und Analysen. 00:13:44.750 --> 00:13:45.750 Einer der Schlüssel 00:13:46.970 --> 00:13:49.340 Entwerfen Sie Punkte in diesem Paket. 00:13:50.180 --> 00:13:52.920 Zuerst verwenden Themen für den Lüfter. 00:13:53.960 --> 00:13:57.730 Der Lüfter im Wesentlichen bedeutet, dass Sie weniger als Sie Themen haben. 00:13:57.780 --> 00:13:59.900 Nicht wahr? Was sind das die Kardinalität sein kann. 00:14:01.080 --> 00:14:03.820 Es wird wahrscheinlich nicht sein ein. Es wird nicht möglich 00:14:03.870 --> 00:14:07.660 Thema für alles. Es ist wahrscheinlich nicht mehr n ermöglicht wird 00:14:07.710 --> 00:14:12.220 irgendwo dazwischen und als sein Wir sprechen, wie zu kommen 00:14:12.270 --> 00:14:13.860 mit dieser Nummer rechts. 00:14:14.410 --> 00:14:18.960 Sie werden für den Lastenausgleich über Rechenzentren aus mehreren Gründen. 00:14:19.320 --> 00:14:22.490 Wenn Sie diese Geräte Bedenken tatsächlich geografisch sind 00:14:23.190 --> 00:14:26.300 verteilt, sodass Sie vornehmen möchten Sie sicher, dass das Gerät verwendet die 00:14:26.350 --> 00:14:30.740 wenigste Energie, die niedrigste Wartezeit für Verbindung zu können 00:14:30.790 --> 00:14:33.770 zu erreichen, und die Daten in die Warteschlange. 00:14:35.480 --> 00:14:39.640 So ist es verteilt Daten zentriert. Damit diese Bus verfügbar ist. 00:14:39.690 --> 00:14:45.690 in allen Regionen Azure alle Rechenzentren. So haben Sie die Möglichkeit 00:14:45.740 --> 00:14:50.730 Themen rund um zu verbreiten. Auf jetzt bedeutet nicht Ihre Back-end 00:14:50.780 --> 00:14:53.890 abgetreten werden müssen auf alle diejenigen Orte zu. 00:14:54.880 --> 00:14:58.000 Bei Tatsache, wenn Sie denken, dass Hadoop Cluster, ist es in der Regel 00:14:58.050 --> 00:15:01.860 nicht etwas, das Sie in replizieren möchten Jeder Bereich in jedem Rechenzentrum. 00:15:01.910 --> 00:15:05.890 Aber das gibt Ihnen einen niedrigen Latenz Endpunkt. Von dort aus können Sie 00:15:05.940 --> 00:15:10.490 wo das Sammeln von Daten generiert. Und ziehen Sie Sie 00:15:10.540 --> 00:15:14.310 aus der Back-End. Über die Grenzen Um alle Regionen und 00:15:14.360 --> 00:15:18.450 Abonnements in den verschiedenen Regionen und die Zuordnung von Daten. 00:15:20.910 --> 00:15:23.690 True, Filter für alle Abonnements Dies ist in diesem vertikalen 00:15:23.740 --> 00:15:27.550 Kundenbeispiel, sie tatsächlich Warum alle ihre Daten und 00:15:27.600 --> 00:15:31.700 Code in Zustandsverfolgung und Stapelverarbeitung Analytics, aber nicht im BI. 00:15:31.750 --> 00:15:35.900 Damit alle diese drei tatsächlich wahr sind. Filter jedoch ein Abonnement 00:15:35.950 --> 00:15:39.960 hatte einen Reduzierung der Filter. Er hatte ein Filter, der sagte, wenn es ein Spiel ist 00:15:40.010 --> 00:15:45.060 Ereignis, dann wir interessieren sich nicht und Sie können tun. 00:15:45.110 --> 00:15:47.360 Batch und in Echtzeit-Analysen. 00:15:49.410 --> 00:15:53.110 In diesem Szenario dachte Wir werden in eine Demo springen. 00:15:54.270 --> 00:15:59.080 Und zeigen Sie das COR Funktionen zu unterstützen. 00:16:00.290 --> 00:16:05.680 Da viele Clients können aus der Perspektive erreichen 00:16:05.730 --> 00:16:11.600 nicht in Warteschlange Nachrichten, die nur mit reinen 00:16:13.270 --> 00:16:15.140 HTTP und so. 00:16:15.730 --> 00:16:21.550 Ich habe eine Website einrichten. Ihr seid kann zu treffen haben Sie 00:16:21.600 --> 00:16:25.950 ein Gerät oder ein Element. Der aufgerufene Hinweis Dateibenutzer führen den Azure 00:16:26.000 --> 00:16:28.260 Websites .NET. 00:16:29.750 --> 00:16:40.510 Alles, was ich hier ist sehr, sehr einfach JavaScript, ich wird 00:16:40.560 --> 00:16:41.160 Zeigen Sie an. 00:16:41.880 --> 00:16:43.280 Und was es tut 00:16:48.770 --> 00:16:53.470 stammt die Schlüsselwerte der basic Werte wie ihr Name ist 00:16:53.520 --> 00:16:58.790 Was ist der Name der Warteschlange Raum zu nennen, Geben Sie mir Ihre SaaS-Regel, die 00:16:58.840 --> 00:17:02.140 Gemeinsamer Zugriff Signatur Autorisierung Das ist, was verwendet wird 00:17:02.190 --> 00:17:03.800 und der SaaS-Schlüssel. 00:17:04.950 --> 00:17:07.970 Und auf der Grundlage, dass eine Nachricht zu senden. 00:17:14.280 --> 00:17:18.140 Die Nachricht wurde erfolgreich gesendet. Das ist es. Damit Sie sehen können, wenn Sie 00:17:18.190 --> 00:17:21.380 eine Riesenauswahl von Browserclients verfügen oder einem anderen Client oder 00:17:21.430 --> 00:17:25.940 Gerät, das nur die reine HTTP tun kann, Es gibt hier keine SEIFE. Es gibt keine... 00:17:26.900 --> 00:17:31.300 Codierung. Sie können die Nachricht einfügen. Eigenschaften in JSON und dann 00:17:31.350 --> 00:17:35.930 eine sehr einfache Möglichkeit Nachrichten abrufen in Warteschlange. Ich zeige 00:17:35.980 --> 00:17:38.170 Sie können den Code für diese Website. 00:17:47.070 --> 00:17:52.110 Hier sehen Sie, ob Sie sind Dabei reichen Eigenschaften 00:17:52.730 --> 00:17:55.220 oder sogar nur sehr, sehr grundlegende Eigenschaften, 00:17:58.440 --> 00:18:05.280 Sie können diesen Code einfach senden. Und in der Tat, die JavaScript-Bibliothek 00:18:05.330 --> 00:18:09.370 die hier verwendet wird, lassen Sie anzeigen, die Ihnen auch. 00:18:16.200 --> 00:18:22.410 Also die Webseite ist die ich zeigte, und Sie können sehen, wie 00:18:35.560 --> 00:18:40.400 einfache wirklich senden und die für diese Nachricht erhalten. 00:18:40.450 --> 00:18:44.840 HTTP, ist tatsächlich löschen für das Szenario empfangen. 00:18:45.430 --> 00:18:47.500 Die wir später sehen. 00:18:48.120 --> 00:18:56.600 Und die Put ist post senden Szenario, Es tut uns leid, soweit Szenario senden. 00:18:58.510 --> 00:19:02.420 Lassen Sie 00:19:03.620 --> 00:19:05.210 einigen weitere Nachrichten an mich senden. 00:19:05.810 --> 00:19:09.220 Und nur zum Anzeigen von Nachrichten zeigt sich, habe hier Server ich 00:19:09.270 --> 00:19:12.280 Beladen mit Explorer... 00:19:21.330 --> 00:19:25.310 Mein Name Space verbunden. Ich habe haben eine einfache-Warteschlange auf dem 00:19:25.360 --> 00:19:28.770 Sie sehen jetzt gibt es zwei Nachrichten in der Warteschlange. Wenn ich kein 00:19:28.820 --> 00:19:35.430 Aktualisieren, sehe ich 14 Nachrichten. So wie beim Nachrichten sie schaffen, 00:19:35.480 --> 00:19:37.840 wird für diese Warteschlange angezeigt. 00:19:48.480 --> 00:19:53.620 Wir behandeln das Szenario empfangen etwas später in Bezug auf die 00:19:53.670 --> 00:19:56.920 HTTP-Client. Das ist für den HTTP-Client. 00:19:57.510 --> 00:20:02.200 Aber ich wollte insbesondere sprechen über Protokolle. 00:20:02.820 --> 00:20:06.840 Was sind die Überlegungen, die Sie sollten bei der Entscheidung 00:20:06.890 --> 00:20:11.460 ob Sie HTTP verwenden oder verwenden die AMQP. Wie Sie wissen, dass Service 00:20:11.510 --> 00:20:13.930 Bus unterstützt verschiedene Protokolle. 00:20:15.060 --> 00:20:21.750 HTTP ist nur unsere RKDPI ist AMQP ein Standardprotokoll der 00:20:21.800 --> 00:20:27.620 Informationen darüber und unsere andere SBMP ist proprietäres Protokoll über .NET. 00:20:29.320 --> 00:20:35.000 Nun, jede dieser Perf Überlegungen haben und Überlegungen zu erreichen. 00:20:35.710 --> 00:20:39.950 Wenn Sie also ein Gerät auf dem ist sehr niedrig, mit Strom versorgt wird, können Sie 00:20:40.000 --> 00:20:44.810 Welches Protokoll Bedenken haben Implementierung können Sie setzen 00:20:44.860 --> 00:20:49.590 dort. Wenn Szenarien, in denen Sie werden von unabhängigen Hersteller möchten, 00:20:50.070 --> 00:20:54.160 Überlegungen zur Reichweite möglicherweise Hier kaufen nicht ich in 00:20:54.210 --> 00:20:57.830 Alle bestimmten Protokoll oder -API Bei einem Kreditor. Ich Gehe zu 00:20:57.880 --> 00:21:00.060 Verwenden Sie einen offenen Standard wie AMQP. 00:21:01.900 --> 00:21:04.390 Manchmal Funktionen nach Protokoll variieren. 00:21:05.130 --> 00:21:08.000 Und das Teil I hervorheben möchten die auf eine Menge von verloren geht 00:21:08.050 --> 00:21:11.300 Leute besteht hauptsächlich darin, dass erhalten Sie Features des. 00:21:11.950 --> 00:21:13.290 Es gibt einige Senderseite 00:21:14.560 --> 00:21:19.100 Auswirkungen, auch die meisten der Zeit es für den Empfang ist, 00:21:19.150 --> 00:21:23.270 Protokolle wirklich zurückgestellt werden ein los, und wir werden Warum sehen. 00:21:23.320 --> 00:21:24.240 der Fall. 00:21:25.950 --> 00:21:28.810 Und dann in der Regel gibt es einige Unterschiede in der Terminologie Kontingent 00:21:28.860 --> 00:21:32.360 wie viele Verbindungen können Sie Erstellen Sie mit AMQP und SBMP. 00:21:32.410 --> 00:21:35.550 Das sind also auch wichtige Überlegungen Wenn man, hey, 00:21:35.600 --> 00:21:38.980 Welches Protokoll soll ich verwenden für meine umfangreichen große Anzahl 00:21:39.030 --> 00:21:50.090 der Absender? So binäre Protokolle im Vergleich zu HTTP spielt Warum 00:21:50.140 --> 00:21:53.280 für messaging? Was sind die Schlüssel Überlegungen zum messaging? 00:21:53.810 --> 00:21:56.350 Ich wollte die Taste aufrufen Szenarien, in denen es macht, ein 00:21:56.400 --> 00:21:59.380 so können Sie wählen einen Unterschied und entscheiden, ob dies wichtig ist 00:21:59.430 --> 00:22:02.780 oder nicht für Ihren speziellen Fall. 00:22:04.210 --> 00:22:08.070 HTTP-Anfrage, jedes Mal, wenn Sie vornehmen ein Aufruf aus, wirst du sein 00:22:08.120 --> 00:22:11.480 Um eine Entität zu erreichen können. Damit die ein Endpunkt, ob es handelt 00:22:11.530 --> 00:22:13.850 ein Endpunkt senden oder einen Endpunkt empfangen. 00:22:14.850 --> 00:22:16.820 Sie können einem ausstehenden Vorgang tun. 00:22:17.560 --> 00:22:21.540 Senden Sie nur ein einzelnes Anruf oder einem einzigen Empfang-Aufruf. 00:22:22.370 --> 00:22:26.300 Und in den meisten Fällen, den Vorgang Lebensdauer nicht mehr als 00:22:26.350 --> 00:22:30.940 60 Sekunden oder was auch immer Ihre Last System zum Lastenausgleich kann entsprechend 00:22:31.480 --> 00:22:33.060 Provider Sie arbeiten. 00:22:34.490 --> 00:22:41.480 Also, die in eine Art bringt eine Case-Szenarios werden soll 00:22:41.530 --> 00:22:43.390 Um mehrere Endpunkte zu reden. 00:22:44.040 --> 00:22:47.590 Viele Male in direktionale kaufen Kommunikationsszenarios Sie sind 00:22:47.640 --> 00:22:51.230 wird gesendet werden, um eine Warteschlange zu wechseln und Empfangen von einem Abonnement. 00:22:52.080 --> 00:22:55.730 Oder auch senden, um eine Benachrichtigung zu wechseln. Hub. Alle diese Arten von 00:22:55.780 --> 00:22:57.060 Szenarien können vorhanden sein. 00:22:57.640 --> 00:23:01.320 Mit einem binären Protokolls Sie tatsächlich kann eine einzelne Verbindung erstellen 00:23:01.370 --> 00:23:08.270 ein einzelnes bISS ein Sockel, und alle Verknüpfungen in der 00:23:08.320 --> 00:23:13.320 AMQP Kontext ist ein multiflexed links über diese einzelne HTTP-Verbindung. 00:23:14.500 --> 00:23:18.740 So erhalten Sie viele Vorteile von nicht bezüglich den handshake 00:23:18.790 --> 00:23:22.680 und nicht mit diesem Socket hergestellt und so für jedes 00:23:22.730 --> 00:23:26.880 die bezahlen Entität im Vergleich zu tun... Kosten einmal und dann wiederverwenden 00:23:26.930 --> 00:23:29.460 Wenn Sie sprechen auf mehrere Entitäten. 00:23:30.290 --> 00:23:33.900 Denken Sie daran, dass Szenario. In einigen Fällen Beim Schreiben von Feld-gateways 00:23:33.950 --> 00:23:37.240 oder Sie benutzerdefinierte gateways viele Geräte, verfügen diese 00:23:37.290 --> 00:23:40.690 Sie werden ein sehr wichtiger Aspekt. 00:23:43.280 --> 00:23:48.250 Der andere Teil ist lang ziehen. So gibt es diese Konstante 00:23:48.300 --> 00:23:51.400 darum auf Warteschlangen, rechts der haben hey, ich eine Nachricht? 00:23:51.450 --> 00:23:55.160 Muss ich eine Nachricht? Habe ich eine Nachricht? Hier, weil es ist 00:23:55.210 --> 00:24:01.040 eine Verbindung für das AMQP-Protokoll Wir halten die Verbindung aktiv. 00:24:01.090 --> 00:24:04.370 Sie müssen jede operation Anders als eine ausstehende 00:24:04.420 --> 00:24:09.120 erhalten die für festgelegt werden konnte ein Timeout Infinity. Sie könnten 00:24:09.170 --> 00:24:12.110 für einen Tag, eine Woche ausgleichen. In der Regel Sie werden nicht das Ausgleichen 00:24:12.160 --> 00:24:16.090 für unendlich. Sie werden es entsprechend festgelegt. Die Shutdown-Merkmale 00:24:16.140 --> 00:24:19.560 aus, wie vielleicht 20 Minuten oder So etwas. Aber Sie 00:24:19.610 --> 00:24:24.920 kann eine lange Pull ausstehende empfangen haben und nicht zu befürchten haben. 00:24:24.970 --> 00:24:27.640 Wirbelnde CPU-Zyklen und so der 00:24:29.370 --> 00:24:33.080 das erste. Wir halten die Verbindung mit 00:24:33.130 --> 00:24:37.040 Pings oder was auch immer der Load-Balancer ist erforderlich, und wir liefern 00:24:37.090 --> 00:24:41.640 Sie die Antwort geringer Latenz Wann wird eine Nachricht. 00:24:42.360 --> 00:24:45.820 Damit wird eine weitere sehr wichtige in der Terminologie berücksichtigt 00:24:45.870 --> 00:24:50.380 Kosten sowie die Auswirkungen auf Gerät entfernt werden. So binäre Protokolle 00:24:50.430 --> 00:24:53.310 Nehmen Sie eine unterschiedliche Begriffe Szenarien. 00:24:56.240 --> 00:24:59.820 Der andere Aspekt der Protokolle bringt SDKs sind. 00:24:59.870 --> 00:25:03.520 Möchten Sie produktiv zu erhalten. Sie möchten festen Kern zu verwenden. Sie möchten 00:25:03.570 --> 00:25:08.220 solide-Bibliotheken verwenden. Damit Sie wirklich Wählen können möchten 00:25:08.270 --> 00:25:11.010 das richtige Protokoll das richtige SDK. 00:25:12.880 --> 00:25:13.950 Folglich wird für Service Bus 00:25:15.670 --> 00:25:19.750 Wenn Sie .NET, und klicken Sie dann auf unsere Standard verwenden SBMP Protokoll ist die Standardeinstellung. 00:25:19.800 --> 00:25:24.130 Das ist, was verwendet wird. Sie können wechseln Es AMQP zu einem beliebigen Zeitpunkt und 00:25:24.180 --> 00:25:25.170 Das ist auch gut. 00:25:25.850 --> 00:25:28.980 Es gibt einige empfohlene Abwehrmaßnahmen im Moment, aber wir schließen 00:25:29.030 --> 00:25:33.730 schon bald diese Lücke. Aber wenn Sie Mithilfe von .NET ist SBMP 00:25:33.780 --> 00:25:36.010 Art der Standardszenario heute. 00:25:37.560 --> 00:25:42.400 Wenn Sie HTTP, wenn das Verwenden des einen Fall haben wir HTTP-Wrapper auf eine Menge 00:25:42.450 --> 00:25:46.160 der verfügbaren Betriebssysteme und viele Bibliotheken zur Verfügung. 00:25:47.010 --> 00:25:50.510 Und klicken Sie dann mit AMQP Sie beginnen Viele der Gemeinschaft zu sehen 00:25:50.560 --> 00:25:51.700 Bibliotheken kommen. 00:25:52.940 --> 00:25:59.670 AMQP wird ein offener Standard wurde entworfene und entwickelte das alles dank einer 00:26:00.690 --> 00:26:05.690 unter Berücksichtigung der Tatsache, effiziente und zuverlässige, sind tragbare Sortieren von Daten 00:26:05.740 --> 00:26:10.310 Darstellung und Flexibilität Denken Sie daran. Flexibilität bei der Begriffe 00:26:10.360 --> 00:26:13.470 Gibt an, ob es den Clients ist Bibliotheken oder Client zu vermitteln 00:26:13.520 --> 00:26:15.120 oder auf Bibliotheken brach kaputt. 00:26:16.680 --> 00:26:20.260 So beginnen Sie mit den AMQP finden Sie unter Standardisierung moving Forward... 00:26:20.310 --> 00:26:26.370 Übrigens wurde AMQP standard OASIS last Oktober. Es deaktiviert nur ISO/IEC. 00:26:27.560 --> 00:26:32.950 Jetzt ist eine internationale erkannt Standard, zu. Damit die 00:26:33.210 --> 00:26:35.180 frisch aus der Presse. 00:26:36.990 --> 00:26:41.560 Aber was bedeutet es für Sie ist, dass Sie wird eine Reihe von Bibliotheken angezeigt werden. 00:26:42.230 --> 00:26:47.750 entwickelt von der Apache geheimnisvolle-Bibliothek Festlegen oder die Proton-Bibliothek 00:26:47.800 --> 00:26:51.010 Clients in verschiedenen Sprachen. 00:26:51.890 --> 00:26:55.240 C, Java, gibt es eine JMS-Implementierung. 00:26:56.110 --> 00:27:00.670 PHP. Alle diese sein verfügbar Sie mit der community 00:27:00.720 --> 00:27:05.970 Öffnen der Bibliothek Quell-Unterstützung für die Verwendung Entwicklung und einen Beitrag 00:27:06.020 --> 00:27:06.740 und 00:27:07.970 --> 00:27:12.310 mit Service plus oder bei einer anderen Anbieter unterstützt die 00:27:12.360 --> 00:27:14.070 AMQP Portal vorhanden. 00:27:14.820 --> 00:27:18.400 Wenn Sie versuchen, Service Bus zugreifen Sie können die verschiedenen Protokolle anzeigen. 00:27:18.450 --> 00:27:22.940 Sie haben viel Auswahl an was SDKs, die Sie verwenden und welche Bibliotheken 00:27:22.990 --> 00:27:34.850 Sie verwenden, und Sie werden müssen beschränkt auf eine bestimmte Weise. 00:27:34.900 --> 00:27:36.150 Sync, Async, im Vergleich zu Batch. 00:27:37.150 --> 00:27:40.650 Jetzt wissen wir, was sind die Nuancen Protokoll denke ich 00:27:40.700 --> 00:27:45.840 sollten wir sprechen darüber, wann sollte Wir schreiben einen Sync-Code asynchron 00:27:45.890 --> 00:27:49.170 Code-Batch-Code und was sind die wesentlichen Unterschiede in der Terminologie 00:27:49.220 --> 00:27:54.100 für Leistung, die Sie sehen können in diesen Szenarien. 00:27:55.890 --> 00:27:58.710 Batchverarbeitung wird deutlich Durchsatz erhöht. 00:27:59.460 --> 00:28:04.620 Es ist immer eine sehr gute Praxis in Bezug auf, ob sie verfügt 00:28:04.670 --> 00:28:09.260 auf der Empfangsseite oder sogar auf der Sendeseite Batchverarbeitung verwendet. 00:28:09.310 --> 00:28:13.190 Die einzige negative Sorge für Leute Manchmal ist das Wartezeit 00:28:13.240 --> 00:28:17.490 und wir werden sehen, wie das sein kann aber nicht zu viel betroffen. 00:28:17.540 --> 00:28:18.880 Wir müssen reden. 00:28:21.250 --> 00:28:24.830 Async ist im Allgemeinen immer die bewährte Methode. Sie möchten immer 00:28:24.880 --> 00:28:28.620 er wann immer möglich verwenden. Mit der Ausnahme die gebunden werden soll. 00:28:28.670 --> 00:28:31.760 die Anzahl der Aufrufe vor. Sie dass eine enge haben 00:28:31.810 --> 00:28:34.720 -Schleife, die eine unendliche Anzahl macht Anrufe und wir werden sehen, wie 00:28:34.770 --> 00:28:37.660 Service Bus hilft bei diesem Szenario. 00:28:40.160 --> 00:28:44.110 Und dann zum Schluss sehen wir die Binärdatei höherer Protokolle 00:28:44.160 --> 00:28:47.980 Durchsatz zu erreichen nur weil diese Protokolle, 00:28:48.030 --> 00:28:54.290 Das AMQP-Protokoll wurde entwickelt. Effizienz mit 00:28:55.260 --> 00:28:58.750 die Flusskontrolle und all das die Protokollebene integriert 00:28:58.800 --> 00:29:03.950 selbst sehen viele Vorteile angezeigt. Lassen Sie mich also tatsächlich 00:29:04.000 --> 00:29:08.550 Zeigen Sie einige Zahlen. Einige ausgeführt Zahlen, damit Sie vergleichen können 00:29:08.600 --> 00:29:10.090 Diese für sich selbst. 00:29:20.030 --> 00:29:24.820 So habe ich einige Code der ist wird versuchen, Nachrichten zu senden. 00:29:26.190 --> 00:29:28.970 Und Sie können sehen, dass ich unterteilt ist in drei Teile nach oben. 00:29:29.850 --> 00:29:32.930 Zuerst wird ein Sync senden ausgeführt. 00:29:33.690 --> 00:29:38.660 Hier werden die wichtigsten Positionen. Für jede Nachrichten, führen Sie eine qClient und senden 00:29:38.710 --> 00:29:44.060 Deaktivieren der Meldung. Dies ist ein sehr synchronisieren Rufen Sie. Gewicht für eine abzuschließen. 00:29:44.110 --> 00:29:48.030 Es wartet auf Bestätigung zu kommen vom Server erreichen. 00:29:48.080 --> 00:29:51.200 vom Client, eine vollständige Schleife und dann verschiebt. 00:29:52.910 --> 00:29:56.650 Bei der zweiten Verwendungsmöglichkeit wird es auf asynchrone Weise. 00:29:57.900 --> 00:30:02.780 Im Wesentlichen dem erstellt wird Asynchrone Vorgänge für alle diese 00:30:03.350 --> 00:30:04.470 Senden Sie Vorgänge. 00:30:05.700 --> 00:30:09.150 Und dann für alle warten die Aufgaben abgeschlossen. 00:30:11.410 --> 00:30:15.170 Und schließlich ist ein im Batch-Modus Senden und ich nennen es bestellt 00:30:15.220 --> 00:30:19.430 Batch senden, da mit asynchronen, Allgemein die Menschen kommen mit 00:30:19.480 --> 00:30:22.840 ein Szenario, in dem sie: hey sagen, mit Async, Verliere ich bestellen. Ich weiß nicht 00:30:22.890 --> 00:30:25.800 wissen Sie, welches zuerst geschieht, Welche wird als Nächstes geschehen. 00:30:26.300 --> 00:30:29.430 Und genau deshalb gibt es Stapel senden die Art der überlegen ist. 00:30:29.480 --> 00:30:32.300 in beiden Fällen da beibehalten alle der... entweder die gesamte 00:30:32.350 --> 00:30:35.920 Stapel wird durch oder die gesamte Batch zurückkehrt, und Sie werden 00:30:35.970 --> 00:30:38.910 wie viel nach Leistung Auswirkungen, die dies haben kann. 00:30:40.310 --> 00:30:45.300 So habe ich alle diese zeigen eine einfache am Beispiel der Nachrichtenwarteschlange. 00:30:45.350 --> 00:30:47.900 Sie sehen jetzt die Anzahl der Warteschlangen ist 0 (null). 00:30:48.910 --> 00:30:52.560 Und ich habe meine Anzahl Nachrichten festgelegt auf eine kleine Anzahl von 100. 00:30:53.660 --> 00:30:54.780 Wir starten. 00:30:57.310 --> 00:30:59.530 Und sehen, wie weit wir kommen. 00:31:00.250 --> 00:31:04.670 Also, zunächst macht senden mit es Sync. So synchron vornehmen. 00:31:04.720 --> 00:31:09.020 100 Anrufe von meinem Laptop alle die Möglichkeit, den Dienst und zurück. 00:31:09.550 --> 00:31:13.970 Dauerte etwa zehn Sekunden ausgedrückt Das. Und Sie zeigen 00:31:14.020 --> 00:31:18.360 Wir können kommen zurück, prüfen auf die Anzahl der Nachrichten, und es sollte 00:31:18.410 --> 00:31:21.860 jetzt bei 100 sein. Alle 100 Nachrichten haben hier gemacht. 00:31:23.160 --> 00:31:26.940 Jetzt Mal sehen, was passiert, wenn Die gleiche Technologie für Async zu tun. 00:31:29.190 --> 00:31:30.590 Das gleiche mit Async. 00:31:31.940 --> 00:31:36.120 Und keinen Unterschied in der Begriffe Nachrichten da 00:31:37.540 --> 00:31:40.460 die Meldungen haben alle gemacht Hier. Es ist jetzt 200 Nachrichten. 00:31:41.250 --> 00:31:46.450 .3 Sekunden dauerte. Für alle, die Nachrichten rein. 00:31:50.260 --> 00:31:52.620 Mit Batch ist es sogar noch schneller. 00:31:53.370 --> 00:31:54.990 Es ist sogar noch schneller. 00:31:56.080 --> 00:31:58.880 Der Grund ist wieder da unter dem Deckel Service Bus 00:31:58.930 --> 00:32:04.440 wird unter Verwendung eines binäres Protokolls so, wenn Sie haben uns Nachrichten asynchron, 00:32:04.490 --> 00:32:09.600 Wir sind Tabelle, um sie zusammen Aufteilung und Senden sie über mit impliziten Batchverarbeitung. 00:32:10.260 --> 00:32:13.630 Sie erhalten, diesen Wert festzulegen. Die Batch leeren Intervall, was Sie 00:32:13.680 --> 00:32:17.710 für eine messaging-Factory festgelegt, ermöglicht Sie können dieses Fenster festgelegt. 00:32:18.310 --> 00:32:21.010 Sie können es zu einem breiteren Fenster festlegen. Sie sehen mehr Latenz 00:32:21.060 --> 00:32:23.690 aber Sie werden viel besser sehen End-to-End-Durchsatz. Sie können 00:32:23.740 --> 00:32:27.310 Legen Sie diese auf einem viel kleineren Fenster und Sie erhalten eine bessere Latenz 00:32:27.360 --> 00:32:32.110 und vielleicht ein wenig geringer Durchsatz. Aber Sie sehen die 00:32:32.160 --> 00:32:36.660 Betrag der Differenz es hier in Bezug auf die Synchronisierung mit macht 00:32:36.710 --> 00:32:38.410 im Vergleich zu asynchronen im Vergleich zu Batch. 00:32:45.080 --> 00:32:49.310 Also Mal schnell sehen, die Wir haben unsere 300 Nachrichten hier, 00:32:49.360 --> 00:32:51.110 Was können wir auf der Empfangsseite? 00:33:02.730 --> 00:33:06.700 Darüber zu erhalten Sie, beachten Sie, dass ich nicht Mithilfe der bei Meldung APIs. 00:33:08.710 --> 00:33:12.460 Dies wird nur erläutert, eine Äpfel Um richtige Vergleiche von dem, was 00:33:12.510 --> 00:33:15.560 die Art von APIs aussehen synchronisieren anschließend zeige ich Ihnen wie die 00:33:15.610 --> 00:33:18.370 die API auf Nachricht werden alle Diese Funktionen für Sie. 00:33:20.100 --> 00:33:23.620 Dies ist eine Synchronisierung erhalten. 00:33:24.300 --> 00:33:28.740 So habe ich genau zwei aufgerufen wird versucht, den Server so diese 00:33:28.790 --> 00:33:33.600 in der Terminologie die Nachricht verarbeitet. Sie verlieren nie 00:33:33.650 --> 00:33:38.280 eine Nachricht bei der Übertragung oder bei der Übertragung Da bis Sie nicht aufrufen 00:33:38.330 --> 00:33:41.950 Führen Sie, wir senden Sie sichern die gleiche Meldung. 00:33:43.810 --> 00:33:48.260 Der nächste ein Async und hier ist Sie sehen, was ich mache 00:33:49.430 --> 00:33:56.230 ist ein Vorgang mit auf fort Rufen Sie dann dort die vollständige. 00:34:01.730 --> 00:34:05.290 Und ich wartet erneut für alle Schnitzerei Aufgaben abgeschlossen 00:34:05.340 --> 00:34:07.770 vor dem Aufruf von meinem Stoppuhr durchgeführt. 00:34:09.300 --> 00:34:10.660 Und schließlich gibt es Batch. 00:34:11.330 --> 00:34:12.950 Batch ist etwas interessanter. 00:34:13.890 --> 00:34:19.030 Hier ist es einfacher, da ich Führen erhalten Sie Batch, Schreiben Sie erfolgreich 00:34:19.080 --> 00:34:21.370 eine Anzahl von Nachrichten Es ist 100. 00:34:22.040 --> 00:34:24.860 Wenn Sie aufrufen erhalten Sie jetzt batch mit hundert bedeutet nicht wir 00:34:24.910 --> 00:34:28.830 hundert Nachrichten erhalten Sie Sichern. Es werden wir immer 00:34:28.880 --> 00:34:32.660 optimale für die Leitung basiert wird konkurrieren Sie im Consumer, 00:34:32.710 --> 00:34:35.970 basierend auf der Anzahl der anderen Knoten haben Sie ziehen angezeigt 00:34:36.020 --> 00:34:38.800 einen optimalen Stapel erstellen und senden Sie. 00:34:39.610 --> 00:34:43.320 Und das ist, warum Sie sehen, ich habe ein äußere Schleife die hält aufrufen 00:34:43.370 --> 00:34:47.620 erhalten Sie Batch, bis ich einmal nicht Meine hundert Nachrichten. Ich möchte 00:34:47.670 --> 00:34:51.430 Diese Berechnung Batchverarbeitung bis zu tun Sie erreichen hundert Nachrichten. 00:34:53.920 --> 00:34:59.030 Und in dem Fall werde ich nur auf die gesperrten Token enthalten. 00:34:59.080 --> 00:35:01.160 Das ist alles, was, die ich mache auf die Nachricht. Der muss ich nicht beibehalten 00:35:01.210 --> 00:35:04.440 die gesamte Nachricht. Einmal haben verbraucht die Nachricht wurde verarbeitet 00:35:04.490 --> 00:35:07.710 Es wird nur habe lassen die Lock-Token und rufen dann 00:35:07.760 --> 00:35:12.940 den vollständigen Stapel Async mit allen die gesperrten Token vorhanden. 00:35:14.060 --> 00:35:16.940 Und ich tue dies pro batch also bin ich nicht darauf warten 00:35:16.990 --> 00:35:19.490 ganz bis zum Ende zu Führen Sie alle Nachrichten? 00:35:19.500 --> 00:35:21.500 [Unverständlich] 00:35:21.660 --> 00:35:22.750 .. .subset vorhanden? 00:35:23.510 --> 00:35:24.840 >> War leid, was die Frage? 00:35:24.890 --> 00:35:28.400 >> Wenn Sie einige dieser verarbeiten können Nachrichten, konnte Sie abgeschlossen. 00:35:28.450 --> 00:35:30.520 Diese Tests eine Teilmenge durchführen? 00:35:30.860 --> 00:35:34.510 >> Absolut. Auf jeden Fall. So führen Sie Stapel Async. 00:35:35.250 --> 00:35:39.040 Sie können mit einem einzelnen gesperrten Token aufrufen. zwei gesperrten Token, was 00:35:39.090 --> 00:35:42.720 die Gruppe ist. Es ist nur, dass es wird Alle diese gesperrten Tokens senden 00:35:42.770 --> 00:35:46.250 in einem Batch und erhalten Sie wieder die Ergebnisse in einem Batch. Daher hat es 00:35:46.300 --> 00:35:50.010 Speichern Sie, dass sich Latenz und Übertragungszeit für übernimmt die gesamte 00:35:50.060 --> 00:35:52.540 und machen es sehr effizient. 00:35:54.300 --> 00:35:56.070 Mal sehen, was bis zu hinzufügt. 00:35:58.400 --> 00:36:03.230 So habe ich den gleichen Fall. Ich bin Zunächst wird Synchronisierung und 00:36:03.280 --> 00:36:07.440 Versuchen Sie, alle 100 empfangen... die ersten hundert Nachrichten 00:36:07.490 --> 00:36:11.190 dort. Jetzt Beachten Sie, dass dies noch schlimmer werden Leistung auf, als da senden 00:36:11.240 --> 00:36:14.080 Es ist doppelt so viele Vorgänge ausführen. Deshalb möchte ich erhalten 00:36:14.130 --> 00:36:16.460 Jede Nachricht, jeder Nachricht abgeschlossen. Jede Meldung 00:36:16.510 --> 00:36:20.110 Führen Sie jede Nachricht. Und Klicken Sie dann auf go. In diesem Fall 18 Sekunden. 00:36:20.160 --> 00:36:24.220 Anstatt zehn sendet hatten wir gesehen Senden dauert es 18 Sekunden 00:36:24.270 --> 00:36:28.760 Diese Nachrichten und vollständige Diese. Auf jeden Fall nicht so gut. 00:36:30.090 --> 00:36:35.330 Mit asynchronen, da Sie ein paar tun Diese parallele jetzt Sie nach unten, um 00:36:35.380 --> 00:36:38.880 über die 2,8 Sekunden. Nun, Diese Zahlen sind... 00:36:39.410 --> 00:36:43.230 Nehmen sie mit Vorsicht, in einem Netzwerk hier ausgeführt wird, sind 00:36:43.940 --> 00:36:47.470 aber Sie sehen nur die Helligkeit der Unterschied. Sie können anzeigen 00:36:47.520 --> 00:36:49.620 wie viel von einer Verbesserung der dies der Fall ist. 00:36:50.830 --> 00:36:52.580 Und nun sehen wir, was Mit Batch geschieht. 00:36:55.730 --> 00:37:00.720 Wir sind wieder. Wir können das gleiche tun fast Merkmale wie 00:37:00.770 --> 00:37:04.590 0,1 Sekunden für alle hundert Vorgänge, die genommen hatte... 00:37:05.410 --> 00:37:07.930 nur weil wir verwenden Stapel vorhanden. 00:37:11.380 --> 00:37:16.640 Nun, nicht nur alle sehen Sie die Vorteile in hier aber Service 00:37:16.690 --> 00:37:21.680 Bus erleichtert tatsächlich sehr, sehr Sie Schreiben dieser Code. 00:37:21.730 --> 00:37:26.700 Der Code, den ich Ihnen gezeigt ist nicht sehr komplexe, aber Sie tatsächlich 00:37:26.750 --> 00:37:29.280 es noch einen Schritt weiter, und wir war es noch einfacher. 00:37:30.200 --> 00:37:33.470 In diesem Fall für die die Art und Weise, wie einfach ich... Wollten Sie zeigen hier auf die 00:37:33.520 --> 00:37:37.280 Nachrichten, die Sie 300 Nachrichten finden Sie unter vorhanden, wenn er aktualisiert, es 00:37:37.330 --> 00:37:41.920 sollte auf 0 (null), der angibt, zurück Ich bin kein Lügner. Alle diese 300 00:37:41.970 --> 00:37:43.380 Nachrichten wurden verarbeitet. 00:37:47.270 --> 00:37:54.910 Nun gut. So werden wir die Nachricht bei betrachten APIs, aber im Interesse 00:37:54.960 --> 00:37:57.880 Zeit werde Geschwindigkeit ich Hier ein wenig nach oben. 00:38:00.480 --> 00:38:04.820 Also haben Sie gesehen, dass den Unterschied zwischen Sync, Async und Stapel, und 00:38:04.870 --> 00:38:10.330 Ich hoffe, dass [Indiscernible] immer verwenden Batchverarbeitung. Nächstes zum Durchsatz. 00:38:10.380 --> 00:38:14.100 Partitionierte Warteschlangen und Themen. Damit wir SDK 2.2 veröffentlicht. 00:38:15.680 --> 00:38:19.590 Warteschlangen und Themen im Wesentlichen partitionieren Nehmen Sie eine Warteschlange und partition 00:38:19.640 --> 00:38:21.830 es über mehrere Knoten der Verarbeitung. 00:38:23.240 --> 00:38:26.950 Dadurch werden nicht nur viel mehr Power im Hinblick auf Durchsatz 00:38:27.000 --> 00:38:31.900 werden mehr Nachrichten verarbeiten, aber Es gibt Ihnen mehr Speicherkapazität. 00:38:32.410 --> 00:38:35.820 Es gibt Ihnen die Möglichkeit größere Warteschlangen. Es gibt 00:38:35.870 --> 00:38:38.170 Sie können weniger anfällig sein. 00:38:39.270 --> 00:38:42.290 Wenn eine Partition nicht verfügbar ist, eine andere Partition kann weiter. 00:38:42.340 --> 00:38:43.580 um Nachrichten zu verarbeiten. 00:38:44.640 --> 00:38:49.270 So Partitionieren Sie Warteschlangen nach und nach weit in den meisten Szenarien erhalten 00:38:49.320 --> 00:38:52.990 Sie einen deutlich besseren Durchsatz Verfügbarkeit und Ausfallsicherheit 00:38:53.040 --> 00:38:58.570 Siehe Merkmal. Auspacken. Es geht ganz einfach erstellen und 00:38:58.620 --> 00:39:02.700 Verwenden Sie Partition-Warteschlangen, die es nur die Empfehlung 00:39:02.750 --> 00:39:06.470 Verwenden Sie immer diese. Immer verwenden Diese. In der Tat in den nächsten 00:39:06.520 --> 00:39:11.000 SDK-Version sind wir auf dem Weg zu machen Es Standard, standardmäßig 00:39:11.050 --> 00:39:13.380 Wenn Sie eine Warteschlange erstellen Sie eine partitionierte Warteschlange abrufen. 00:39:15.690 --> 00:39:20.650 Jetzt haben Sie wissen Was passiert, wenn Sie 00:39:20.700 --> 00:39:22.590 eine Warteschlange, und Sie eine partition auf. 00:39:24.060 --> 00:39:26.530 Wenn Sie keine Sitzungen, verwenden wir Sprechen Sie viel zu Sitzungen 00:39:26.580 --> 00:39:30.340 in Details, aber wenn verwenden Sie nicht Sitzungen und klicken Sie dann im Wesentlichen 00:39:31.060 --> 00:39:33.050 Sie müssen... 00:39:34.220 --> 00:39:38.380 Sie müssen bekannt sein, die Ihre Nachrichten möglicherweise nicht in der richtigen Reihenfolge angezeigt 00:39:38.430 --> 00:39:41.830 nun, da sie im Grunde können Wechseln Sie in die einzelnen Partitionen 00:39:41.880 --> 00:39:46.770 und wenn Sie eine Partition nicht zur Verfügung steht, wird die Meldung angezeigt wird 00:39:46.820 --> 00:39:47.720 kaputt. 00:39:48.460 --> 00:39:51.270 Das ist eine Sache zu beachten aber wenn Sie Sitzungen verwenden, 00:39:51.320 --> 00:39:54.720 wir heute sprechen werden dann alle Ihre Bestellung Semantik 00:39:54.770 --> 00:39:56.100 bleiben vollständig erhalten. 00:39:57.120 --> 00:40:02.330 Und wir werden sehen, wie. Sie zeigen der Code hier, wann immer Sie sind 00:40:02.380 --> 00:40:05.590 Erstellen einer Warteschlange gibt es eine einzige EnablePartitioning-Eigenschaft. 00:40:05.640 --> 00:40:08.720 Es ist heute standardmäßig auf False festgelegt. Wie, in den nächsten gesagt 00:40:08.770 --> 00:40:10.040 SDK wahr werden. 00:40:10.780 --> 00:40:13.750 So sollten Sie nur das festlegen. Durch die Möglichkeit, ich weiß nicht, wie Sie 00:40:13.800 --> 00:40:18.770 Leute machen in der Regel aber meine Philosophie im Allgemeinen ist nie kopieren 00:40:18.820 --> 00:40:20.730 Code, der in eine PowerPoint angezeigt. 00:40:21.330 --> 00:40:24.470 Ich weiß nicht, ob das für funktioniert Euch. Es ist nie zu kopieren 00:40:24.520 --> 00:40:28.150 Code, der in PowerPoint da angezeigt die vereinfachte werden 00:40:28.590 --> 00:40:32.710 und Basic codieren die jeder Art von kann da draußen. In diesem 00:40:32.760 --> 00:40:35.500 Fall ist es OK. Sie sind lediglich festlegen. eine Eigenschaft, sind so gut ist. 00:40:35.550 --> 00:40:38.540 Aber wenn ich jemals zeigte, dass Sie code in PowerPoint nicht kopiert werden. 00:40:40.650 --> 00:40:46.660 In diesem Fall Verbindungsdurchsatz. Wir Sprachen zum Absender. Wir haben gesehen 00:40:46.710 --> 00:40:50.290 wie binäre Verbindungen sind wirklich wichtig ist. Es gibt 00:40:50.340 --> 00:40:55.090 einige Fälle, in denen Sie senden kann verwenden eine sehr Dicke Pipe. 00:40:55.660 --> 00:40:58.340 Betrachten Sie es als Ihre Backend-so sind wir möchten sich in der Warteschlangennachrichten. 00:40:58.390 --> 00:41:03.370 Sie haben eine Tonne Protokolle Sie die gewünschten Push-Up und so was. 00:41:04.400 --> 00:41:08.450 Erstellen nun zu einem bestimmten Zeitpunkt weitere können physische TCP-Verbindungen 00:41:08.500 --> 00:41:12.630 eine gute Idee sein, und Sie können machen Sie leicht. Jede Nachrichten 00:41:12.680 --> 00:41:16.220 in der Factory-Instanz für eine Klasse Instanz messaging-factory 00:41:16.270 --> 00:41:18.390 eine PCP-Verbindung entspricht. 00:41:19.390 --> 00:41:22.550 Mehr Anzahl der Warteschlangenclients und Dinge, die Sie erstellen 00:41:22.600 --> 00:41:25.680 Deaktivieren der selben Unternehmen wie ich gezeigt habe Sie sind Sie alle multiplexing 00:41:25.730 --> 00:41:31.430 die Verbindungen über denselben TCP-Socket. So erstellen Sie weitere messaging-Factorys. 00:41:31.480 --> 00:41:33.700 Und wenn Sie messaging erstellen Factorys, einfach mehr erhalten Sie 00:41:33.750 --> 00:41:38.720 Rohre und mehr Daten können weitergegeben werden durch so ein wichtiges Kriterium für 00:41:38.770 --> 00:41:42.540 für diese. Verbindung Ebene Ausfallsicherheit ist integriert. Also, wenn Sie 00:41:42.590 --> 00:41:46.140 Erstellen eine messaging-Factory Sie keine es verworfen. 00:41:46.190 --> 00:41:49.320 Wenn die Verbindung unterbrochen wird, werden wir Erstellen Sie ihn neu. Wenn Ihre Verbindung unterbrochen 00:41:49.370 --> 00:41:52.740 für eine Warteschlange werden wir ihn neu erstellen. Was auch immer Es handelt sich um wird neu 00:41:52.790 --> 00:41:54.860 in Bezug auf das so nie dazu haben... 00:41:55.370 --> 00:41:58.030 Dieses Objekt Weg werfen und dieses Objekt neu. 00:41:58.310 --> 00:42:02.780 Nur mehr davon erstellen und wiederverwenden für so stark wie müssen Sie. 00:42:05.910 --> 00:42:07.540 So führt, die uns zu Sitzungen. 00:42:08.520 --> 00:42:11.670 Da sage ich Sie nehmen Alle diese Absender große Anzahl 00:42:11.720 --> 00:42:14.910 der Absender und multiplex-alle in sehr kleinen Anzahl 00:42:14.960 --> 00:42:17.850 Warteschlangen werden Sie wie Um dies tatsächlich zu verarbeiten? 00:42:17.900 --> 00:42:21.110 Wir haben gesehen, Orleans Art des Rahmens und so, alle 00:42:21.160 --> 00:42:23.460 Versuch, den Stream übergeben (Demultiplexing), 00:42:24.720 --> 00:42:26.530 übergeben (Demultiplexing) in den Stream. 00:42:28.490 --> 00:42:33.070 Sitzungen ist großartig integriert Funktion in Service Bus 00:42:33.120 --> 00:42:37.130 im Wesentlichen erstellt Unterwarteschlangen. So können jede Sitzung Sie denken 00:42:37.180 --> 00:42:40.290 der als eine Unterwarteschlange bei einer vollen Warteschlange. 00:42:41.480 --> 00:42:44.860 Und die ursprüngliche Art nur die Sitzungs-ID festgelegt. 00:42:44.910 --> 00:42:46.840 Das ist die eine einzelne Eigenschaft Sie haben festgelegt. 00:42:48.090 --> 00:42:51.240 Der Empfänger ist, in dem die Paradigma wirklich ändert. 00:42:52.050 --> 00:42:56.090 Der Empfänger nun nicht mehr geht, und So geben Sie mir die nächste Nachricht. 00:42:56.140 --> 00:42:59.670 Der Empfänger sagt mir das nächste Sitzung. Geben Sie mir die nächste 00:42:59.720 --> 00:43:02.690 Unterwarteschlange hat einige Nachrichten und ich denke, dass in Verarbeitung 00:43:02.740 --> 00:43:06.760 Bestellen Sie, ich Gehe mit verarbeiten Ein Zustand, die ich speichern können 00:43:06.810 --> 00:43:10.600 für diese Empfänger. Wenn Sie der Meinung sind über Millionen von Geräten, 00:43:10.650 --> 00:43:13.290 Jetzt können Sie auf einem einzigen halten Warteschlange, können Sie diese Werte haben 00:43:13.340 --> 00:43:18.620 Millionen von Unterwarteschlangen und Speicher Status pro Unterwarteschlange. So sehr 00:43:18.670 --> 00:43:20.410 in diesem Sinne sehr leistungsfähig. 00:43:21.050 --> 00:43:24.400 Sie erreichen Arbeit festhalten Arbeit festgelegt. Das heißt, Sie können sagen. 00:43:24.450 --> 00:43:29.230 Empfänger eine, möchte ich zu lokalisieren Geräte 1 bis 100. Damit es 00:43:29.280 --> 00:43:32.810 gehen und Fragen nach Sitzungen 1 über 100 und wird fixiert werden 00:43:32.860 --> 00:43:33.440 mit dem. 00:43:35.000 --> 00:43:39.680 Und natürlich Sie können speichern Zustand. Damit werde ich Ihnen zeigen die 00:43:39.730 --> 00:43:43.490 der Code dafür. Führen Sie im Wesentlichen true, wenn die sicherte Sitzung 00:43:43.540 --> 00:43:45.270 Sie erstellen die Warteschlange. 00:43:45.790 --> 00:43:49.670 Auf der Sendeseite müssen Sie lediglich Legen Sie eine Eigenschaft, die Sitzungs-ID. 00:43:50.530 --> 00:43:55.720 Und klicken Sie dann auf Seite, erhalten alle die Anwenden derselben Art von Parametern 00:43:55.770 --> 00:43:59.840 So habe ich Sie, die Nachricht annehmen Sitzung, Sie können akzeptieren 00:43:59.890 --> 00:44:03.730 Sitzung mit der Kennung Message oder jetzt Was haben wir soeben veröffentlicht 00:44:03.780 --> 00:44:08.760 ist ein sehr einfacher Weg zu tun können. 00:44:11.810 --> 00:44:13.010 Empfänger der Sitzung. 00:44:14.920 --> 00:44:18.080 So werde ich einen Absender Sitzung öffnen. 00:44:18.970 --> 00:44:21.810 Wir haben bereits erkannt, dass Batchverarbeitung ist der beste Weg zu senden 00:44:21.860 --> 00:44:25.740 Alle Absender tut für jede Sitzung-ID, es wird 00:44:25.790 --> 00:44:30.240 wie viele Nachrichten als senden die Sitzungs-ID plus eins. Wenn sie hat 00:44:30.290 --> 00:44:33.480 Sitzungs-ID, ich werde senden zwei Nachrichten. Sitzung ist 00:44:33.530 --> 00:44:36.070 Zwei ID, ich werde senden drei Nachrichten und So weiter. 00:44:37.350 --> 00:44:38.920 So werde ich nur den Absender beginnen. 00:44:39.880 --> 00:44:43.910 Und hier, wenn Sie diese Warteschlange betrachten, Im Beispiel für Meldungswarteschlangen 00:44:44.580 --> 00:44:49.140 Wenn ich diese Warteschlange erstellt die zusätzliche nur eine Eigenschaft festgelegt 00:44:49.190 --> 00:44:55.090 Es war, die Session-Eigenschaft erforderlich. Das war der einzige Unterschied. 00:44:55.670 --> 00:44:59.940 Also wenn Sie zu diesem bestimmten wechseln Warteschlange, und Sie sehen, es hat 00:44:59.990 --> 00:45:02.440 können Sie folgende Eigenschaften, 00:45:08.230 --> 00:45:09.410 sehen Sie, dass... 00:45:11.710 --> 00:45:16.480 erfordert ist der Session-Eigenschaft False. Das ist nicht gut. 00:45:16.530 --> 00:45:20.780 Nun gut. Lassen Sie mich diese Warteschlange löschen. 00:45:24.670 --> 00:45:34.390 Erstellen Sie auf Nachricht Sitzung Sample. 00:45:37.280 --> 00:45:38.780 Sitzung erforderlich. 00:45:45.040 --> 00:45:47.020 Auf meinen Sender gelesen werden. 00:45:51.490 --> 00:45:53.840 So beginnt das Senden von Nachrichten an. 00:46:09.430 --> 00:46:18.880 Ich denke, das nicht gefunden werden jetzt Warteschlangenname. 00:46:18.890 --> 00:46:20.800 [Unverständlich] 00:46:20.870 --> 00:46:27.580 >> Habe das ich? Nachricht-Sitzungen... Oh, wechseln dorthin Sie. 00:46:29.640 --> 00:46:36.750 Perfekt. Lassen Sie mich das Ändern bis Nachricht Sitzung Sample. 00:46:39.450 --> 00:46:40.630 Vielen Dank. 00:46:42.100 --> 00:46:43.360 Jetzt führen wir diesen Typ. 00:46:46.770 --> 00:46:49.710 Damit sind fertig Sie. So senden alle Nachrichten. Ich zeige nun 00:46:49.760 --> 00:46:54.350 Sie liefern der code für diese aussieht. 00:46:55.510 --> 00:46:59.710 Dies ist die neue API, Wir haben gerade freigegeben, die auf 00:46:59.760 --> 00:47:02.010 Message Processing-API. 00:47:03.430 --> 00:47:07.500 Folglich wird in Ihren Azure Worker-Rolle Lassen Sie mich dies zu ändern. 00:47:10.890 --> 00:47:14.690 In Ihren Azure Worker-Rolle auf dem Klicken Sie auf Start-Methode würden Sie tun 00:47:14.740 --> 00:47:19.540 gleich, überprüfen nur, ob die Warteschlange vorhanden ist und erstellen Sie die qClient. 00:47:20.250 --> 00:47:24.120 In der Regel ausführen, beachten Sie die Code wird sogar noch einfacher. 00:47:25.610 --> 00:47:29.270 Alles, was, die Sie dies ist tun ein Register-Aufruf. 00:47:29.900 --> 00:47:32.770 Dazu registriert einen Handler für die Sitzung. 00:47:33.670 --> 00:47:36.500 Und das war 's. Keine Täuschung Schleifen zu schreiben. 00:47:37.120 --> 00:47:38.950 Keine Lebensdauer zu verwalten. 00:47:39.580 --> 00:47:43.920 All das ist erledigt von die Clientbibliothek für Sie. 00:47:43.970 --> 00:47:48.540 Sie müssen lediglich alle kapseln die Logik der wie Sie gehen 00:47:48.590 --> 00:47:53.790 in einem Datenstrom zu verarbeiten Klasse mit dem Namen der Session-Prozedur. 00:47:54.700 --> 00:47:57.450 Betrachten wir diese Klasse und sehen, was ich hier tue. 00:47:58.700 --> 00:48:02.660 Der erste Schritt ist, was wann muss ich tun Wird die Meldung eigentlich? 00:48:05.430 --> 00:48:09.430 Meldung bin ich einfach ausdrucken ich die Meldung habe und 00:48:09.480 --> 00:48:10.870 Ich habe meine zählen erweitern. 00:48:11.610 --> 00:48:15.320 Das ist alles, was, die ich mache in dieser Klasse. Count ist ein privater member 00:48:15.370 --> 00:48:19.860 hier, und wir diesen Wert nur speichern. 00:48:21.090 --> 00:48:22.960 Damit wir die Anzahl festlegen 00:48:24.710 --> 00:48:28.550 gleich 0 (null), und wir haben eine Anzahl Damit ist meine gesamte Verarbeitung ist. 00:48:29.270 --> 00:48:34.550 Auf geschlossene Sitzung geschlossen Sitzung wird aufgerufen, wenn keine 00:48:34.600 --> 00:48:38.750 Weitere Nachrichten für diese verfügbar Sitzung oder Sie wurde erreicht. 00:48:38.800 --> 00:48:42.360 Ihre maximale Währung zählen. Wir Sprachen über wie viele gleichzeitig 00:48:42.410 --> 00:48:43.630 Möchten Sie besitzen. 00:48:44.260 --> 00:48:48.230 Wenn Sie Max. erreicht haben wie viele Anzahl Parallelität 00:48:48.280 --> 00:48:53.040 Sitzungen zu verarbeiten, wir rufen in dieser Sitzung schließen und öffnen 00:48:53.090 --> 00:48:57.610 eine neue Sitzung je nachdem, welche Nachrichten sind verfügbar. So schließen 00:48:57.660 --> 00:49:00.700 Ihre Chance zu sagen, dass ich habe gelangt eine Reihe von Nachrichten, habe ich 00:49:00.750 --> 00:49:03.900 für diese spezielle bearbeitet Sitzung, und jetzt kann ich sollte 00:49:03.950 --> 00:49:05.580 Dieser Zustand gespeichert werden. 00:49:07.140 --> 00:49:10.730 Hier finden Sie alles, was, die ich tue, und ist der Status für Set und Get Aufruf 00:49:10.780 --> 00:49:15.250 Staat, der auf den Einwand der Sitzung ist. Dies sind im Wesentlichen Streams. 00:49:16.050 --> 00:49:20.770 Und entfernt den Count-Wert speichern Wann wird die Sitzung geschlossen. 00:49:21.780 --> 00:49:26.130 Und dann das endgültige ist der Fehler Wenn eine Sitzung verloren ist Fall. 00:49:27.420 --> 00:49:31.050 Jetzt denken Sie daran, den Grund, Sie können Alle diese Nachrichten korrelieren. 00:49:31.100 --> 00:49:34.310 Da wir für eine Sitzung gesperrt ist Sie können. Wir sorgen dafür, dass Du bist 00:49:34.360 --> 00:49:38.790 Wer erhält nur Empfänger Nachrichten für diese Unterwarteschlange, 00:49:38.840 --> 00:49:40.510 Diese bestehen. 00:49:41.190 --> 00:49:43.780 Und Sie können immer eine Sperre verlieren. Eine Sperre wäre da verloren 00:49:43.830 --> 00:49:47.660 eines Fehlers auf dem Server. Es könnte aufgrund der Verbindung verloren 00:49:47.710 --> 00:49:51.410 Probleme oder vielleicht Ihr Prozessor nur aufgehängt, sodass er die Sperre verloren 00:49:51.460 --> 00:49:55.290 Da eine Operation führen so können Sie immer dort 00:49:55.340 --> 00:49:58.940 Dieser Fehler aufgerufen. In diesem Fall Alles, was Sie tun werden die Abandon ist die 00:49:58.990 --> 00:50:03.500 lokale Gruppe von Änderungen und verschieben auf. In Bezug auf. 00:50:04.870 --> 00:50:07.150 Mal sehen, wie das aussieht. 00:50:07.670 --> 00:50:08.790 Eine Ausführung. 00:50:10.210 --> 00:50:10.800 War es eine Frage? 00:50:10.850 --> 00:50:11.930 >> Funktioniert das gleiche? 00:50:13.740 --> 00:50:17.500 >> Die Frage war: funktioniert dies für Abonnements? Hundert Prozent. 00:50:17.550 --> 00:50:21.170 Es ist vollständig symmetrisch. Gibt an, ob Sie sind aus einer Warteschlange empfangen. 00:50:21.220 --> 00:50:24.130 oder Sie aus einem Abonnement erhalten. 00:50:25.440 --> 00:50:28.920 So, hier ist jetzt mein Worker-Rolle. Lassen Sie mir was tatsächlich schnell überprüfen 00:50:28.970 --> 00:50:30.850 die Anzahl der Warteschlangen gesucht wie nach dem 00:50:32.060 --> 00:50:36.390 Rollen geschah senden. Sieht wie folgt aus verfügt über 3.700 Nachrichten richtig 00:50:36.440 --> 00:50:40.610 jetzt 33, sieht aus wie Verarbeitung in getreten ist. 00:50:41.650 --> 00:50:56.690 Lassen Sie mich in dort springen... Wir gehen. Es kommt. 00:50:56.740 --> 00:51:03.350 Gute. Also jetzt, sind meine Computer durchzugehen und Sie 00:51:03.400 --> 00:51:06.090 Verarbeiten von Tausenden sehen und Tausende von Nachrichten. 00:51:06.890 --> 00:51:10.740 Und der Code, den ich geschrieben habe, war sehr simpel denken 00:51:10.790 --> 00:51:15.170 über nur eine einfache Sitzung ein einzelnes Sitzung, und ich habe nicht 00:51:15.220 --> 00:51:18.800 Um eine einzelne Empfangsschleife zu schreiben. Ich habe gerade Pipe-Handler registriert werden musste. 00:51:19.200 --> 00:51:23.370 Prozedur, die bereits zuvor gezeigt wird. der einfache Fall, in dem Sie 00:51:23.420 --> 00:51:28.420 Instanzen dieser erstellt haben und Sie machen alle Initialisierungen. 00:51:28.450 --> 00:51:32.020 Wir haben eine Factory zurück, die ist auch verfügbar. Sie erreichen 00:51:32.070 --> 00:51:36.960 eine Handlerfactory Register und Möglichkeit die Erstellung zu steuern 00:51:37.010 --> 00:51:38.700 Semantik, die auch. 00:51:40.370 --> 00:51:43.560 Hier können Sie sehen, aber beibehalten Status und geschlossene Sitzung. 00:51:44.420 --> 00:51:48.340 Lassen Sie mich hier vergrößern, damit Leute können deutlich zu sehen, was passiert. 00:51:49.070 --> 00:51:54.740 Wenn Sie sehen, dass jeder Sitzung Sitzung 22 war für Sitzung 21. 00:51:54.790 --> 00:51:57.810 Der Sitzungszustand ist 46 für 45-Sitzung. 00:51:58.620 --> 00:52:03.770 Da diese Klasse nur Nachrichten haben die für die aktuelle Sitzung gehörte. 00:52:04.200 --> 00:52:08.320 Alles, was demuxen und muxen einfach alles behandelt wurde 00:52:08.370 --> 00:52:12.410 mit dem Service Bus für Sie. So, wenn Sie denken über multiplexing 00:52:12.460 --> 00:52:15.990 eine große Anzahl von Absendern in eine kleine Anzahl von Warteschlangen, weiß 00:52:16.040 --> 00:52:19.260 dass Sie nicht einfach zu verwendenden verloren haben nicht verarbeiten 00:52:19.310 --> 00:52:23.800 auf dem Back-End mit Ihnen Diese einzelnen streams 00:52:30.570 --> 00:52:34.260 dort. 00:52:37.740 --> 00:52:41.000 Sitzungsstatus, die wir gesprochen. Korrelation mithilfe von Sitzungen. 00:52:41.350 --> 00:52:46.020 Also nur zu tatsächlich zusammenfassen Bevor wir also zugreifen. 00:52:46.590 --> 00:52:49.230 Damit ein weiterer wichtiger Gesichtspunkt ist Wann haben Sie diese sehr, sehr 00:52:49.280 --> 00:52:52.530 große Anzahl der Absender, was ist das Auth-Modell? Was ist die Sicherheit 00:52:52.580 --> 00:52:55.750 Modell, das Sie verwenden möchten? So würde ich gemeinsamen Zugriff sagen. 00:52:55.800 --> 00:52:58.420 Signatur ist auf jeden Fall die empfehlen des Auth-Modells. 00:52:59.010 --> 00:53:02.150 Es gibt viel mehr Details. In der Tat Das Deck hat mehr Details auf 00:53:02.200 --> 00:53:08.190 das Einrichten von Signaturen für gemeinsamen Zugriff. Sie können auf das Portal gehen. 00:53:08.540 --> 00:53:10.040 und Verwalten von Warteschlangen. 00:53:10.910 --> 00:53:15.270 Hier habe ich die IOT, die Sie in die Warteschlange Typen verwenden von der Website. 00:53:16.050 --> 00:53:18.850 Und ich hier und konfigurieren können. 00:53:19.420 --> 00:53:23.650 Beachten Sie, dass ich Oh... 00:53:23.660 --> 00:53:23.720 [Unverständlich] 00:53:23.700 --> 00:53:25.290 >> Tut mir so leid. Ich bin mir so leid. 00:53:28.330 --> 00:53:33.790 So übernahm in Azure portal und ich meine IOT Warteschlange ausgewählt. 00:53:34.890 --> 00:53:38.340 Und, wenn ich Gehe zu konfigurieren Registerkarte sehen Sie Meine freigegebenen 00:53:38.390 --> 00:53:42.420 die Richtliniennamen zugreifen. Dies in Diese Website wird die ich 00:53:42.470 --> 00:53:45.240 zeigte, wenn ich empfangen habe, ist dies tatsächlich der Fall wäre 00:53:45.290 --> 00:53:49.650 fehl, da jetzt nur Autorisierung auf Dies ist senden. 00:53:50.890 --> 00:53:54.310 Aber ich kann einfach gehen und Listen hinzufügen Autorisierung von dieser Regel. 00:53:55.730 --> 00:53:56.440 Treffer speichern. 00:53:57.340 --> 00:53:58.640 Aktualisieren der Warteschlange angezeigt. 00:53:59.190 --> 00:54:00.050 Und jetzt alle 00:54:01.700 --> 00:54:06.780 Token für diese generiert wurde Regel haben die Möglichkeit 00:54:06.830 --> 00:54:11.480 zum Senden und empfangen. So, jetzt Ich kann hier ein, und klicken Sie auf erhalten, 00:54:12.880 --> 00:54:15.660 Na, dann gibt Sie. Sieht aus wie Leute haben Nachrichten gesendet wurden. 00:54:15.710 --> 00:54:18.320 Nun gelangen Sie auf die Chatsitzung gehen, Ihr seid können in Kontakt bleiben. 00:54:18.370 --> 00:54:20.210 mit jedem anderen online. 00:54:21.490 --> 00:54:24.220 So gemeinsam genutzten Access-Signatur, sind sehr sehr leichte sind sehr 00:54:24.270 --> 00:54:28.290 benutzerfreundliche Modell. Bei Bedarf direkt in eine Art SDS des Modells, 00:54:28.340 --> 00:54:35.540 ACS ist vollständig unterstützt werden. ACS ist immer noch die richtige Option vorhanden. 00:54:35.590 --> 00:54:37.660 Sie haben gerade gelernt, mit den Warteschlangen. 00:54:39.580 --> 00:54:43.390 So fassen Sie zusammen, sahen wir Protokolle. Warum sie relevant sind. 00:54:43.650 --> 00:54:47.970 Wir gingen durch Korrelation Stream, Deshalb es nicht erforderlich ist, 00:54:48.020 --> 00:54:50.860 Sie erstellen eine Warteschlange pro Gerät. Nicht verwaltet werden sollen 00:54:50.910 --> 00:54:53.980 eine Million Warteschlangen. Nur ich möchten code schreiben, über den 00:54:54.030 --> 00:54:57.760 hat auch super kompliziert sein. So Diese beiden sind sehr, sehr 00:54:57.810 --> 00:55:00.840 mit Dienst unterstützt problemlos. Bus-messaging. 00:55:01.900 --> 00:55:05.320 Warteschlangen, Themen, Abonnements. In allen diesen symmetrischen. 00:55:05.370 --> 00:55:08.990 Alles, was habe ich Ihnen in Begriffe Was mit Warteschlangen für funktioniert 00:55:09.040 --> 00:55:12.280 Sitzungen genaue die gleiche Weise funktioniert mit Themen und Abonnements 00:55:12.330 --> 00:55:16.290 und Filter. Wenn Sie ein Abonnement erstellen, Sag erfordert 00:55:16.340 --> 00:55:18.360 Sitzung auf es gleich true oder nicht. 00:55:21.680 --> 00:55:22.910 Skalieren Sie auf Empfänger. 00:55:27.210 --> 00:55:30.850 Visual Studio hat diese Herausforderung Wo können Sie unzählige starten. 00:55:30.900 --> 00:55:34.520 Instanzen der IDE und dann Sie gehen können, und ändern Sie Ihre 00:55:34.570 --> 00:55:37.840 Profil auf einem von ihnen und Sie Möchten Sie alle von ihnen zu synchronisieren. 00:55:38.640 --> 00:55:41.980 Wie wollen Sie gehen zu kommunizieren auf diese Instanzen? 00:55:42.490 --> 00:55:45.600 Und dies sind dynamische Instanzen auch weil die Anzahl der VS 00:55:45.650 --> 00:55:49.910 Instanzen, die Sie gestartet haben und variiert. Je nach Wochentag. 00:55:49.960 --> 00:55:53.530 Können wir Ihnen Statistiken die die Art und Weise anzeigen möchten. 00:55:53.580 --> 00:55:57.170 Menschen öffnen mehr Instanzen am Mittwoch als sie am Freitag zu öffnen. 00:55:57.220 --> 00:56:04.740 Damit die Produktivität von Freitag tank-ist. Wie auch immer, kann das Problem wieder 00:56:04.790 --> 00:56:07.440 mit Themen gelöst werden, in dem Sie haben Sie Millionen von 00:56:07.490 --> 00:56:11.110 Endpunkte. Und alle Sie hören auf ihre eigenen einen 00:56:11.160 --> 00:56:14.070 Abonnements für Nachrichten. 00:56:15.150 --> 00:56:19.140 Gibt an, ob die Nachrichten generiert werden durch die Back-End-Basis 00:56:19.190 --> 00:56:22.840 auf eine Änderung im System oder singen Sie senden möchten. 00:56:22.890 --> 00:56:26.270 soll eine Benachrichtigung an einen Benutzer auf einem Windows benachrichtigen 00:56:26.320 --> 00:56:30.510 7 im Feld müssen Sie keine Benachrichtigung Dienst. Benachrichtigt werden soll 00:56:30.560 --> 00:56:34.520 Sie sagen hey gibt es ein neues Update in Visual Studio verfügbar, 00:56:34.570 --> 00:56:39.970 Fahren Sie es herunterladen. Oder wichtiger Geben sie eine niedrige Latenz Sortierung 00:56:40.020 --> 00:56:43.890 von wo leiten, wenn sie Änderungen vornehmen auf eine VS-Instanz, die andere 00:56:43.940 --> 00:56:45.430 VS-Instanzen synchronisieren. 00:56:46.140 --> 00:56:48.340 Sie können Themen verklagt und Abonnements für diese. 00:56:49.760 --> 00:56:52.470 So stellen sie vom Konzept her als Benutzer pro VS Thema. 00:56:53.200 --> 00:56:58.800 Sie haben eine Abonnement pro VS-Instanz Mithilfe des MQP verbunden immer. 00:56:58.850 --> 00:57:03.260 So gibt MQP uns viele Verbindung Effizienz, bei denen 00:57:03.310 --> 00:57:07.830 uns Millionen von gleichzeitige Abschnitten mit sehr 00:57:07.880 --> 00:57:12.350 sehr geringer Mehraufwand, warten für gelegentliche Benachrichtigungen. 00:57:12.380 --> 00:57:14.840 Das ist der Unterschied zu Benachrichtigungen. Sie sind sehr gelegentlichen 00:57:14.890 --> 00:57:18.080 in der Natur. Wie oft Leute zu tun Ändern Sie ihre Profilfarbe? 00:57:19.770 --> 00:57:20.260 Ein Tag? 00:57:20.310 --> 00:57:22.960 Woche? Hoffentlich nicht jeden Tag. 00:57:23.790 --> 00:57:25.160 Hängt von Ihrer Stimmung, die ich denke. 00:57:26.260 --> 00:57:29.100 Aber nicht sehr häufig geschieht. Wie oft haben sie Updates 00:57:29.150 --> 00:57:33.660 zu? Nicht sehr oft. Aber Sie haben immer noch diese Art BNS 00:57:33.710 --> 00:57:38.290 Infrastruktur für Sie Sie Verbindungen müssen 00:57:38.340 --> 00:57:41.780 Da für diese Benachrichtigung warten Wenn diese Benachrichtigung 00:57:41.830 --> 00:57:45.170 wird verfügbar, er soll Sofortnachrichten. Sie möchten rechts 00:57:45.220 --> 00:57:46.040 und es dann. 00:57:51.000 --> 00:57:54.990 Hier müssen Sie doch ein bisschen über und müssen Sie denken 00:57:55.040 --> 00:57:59.320 über Meldungsflüsse. Da heute Themen können Sie bis zu 2000 00:57:59.370 --> 00:58:03.170 Abonnements und wann Sie denken der Maßstab für die Anzahl 00:58:03.220 --> 00:58:07.420 der Empfänger kann 2000 ausreichen oder 2000 ist nicht immer ausreichend. 00:58:07.980 --> 00:58:10.910 Wenn Sie über Visual Studio vorstellen, eine einzelne Person mehr 00:58:10.960 --> 00:58:13.700 als Instanzen von 2000 die IDE ausgeführt wird 00:58:16.030 --> 00:58:20.210 nahezu unmöglich. Ich weiß nicht, vielleicht Es ist möglich, aber es passiert nicht. 00:58:20.520 --> 00:58:24.520 Dies für sie ein Thema pro VS-Benutzer ist gut, aber Sie können Sie 00:58:24.570 --> 00:58:27.660 dass jeder überwacht werden um die dasselbe Futter. Sie möchten 00:58:27.710 --> 00:58:30.790 in der Lage, alle senden... eine einzelne Nachricht und senden Sie es 00:58:30.840 --> 00:58:34.790 Breite Umwandlung in jeder. Gut, dann Möchten Sie Themen miteinander zu verketten. 00:58:35.250 --> 00:58:38.680 Und auto, verwenden Sie weiterleiten. 00:58:39.850 --> 00:58:43.350 Ich werde nicht in der Gruppe springen Diese Muster-Details im 00:58:43.400 --> 00:58:45.280 Nutzungsbedingungen Filter einrichten. 00:58:45.800 --> 00:58:48.520 All dies sind Beispiele für MSDN.com. 00:58:49.130 --> 00:58:55.380 In diesem besonderen Beispiel wird aufgerufen. Liste. Es ist ein Beispiel aufgerufen 00:58:55.430 --> 00:58:58.720 Veröffentlichen Sie abonnieren. Den vollständigen code Diese ist verfügbar. 00:58:58.770 --> 00:59:02.570 Wirklich fördern Sie Typen zu gehen ein aussehen, aber mit diesen Themen 00:59:02.620 --> 00:59:06.190 Sie können sich diese Rich wirklich ausgleichen Flows stellen, wo jede Nachricht 00:59:06.240 --> 00:59:09.930 muss nicht für alle weitergeleitet die 2 Millionen Leute und dann 00:59:09.980 --> 00:59:14.280 Abrufen wird jedes Mal gelöscht. Sie erhalten an eine Person, die für viele weitergeleitet 00:59:14.330 --> 00:59:18.680 Personen, oder in einer endlosen Art der Anfrage Wenn Sie nur Adresse schreiben. 00:59:18.730 --> 00:59:19.660 Wie e-Mail-Nachrichten. 00:59:20.190 --> 00:59:23.130 In diesem Fall ist es z. B. sagen, auf die Nachricht, die ich zuerst sagen kann, 00:59:23.180 --> 00:59:24.230 Komma, Sekunde. 00:59:25.130 --> 00:59:27.850 Und ich wende mich an beiden Geräten, das erste Gerät und die zweite 00:59:27.900 --> 00:59:30.770 Gerät oder zwei Abonnements, die erste und die zweite. 00:59:30.820 --> 00:59:35.390 Da sie Regeln eingerichtet haben, wie erste und wie zweite vorhanden. 00:59:36.390 --> 00:59:40.470 Also wirklich, sehen Sie sich diese Pub Sub (unverständlich) 00:59:42.610 --> 00:59:47.050 Automatische Weiterleitung. Sehr leicht um zu verwenden. Im Wesentlichen erstellen Sie 00:59:47.100 --> 00:59:52.150 die Warteschlange zuerst Ihr Ziels und Klicken Sie auf der Quellwarteschlange Sie 00:59:52.200 --> 00:59:55.970 Fügen Sie eine Eigenschaft hinzu. Die einzige Eigenschaft wird die Quelle bezeichnet.Auf, 00:59:57.220 --> 01:00:00.600 an die Zielwarteschlange und es. Alle eingehenden Nachrichten 01:00:00.650 --> 01:00:03.280 in der Quellwarteschlange eingehen die Zielwarteschlange. 01:00:03.330 --> 01:00:10.030 Datenquellen können Abonnements werden und Warteschlangen. Audits können Themen sein. 01:00:10.080 --> 01:00:10.960 und Warteschlangen. 01:00:13.190 --> 01:00:16.800 Vollständig symmetrisch, so viele einrichten würde der Schriftart entschuldigen Sie 01:00:16.850 --> 01:00:18.810 wie und anzuzeigen. 01:00:19.400 --> 01:00:22.540 Haben Sie vorübergehende Fälle, in denen Sie über ein Abonnement verfügen, 01:00:22.590 --> 01:00:23.390 werden entfernt 01:00:24.660 --> 01:00:28.430 Automatische löschen können in den Leerlauf übergehen. So Dies ist auch sehr praktische Funktion. 01:00:28.480 --> 01:00:32.570 Wir verwalten Sie große Anzahl vorübergehende Verbindungen. In der Tat 01:00:32.620 --> 01:00:35.640 eine der wichtigsten Szenarios ist dies SignalR ist verwendet wird und 01:00:35.690 --> 01:00:38.590 Socket-e/a. Sie sind sehr sehr vorübergehend in Natur. 01:00:38.640 --> 01:00:40.200 Verbindungen kommen, Verbindungen gehen. 01:00:41.380 --> 01:00:43.700 Lasten werden hinzugefügt, und die Knoten entfernt. 01:00:44.600 --> 01:00:48.680 So verwenden sie Service Bus als Sicherungskopie Spielen sie, wo im Wesentlichen sind 01:00:48.730 --> 01:00:52.540 Schreiben ein Abonnement pro Knoten Wenn kommt ein neues Abonnement 01:00:52.590 --> 01:00:56.160 kommt keine neue Verbindung herstellen ein neuer Knoten kommt, wenn sie 01:00:56.210 --> 01:00:57.260 Fügen Sie Server hinzu. 01:00:58.320 --> 01:01:03.210 Mit Themen und Abonnements als Pipe an zurück 01:01:03.260 --> 01:01:05.970 Meldungen zur Übertragung zwischen Knoten und weiter gefasstes erhalten. 01:01:07.010 --> 01:01:10.090 Und dann wenn ein Knoten ausfällt das Abonnement abläuft, die 01:01:10.140 --> 01:01:17.490 Es sind Nachrichten drin. Beide Diese Codes sind open-Code. 01:01:17.540 --> 01:01:20.240 Beide sind verfügbar, wenn Sie möchten Dezentrales Skalieren, Signal, oder Socket 01:01:20.290 --> 01:01:24.720 E/a, da Sie ein dauerhaftes messaging benötigen Pipe am Ende, Service 01:01:24.770 --> 01:01:27.980 Bus verfügt über Implementierungen für die beiden Schlüsselwörter. 01:01:29.920 --> 01:01:33.050 Ich möchte kommunizieren ein wenig integriert. über die Verfügbarkeit lassen Sie mich 01:01:33.100 --> 01:01:36.780 kurz erklärt werden, die. Ich weiß Wir sind fast mit der Zeit 01:01:38.830 --> 01:01:42.440 Code muss flexibel auf Vorgang Fehler sowie verbunden 01:01:42.490 --> 01:01:43.470 mit den Problemen. 01:01:43.990 --> 01:01:46.750 Warteschlangen für unzustellbare Nachrichten, wie ich gesagt habe Sie wirklich helfen Ihnen. Sie helfen 01:01:46.800 --> 01:01:50.790 Bei Anwendung der Where Ebene Decivilization einer Nachricht oder 01:01:50.840 --> 01:01:51.830 etwas schlägt möglicherweise fehl. 01:01:52.980 --> 01:01:57.440 Jede Nachricht, die Service-Bus auslöst. hat eine in transiente-Eigenschaft 01:01:57.490 --> 01:01:58.020 auf 01:01:59.480 --> 01:02:02.780 Problemloses klar und einfach zu wissen, ob Sie 01:02:02.830 --> 01:02:04.350 haben oder nicht wiederholt. 01:02:05.090 --> 01:02:08.560 Standardmäßig sind wir eigentlich automatisch wiederholt. So habe ich 01:02:08.610 --> 01:02:12.090 über die Timeouts im Grunde Vorgang Timeouts. In der Standardeinstellung 01:02:12.140 --> 01:02:15.190 Vorgang Timeouts sind auf festgelegt 60 Sekunden, d. h. Wenn Sie 01:02:15.240 --> 01:02:19.720 Stellen einen Aufruf von Send, einmal fehlschlagen, Wir versuchen es erneut nach 01:02:19.770 --> 01:02:22.980 drei Sekunden. Die Datei möglicherweise zweimal. Wir werden Versuchen Sie es erneut nach zehn Sekunden. 01:02:23.030 --> 01:02:27.840 In diesem 60 Sekunden Sie uns geben, werden wir Versuchen Sie, diesen Aufruf erfolgreich ausgeführt werden. 01:02:27.890 --> 01:02:29.740 Wenn nicht, wir senden Diese an Sie zurück. 01:02:31.320 --> 01:02:33.650 Haben Sie eine andere Stelle Es ist in Ordnung, die beibehalten werden. 01:02:33.700 --> 01:02:36.920 Überprüfen Sie andernfalls, ob als flüchtig und erneut senden, dann. 01:02:38.160 --> 01:02:42.430 Und die Partition Warteschlangen und Themen deutlich verbesserte Verfügbarkeit. 01:02:43.080 --> 01:02:48.230 Zur Verbesserung der Größenordnung. So empfehlen Sie dringend, Verwendung 01:02:48.280 --> 01:02:49.710 Dieses Feature. 01:02:51.830 --> 01:02:55.280 Wiederholen Sie Richtlinie standardmäßig. Deaktivieren Sie nicht es, bitte. 01:02:57.200 --> 01:02:59.970 Gepaarten Namespaces. Die letzte Was ich heute sprechen werden. 01:03:00.490 --> 01:03:03.540 Wenn Sie eine Service-Bus mit dem Namen Platz haben, Nachrichten sind gut übertragen. 01:03:03.590 --> 01:03:08.210 durch, und klicken Sie dann die gesamten Daten Center Caput geht oder zumindest 01:03:08.260 --> 01:03:13.570 der gesamte Namespace gilt eine Caput. Ungültiger Namespace erstellt. 01:03:13.620 --> 01:03:15.790 das Sichern von Namespace. Sie erstellen das Sichern von Namespace. 01:03:15.840 --> 01:03:19.190 Sie einfach zur Verfügung stellen, und wir werden Starten Sie Speichern von Nachrichten in 01:03:19.240 --> 01:03:23.440 das Sichern von Namespace. So eine Meldung bei weit 01:03:24.140 --> 01:03:25.350 an der Rückseite steigen wird. 01:03:26.210 --> 01:03:29.450 Zu einem bestimmten Zeitpunkt startet Nachrichten durch fließt. Das system 01:03:29.500 --> 01:03:30.340 kommt zurück. 01:03:31.350 --> 01:03:35.150 Und wir haben nun ein siphon Nachrichten von diesen dauert 01:03:35.200 --> 01:03:39.110 Transfer-Warteschlangen und reenqueue Diese ursprünglichen Warteschlange. 01:03:40.650 --> 01:03:43.590 Für alle diese Codes Absender ändert nicht den receiver 01:03:43.640 --> 01:03:46.370 Code ändern nicht. Der Absender und Empfänger verwendet werden, als wären sie 01:03:46.420 --> 01:03:48.470 Dienst sprechen immer. Bus-Namensbereich. 01:03:49.240 --> 01:03:54.700 Hinter den Kulissen schaffen wir die Transfer-Warteschlangen verschieben 01:03:54.750 --> 01:03:57.870 Ziehen die Nachrichten und dort Sie sichern sich für Sie. 01:03:58.720 --> 01:04:03.160 Und dies ist der einzige Code, der zum Ändern. 01:04:03.740 --> 01:04:06.070 Dies ist nicht die einzige Aufgabe, die Sie haben zu tun. Wir sprechen über die 01:04:06.120 --> 01:04:08.520 Überlegungen, aber dies ist die nur ein Teil des Codes auf 01:04:08.570 --> 01:04:13.330 Ändern Sie die, die bei der Erstellung eine Factory, die Ihre 01:04:13.380 --> 01:04:17.690 Ausführen des Zeitpunkt senden und Empfangen von code Klasse, verbinden Sie es mit einem Namen 01:04:17.740 --> 01:04:21.230 Raum, sagen Sie hey, es gibt eine zweite Factory, einen zweiten Namespace 01:04:21.280 --> 01:04:24.130 mit dem Manager Um werden Sie mit kombiniert. 01:04:24.660 --> 01:04:28.600 Und alles andere erfolgt durch die Client-seitige. Keine Änderung des Absenders. 01:04:28.650 --> 01:04:31.470 Keine Empfänger ändern. Code bleibt unverändert. 01:04:36.210 --> 01:04:41.520 Verfügbare Sender wird nun unterstützt. Wie in der Abbildung gezeigt, 01:04:41.570 --> 01:04:44.590 der Empfänger wird die Nachricht nicht erhalten. bis zu den ursprünglichen Namen 01:04:44.640 --> 01:04:45.760 Speicherplatz kommt zurück. 01:04:46.330 --> 01:04:49.340 Das ist also mehr von der Verfügbarkeit einer senden. Deshalb ist jetzt 01:04:49.390 --> 01:04:54.000 Wir nennen es Verfügbarkeitsoptionen senden. Bestellung da möglicherweise verloren 01:04:54.050 --> 01:04:57.910 Nachrichten, die bei der Übertragung Warteschlangen werden nicht angezeigt. 01:04:58.630 --> 01:05:02.360 Und Latenz Ende beendet wird Natürlich können hoch sein. 01:05:02.410 --> 01:05:06.420 Es gibt einige Überlegungen aber dies als denke. 01:05:06.470 --> 01:05:10.730 ein wichtiges Szenario von machen Disaster Recovery-Art 01:05:12.070 --> 01:05:14.770 Je Szenarien. 01:05:15.810 --> 01:05:18.710 Also, wir schließen nur sah Azure Service Bus kann wirklich skaliert. 01:05:18.760 --> 01:05:21.870 in allen Dimensionen. Viele Absender. Viele Durchsatz. 01:05:21.920 --> 01:05:23.080 Viele Empfänger. 01:05:23.730 --> 01:05:27.420 Und Sie können die Zuverlässigkeit erhöhen sowohl mithilfe der neuen Features aus 01:05:27.470 --> 01:05:31.950 neben dem Feld wie Partition Warteschlangen und Namespaces verbunden oder 01:05:32.000 --> 01:05:37.320 wie verwenden Sie Muster wie code Async und Stapel und Sachen. 01:05:38.100 --> 01:05:41.750 Tonnen von Links. Unmengen an Ressourcen. Sie haben Zugriff auf all das. 01:05:41.800 --> 01:05:44.130 Vielen Dank. Ich entschuldige mich für was auch immer.