Commit 399cc488 authored by Nane Kratzke's avatar Nane Kratzke
Browse files

Final polishing

parent 374e208e
......@@ -92,6 +92,6 @@ all:
- mo deploy/pubsub-producer-dep.yaml | kubectl delete -f - || true
- mo deploy/pubsub-consumer-dep.yaml | kubectl delete -f - || true
- mo deploy/queueing-producer-dep.yaml | kubectl delete -f - || true
- mo deploy/queueing-producer-dep.yaml | kubectl delete -f - || true
- mo deploy/queueing-consumer-dep.yaml | kubectl delete -f - || true
- kubectl delete -f deploy/redis-dep.yaml
- kubectl delete -f deploy/redis-svc.yaml
......@@ -78,16 +78,18 @@ verteilt dann alle Messages an Consumer *C*, die sich für diesen Channel angeme
```
- Sehen Sie sich in Lens nun die Logs des Producers an:
```
...
[...]
Publishing message 'Hi, this is message #4317 from pubsub-producer-79bcdbf9d8-bdxrn.' to channel 'xpubsub'
Publishing message 'Hi, this is message #4318 from pubsub-producer-79bcdbf9d8-bdxrn.' to channel 'xpubsub'
Publishing message 'Hi, this is message #4319 from pubsub-producer-79bcdbf9d8-bdxrn.' to channel 'xpubsub'
Publishing message 'Hi, this is message #4320 from pubsub-producer-79bcdbf9d8-bdxrn.' to channel 'xpubsub'
Publishing message 'Hi, this is message #4321 from pubsub-producer-79bcdbf9d8-bdxrn.' to channel 'xpubsub'
[...]
```
- Die Logs des Consumers sollten in etwa so aussehen:
```
...
[...]
0.92ms | msg: {"timestamp": 1614764396330193114, "message": "Hi, this is message #4689 from pubsub-producer-79bcdbf9d8-bdxrn."}
0.64ms | msg: {"timestamp": 1614764396731672144, "message": "Hi, this is message #4690 from pubsub-producer-79bcdbf9d8-bdxrn."}
0.79ms | msg: {"timestamp": 1614764397232874681, "message": "Hi, this is message #4691 from pubsub-producer-79bcdbf9d8-bdxrn."}
......@@ -95,6 +97,7 @@ verteilt dann alle Messages an Consumer *C*, die sich für diesen Channel angeme
0.81ms | msg: {"timestamp": 1614764398035370260, "message": "Hi, this is message #4693 from pubsub-producer-79bcdbf9d8-bdxrn."}
0.52ms | msg: {"timestamp": 1614764398236610874, "message": "Hi, this is message #4694 from pubsub-producer-79bcdbf9d8-bdxrn."}
0.70ms | msg: {"timestamp": 1614764398737878344, "message": "Hi, this is message #4695 from pubsub-producer-79bcdbf9d8-bdxrn."}
[...]
```
Die Zeitangaben in ms geben an, wie lange eine Message vom Producer zum Consumer benötigt hat (Latenz). Vergleichen Sie diese Werte mit den Werten, die Sie im letzten Lab zu REST und gRPC basierten Interaktionsverfahren erhoben haben.
- Merken Sie sich in etwa die letzte Messagenummer, die der Consumer bis dahin erhalten hat. Löschen Sie dann in Lens den Consumer und warten Sie ab, bis der Pod wieder durch Kubernetes automatisch neu gestartet wurde. Prüfen Sie im neuen Container Log des regenerierten Pods ab welcher Message Nummer dieser das Streaming wieder auf nimmt?
......@@ -103,11 +106,13 @@ verteilt dann alle Messages an Consumer *C*, die sich für diesen Channel angeme
- Der Producer sollte wieder ab 1 nummerierte Messages erzeugen, die der Consumer im Log anzeigt.
- Skalieren Sie nun in Lens den Producer auf 3 Instanzen hoch (`Producer Deployment -> Scale`). Achten Sie nun im Consumer Log auf die Ursprünge der Messages. Sie erhalten nun Messages von mehreren Producern.
```
[...]
0.89ms | msg: {"timestamp": 1614765108327074527, "message": "Hi, this is message #95 from pubsub-producer-79bcdbf9d8-ch4w9."}
1.10ms | msg: {"timestamp": 1614765108467772402, "message": "Hi, this is message #610 from pubsub-producer-79bcdbf9d8-lc2rq."}
0.78ms | msg: {"timestamp": 1614765108746772325, "message": "Hi, this is message #100 from pubsub-producer-79bcdbf9d8-nzr2v."}
0.86ms | msg: {"timestamp": 1614765108828138961, "message": "Hi, this is message #96 from pubsub-producer-79bcdbf9d8-ch4w9."}
0.81ms | msg: {"timestamp": 1614765108869005443, "message": "Hi, this is message #611 from pubsub-producer-79bcdbf9d8-lc2rq."}
[...]
```
- Skalieren Sie auch die Consumer auf drei Instanzen hoch. Vergleichen Sie die Logs der drei Pods in Lens. Laufen unterschiedliche Messages auf?
- Löschen Sie nun das Producer Deployment und das Consumer Deployment (entweder in Lens oder mit dem Gitlab Pipeline `pubsub`-Job in der `terminate`-Stage).
......@@ -148,12 +153,15 @@ Committen Sie diese Änderung in das Repo und deployen Sie dann den Consumer mit
Sie können auch ab einem beliebigen Zeitpunkt aufsetzen. Schauen Sie doch einfach in Ihr Log des Consumers, um sich einen beliebigen Aufsetzpunkt zu wählen.
```
[...]
15331.28ms | msg b'1614769654088-0': {'text': 'Hi, this is message #625 from queueing-producer-64b575bb98-wssf2.'}
10327.25ms | msg b'1614769659092-0': {'text': 'Hi, this is message #626 from queueing-producer-64b575bb98-wssf2.'}
6322.52ms | msg b'1614769663096-0': {'text': 'Hi, this is message #627 from queueing-producer-64b575bb98-wssf2.'}
5320.72ms | msg b'1614769664098-0': {'text': 'Hi, this is message #628 from queueing-producer-64b575bb98-wssf2.'}
1319.34ms | msg b'1614769668100-0': {'text': 'Hi, this is message #629 from queueing-producer-64b575bb98-wssf2.'}
[...]
```
Um z.B. ab der Message `#628` weiter zu lesen, könnten dann folgendes eingeben:
......@@ -166,6 +174,7 @@ for since, msg in queue.listen(since=1614769663096):
Committen Sie, pushen Sie in die Gitlab Pipeline und redeployen anschließend den Consumer erneut. Sie werden feststellen, die Logs setzen ab Message `#628` fort.
```
[...]
queueing-consumer-66cc6f8cfb-v55w8 has found already existing consumer group for xqueue
594444.00ms | msg b'1614769664098-0': {'text': 'Hi, this is message #628 from queueing-producer-64b575bb98-wssf2.'}
590442.67ms | msg b'1614769668100-0': {'text': 'Hi, this is message #629 from queueing-producer-64b575bb98-wssf2.'}
......@@ -173,7 +182,7 @@ queueing-consumer-66cc6f8cfb-v55w8 has found already existing consumer group for
583434.14ms | msg b'1614769675108-0': {'text': 'Hi, this is message #631 from queueing-producer-64b575bb98-wssf2.'}
581431.20ms | msg b'1614769677111-0': {'text': 'Hi, this is message #632 from queueing-producer-64b575bb98-wssf2.'}
579428.24ms | msg b'1614769679114-0': {'text': 'Hi, this is message #633 from queueing-producer-64b575bb98-wssf2.'}
...
[...]
```
__Transferaufgabe:__
......@@ -218,7 +227,7 @@ Committen Sie diese Änderung in das Repo und deployen Sie dann den Consumer mit
[...]
```
Ändern Sie nun in Lens unter `Deployment ->` Consumer Deployment `-> Scale` die Anzahl an Replikas auf 2. Nachdem diese Änderung durchgeführt wurde, sollten Sie das Log wie folgt ändern.
Ändern Sie nun in Lens unter `Deployment -> Consumer Deployment (wählen) -> Scale` die Anzahl an Replikas auf 2. Nachdem diese Änderung durchgeführt wurde, sollte sich der Stream im Log wie folgt ändern.
```
[...]
......@@ -229,7 +238,9 @@ Committen Sie diese Änderung in das Repo und deployen Sie dann den Consumer mit
[...]
```
D.h. die Message Nummern steigen nun in zweier Schritten (da zwei Replikas des Consumers vorhanden sind). Wenn Sie die Replikas auf fünf setzen, werden die Messages in einem Consumer Pod, dann in fünfer Schritten steigen. Usw. Sie können dies gerne in den einzelnen Logs der Consumer Pods nachvollziehen.
D.h. die Message Nummern steigen nun in zweier Schritten (da zwei Replikas des Consumers vorhanden sind). Wenn Sie die Replikas auf fünf setzen, werden die Messages in einem Consumer Pod, dann in fünfer Schritten steigen, usw.. Sie können dies gerne in den einzelnen Logs der Consumer Pods nachvollziehen.
Durch Gruppen-basiertes Lesen kann man mit Messaging Systemen also Events über eine Gruppe von Consumern verteilen. Dies ist eine Form der horizontalen Skalierung. Durch Skalierung der Producer kann man mehr oder weniger Last in das System geben. Durch Skalierung der Consumer kann mehr oder weniger Last in einem Zeitraum verarbeitet werden.
## Verständnis- und Transferfragen
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment