Die Vergangenheit erben und die Zukunft des Werbegeschäftssystems einläuten – „Message Center“

Die Vergangenheit erben und die Zukunft des Werbegeschäftssystems einläuten – „Message Center“

Nachrichtenzentrum

Das Nachrichtenzentrum ist eine Verbindung zur Synchronisierung von Kundeninformationen und Materialien für die Liefermaschine sowie zur Echtzeit-Dateninteraktion mit der BP-Plattform, der Abwicklungsseite und der Liefermaschine, was ein wichtiges Bindeglied in der Verbindung zwischen Vergangenheit und Zukunft darstellt.
Bitte beachten Sie den offiziellen Bericht am Ende des Artikels

Verbindungsdiagramm zur Materialsynchronisierung

Materialien werden von DSP initiiert und an Message_center gesendet, um Kandidatenunterstützung für die Liefermaschine bereitzustellen.

Werbetreibende [im Folgenden als DSP bezeichnet] laden über die BP-Plattform ihre eigenen Qualifikationsinformationen, Identifikationsinformationen und andere Informationen wie die freigegebenen freigestellten Materialien hoch, und die BP-Plattform führt die Landung und Überprüfung selbst und die vorhandenen durch Informationen haben die Überprüfung nicht bestanden. , Offline, Online, Gesperrt usw.

• Darunter werden die Dsp-Informationen mit den Client-Informationen gekoppelt, da die UUID, die das aktuelle Material darstellt, mit dem Datenverkehr in das Expositionsprotokoll eingeht und schließlich zur Abwicklungsseite fließt, und die Abwicklungsseite wird dies als Grundlage für verwenden Messung und Schätzung der Bestell-/Vertragsmenge sind die Hauptkriterien für die Beurteilung.
• Es gibt zwei Arten von Creatives: zur Überprüfung eingereichte und nicht überprüfte Creatives.
  • Es gibt zwei Arten von rezensionsfreien Materialien: Rendering und Non-Rendering. Das Basismaterial ist das Untermaterial. Wenn DSP kein relevantes Material zurückgibt, wird es als Untermaterial verwendet. Das Nicht-Basismaterial wird gemäß dem spezifischen Lieferplan freigelegt und angezeigt.

Zur Überprüfung eingereichte Materialien werden zusammen mit den natürlichen Geschäftsergebnissen überprüft, daher ist dieser Link hier nicht enthalten.

• Informationen zur Szenariozustellung dienen dazu, bestimmte Zustellungsszenarien nach Typ in mehrere Szenarien zu unterteilen. Zum Beispiel gleicher Stadtfluss, gleicher Feedfluss, gleiche Zielseite usw. DSP muss die Szene abgrenzen, in der sich die Benutzergruppe befindet, die seinem eigenen Unternehmen entspricht, und gezielte Werbung platzieren.

Bitte beachten Sie den offiziellen Bericht am Ende des Artikels

„Eins teilt sich in zwei“ mit modularem Aufbau

Wenn interessierte Studierende dies sehen, könnten sie auf ein Problem stoßen.

„Alle Daten im Message Center stammen von der BP-Plattform. Warum den Datenfluss in zwei Teile aufteilen?“

Lassen Sie mich hier den Grund erläutern und sehen, welche Vorteile „eins in zwei geteilt“ hat und ob es mit Ihrer Meinung übereinstimmt.

• Datennutzer sind unterschiedlich
  • Die BP-Plattform wird von DSP verwendet. Um Dienste extern bereitzustellen, sind exklusive Logikfunktionen wie externe Domänennamen, Signaturprüfung usw. erforderlich.
  • Nachrichtencenter, das von der Liefermaschine verwendet wird. Stellen Sie Datenunterstützung nur für interne Dienste bereit.
• Die Angaben zur Datennutzung variieren
  • Auf der BP-Plattform enthalten die Daten mehrere Dimensionen und Typen. Einschließlich des Status „nicht genehmigt“, geprüft, ausgesetzt, neu, geändert usw. sowie Daten wie DSP-Identitätsüberprüfung, historische Betriebsaufzeichnungen usw.
  • Im Nachrichtenzentrum müssen die Daten nur Materialien, Dsp, Client und andere Daten sein, die alle genehmigt und aktuell verfügbar sind und mit einem einzigen Status und einem extrem kleinen Maßstab übermittelt werden.
• Die Anforderungen an die Datennutzungsleistung sind unterschiedlich
  • BP-Plattform, toB-Typ, keine strengen Leistungsanforderungen.
  • Das Nachrichtenzentrum, das den Echtzeitverkehr abwickelt, stellt extrem hohe Anforderungen an die Datenleseleistung.
• Funktionale Spezifität des Moduls
  • …

Kehren Sie anhand der obigen Analyse und Ihres Verständnisses der Erweiterung von Microservices zur obigen Frage zurück. Ich glaube, Sie haben die entsprechende Antwort!

Bitte beachten Sie den offiziellen Bericht am Ende des Artikels

„Starkes Konsistenzdesign“ des Modulinteraktionsdiagramms

Der Upstream von Message_center ist die BP-Plattform, und das Folgende ist das Interaktionsflussdiagramm der beiden Module.

Ein solches Interaktionsdiagramm mag auf den ersten Blick seltsam erscheinen.

„Es handelt sich nicht nur um eine einfache Synchronisierung von Upstream- und Downstream-Daten, es reicht aus, die Http/Https-Schnittstelle direkt aufzurufen. Viele Upstream- und Downstream-Unternehmen tun dies …“

Wenn Sie den gesamten Hintergrund sorgfältig durchdenken, werden Sie das Gefühl haben, dass die obige Rede fast bedeutungslos ist!

Stellen Sie zunächst den Datenlink im obigen interaktiven Diagramm vor.

Datenlinks für seltsame Interaktionsdiagramme

Die Datenquelle ist BP, und die Daten gehen zur Produktion und Landung direkt an die Middleware [kafka]; das nachgelagerte Message_center-Modul erhält Daten über die Form des Mittelpreisverbrauchs.

> 注意：这里传递的数据为 命令形式【雷同于设计模式中的——命令模式】。

{
    
    
    "type":"dsp",
    "action":"update_all",
    "env":"test",
    "source":"bp",
    "version":2,
    "time":"2021-08-18 11:33:06"
}

Nachdem das Message_center die Befehlsdaten erhalten hat, greift es über die API-Schnittstelle auf die BP-Datenbank zu, ruft die Daten ab, die den Befehlsregeln entsprechen, und implementiert sie.

Hinweis: Die BP-Seite ist als DB implementiert und das Message_center ist eine Redis/MC-Komponente mit besserer Leseleistung und größerer Ladekapazität.

Probleme mit der Datenkonsistenz

Angenommen, wir verwenden die Http/Https-Schnittstellenform für die Upstream- und Downstream-Interaktion. Ein Problem können wir nicht vermeiden: das Netzwerkproblem.

Das Netzwerk ist für die Kommunikation völlig unzuverlässig, da das TCP-Protokoll sonst nicht den Großteil seiner Energie für die Verarbeitung der Datenpaketreihenfolge und Neuübertragungsstrategien mit Datenintegrität aufwenden würde.

• Paketverluste und Paketfehler sind unsere Hauptsorgen.
  Im seltsamen Interaktionsdiagramm verwenden wir eine API, um DB-Daten abzurufen, um solche Probleme effektiv zu vermeiden.
• Nach dem Senden des Datenbefehls besteht ein Zeitlückenproblem bei der DB-Datenaktualisierung.
  Nachdem der Befehl empfangen und die DB-Daten synchronisiert wurden, schließt die DB auf der BP-Seite die Datenänderung zu diesem Zeitpunkt ab, was bedeutet, dass es sich bei den vorherigen Synchronisationsdaten um alte Daten handelt. Im Gegensatz dazu verfügt Message_center über eine Cron-Aufgabe, um regelmäßig DB-Daten zur Synchronisierung zu extrahieren.

Das obige Problem ist gelöst, aber sorgfältige Schüler stellen möglicherweise fest, dass sich auf der rechten Seite der Abbildung mehr Links befinden und Kafka auf der linken Seite nicht beteiligt ist.

Dann: „Kann die Art des Befehlszugriffs durch Http/Https ersetzt werden?“

• Warum Middleware zur Unterstützung der Befehlsauslösung verwenden?
  Ja, es ist möglich, den API-Funktionsersatz zu verwenden. Der einzige Nachteil besteht darin, dass Kafka über eine höhere Datenintegrität und eine zuverlässigere Nachrichtenlandung verfügt. Aber wo soll ich anfangen?
  • Studenten, die sich mit Middleware auskennen, kennen diesen Punkt vielleicht.
    Das heißt, wenn Daten verbraucht werden, kann der Offset manuell übermittelt werden. Diese Einstellung kann sicherstellen, dass nach dem Empfang der Daten durch Message_center bei abnormaler Geschäftsverarbeitung die gleichen Daten hier wiederverwendet werden können, um das Problem nicht synchronisierter Daten zu vermeiden. Wenn es sich um eine API handelt, beträgt die empfangene Antwort immer noch 200 und ein solches Problem kann nicht gefunden werden.

Das seltsame Design ist nie überflüssig, sondern gewährleistet lediglich den sicheren, effizienten und stabilen Betrieb des Systems!

Bitte beachten Sie den offiziellen Bericht am Ende des Artikels

Log-Center

Das Logcenter ist eine Übergabestation für Daten im Werbelink . Echtzeitüberwachung der Robustheit des Full-Link-Dienstes und Unterstützung für Abwicklung, Exposition, Interaktion und andere Überwachungs- und Berichtsfunktionen. Spielt eine zentrale Rolle im Hinterlenker …

---

Siehe Folgeartikel!

Empfohlene Lektüre:
Werbung, Empfehlung, Suche nach drei Top-Komplexgeschäften „Details zum Werbegeschäftssystem“
Vererbung der Vergangenheit und Zukunft des Werbegeschäftssystems – „Message Center“
Datenübertragungsstation des Werbegeschäftssystems – „Protokollcenter – Echtzeit-Serviceüberwachung“
Die Datenbrücke des Werbegeschäftssystems – der Kernkanal des
Werbegeschäftssystems „Log Center-Expositionsdatenübertragung und -abrechnung“ – die Hilfsentscheidungsfindung des Werbegeschäftssystems „Log Center-S2S-Überwachung und Berichterstattung“
– die „ AB Experimental Platform“
-Werbegeschäftssystem Framework Precipitation – Intelligente Sicherung des
Werbegeschäftssystems „Data Consumption Service Framework“ – Agile Bereitstellung des Werbegeschäftssystems „Smart Flow Control“
– Geschäftsverbindung des Werbegeschäftssystems „Deployment Based on Docker Containers“
. —„PDB – Anzeigenlieferung [Menge und Preis]“

---

Erledigen Sie es mit drei Codezeilen - Umkehren der verknüpften Liste ...
Kafkas hoher Durchsatz, leistungsstarke Kerntechnologie und beste Anwendungsszenarien ...
Wie HTTPS die Sicherheit der Datenübertragung gewährleistet - TLS-Protokoll ...
Erstellen Sie eine Echtzeit Überwachungssystem auf Basis von Prometheus + Grafana in fünf Minuten ...