Ibco ist eine C/C++-Coroutine-Bibliothek, die in gro?em Umfang im WeChat-Backend verwendet wird. Sie l?uft seit 2013 stabil auf Zehntausenden von Maschinen im WeChat-Backend. Libco wurde 2013 zum ersten Mal als eines der sechs gro?en Open-Source-Projekte von Tencent ver?ffentlicht. Wir haben kürzlich ein gro?es Update durchgeführt, das auf github.com/tencent/libco synchronisiert ist. libco unterstützt das Backend-Programmiermodell im agilen Synchronisierungsstil und bietet gleichzeitig hohe Parallelit?tsf?higkeiten des Systems.

Von libco unterstützte Funktionen

Es besteht keine Notwendigkeit, in die Gesch?ftslogik einzudringen, Multiprozess- und Multithread-Dienste in Coroutine-Dienste umzuwandeln, und die Parallelit?tsf?higkeit wird um das Hundertfache verbessert ??> Unterstützt CGI
Framework
, einfach zu erstellende Webdienste (Neu); Unterstützt h?ufig verwendete dritte Bibliotheken wie gethostbyname, mysqlclient, ssl (Neu); Shared-Stack-Modus, einfacher Standalone-Zugriff auf zig Millionen Verbindungen (Neu);

Perfekte und pr?gnante Coroutine-Programmierung
Schnittstelle


- pthread-?hnliches Schnittstellendesign, durch einfache und klare Schnittstellen wie co_create und co_resume Vervollst?ndigen Sie die Erstellung und Wiederherstellung der Coroutine – Thread-?hnliche Coroutine private Variable , Coroutine-Semaphor co_signal (Neu) für die Kommunikation zwischen Coroutinen – Lambda auf Nicht-Sprachebene Implementierung, kombiniert mit Coroutine-In-Place-Schreiben und Ausführen von asynchronen Hintergrundaufgaben (Neu); – Ein kleines und leichtes Netzwerk-Framework basierend auf epoll/kqueue, einem Hochleistungs-Timer basierend auf Zeit-Roulette
; >
Generiert von libco Hintergrund In den frühen Tagen des WeChat-Backends verwendeten die meisten Module aufgrund komplexer und sich ?ndernder Gesch?ftsanforderungen und schneller Produktiteration ein halbsynchrones und halbasynchrones Modell . Die Zugriffsschicht ist ein asynchrones Modell und die Gesch?ftslogikschicht ist ein synchrones Multiprozess- oder Multithread-Modell. Die Parallelit?tsf?higkeit der Gesch?ftslogik betr?gt nur zehn bis Hunderte. Mit dem Wachstum des Gesch?fts von WeChat wird der Systemumfang immer gr??er und jedes Modul wird leicht durch Back-End-Service-/Netzwerk-Jitter beeintr?chtigt.

Die Wahl der asynchronen Transformation

Um die Parallelit?tsf?higkeit des WeChat-Backends zu verbessern, besteht der allgemeine Ansatz darin, alle Dienste im bestehenden Netzwerk auf ein asynchrones Modell umzustellen. Dieser Ansatz erfordert einen enormen Arbeitsaufwand, vom Framework bis zum Gesch?ftslogikcode, der eine vollst?ndige Transformation erfordert, was zeitaufw?ndig, arbeitsintensiv und riskant ist. Also begannen wir über die Verwendung von Coroutinen nachzudenken. Bei der Verwendung von Coroutinen treten jedoch folgende Herausforderungen auf:

Die Branche hat keine Erfahrung mit der gro? angelegten Anwendung von Coroutinen in einer C/C++-Umgebung.

Wie man Coroutinen steuert Planung;

　Wie man mit synchronisierten Stil-
API
-Aufrufen wie Socket, MySQLclient usw. umgeht;

　Wie man mit der Verwendung vorhandener globaler Variablen und privater Thread-Variablen umgeht ;

Am Ende haben wir alle oben genannten Probleme durch libco gel?st und eine nicht-invasive asynchrone Transformation der Gesch?ftslogik erreicht. Wir haben libco verwendet, um Hunderte von WeChat-Backend-Modulen in Coroutinen und asynchrone Transformationen umzuwandeln. W?hrend des Transformationsprozesses blieb der Gesch?ftslogikcode im Wesentlichen unver?ndert. Bisher handelt es sich bei den meisten Diensten im WeChat-Backend um Multiprozess- oder Multithread-Coroutine-Modelle. Die Parallelit?tsf?higkeiten wurden im Vergleich zu früher qualitativ verbessert, und libco ist zum Eckpfeiler des WeChat-Backend-Frameworks geworden. 　libco-Framework

Libco ist im Framework in drei Schichten unterteilt, n?mlich Schnittstellenschicht, System
Funktion
Hook-Schicht und
Ereignis

Treiber
Schicht.

Verarbeitung von APIs im synchronen Stil

Bei APIs im synchronen Stil, haupts?chlich synchronen Netzwerkaufrufen, besteht die Hauptaufgabe von libco darin, die Ressourcenbelegung durch diese Wartezeiten zu beseitigen und die Parallelit?tsleistung des Systems zu verbessern. Bei einem regul?ren Netzwerk-Hintergrunddienst k?nnen wir Schritte wie Verbinden, Schreiben, Lesen usw. durchlaufen, um eine vollst?ndige Netzwerkinteraktion abzuschlie?en. Wenn diese APIs synchron aufgerufen werden, bleibt der gesamte Thread h?ngen und wartet auf eine Netzwerkinteraktion.

Obwohl die Parallelit?tsleistung des synchronen Programmierstils nicht gut ist, bietet er die Vorteile einer klaren Codelogik und eines einfachen Schreibens und kann eine schnelle Gesch?ftsiteration und eine agile Entwicklung unterstützen. Um die Vorteile der synchronen Programmierung weiterhin aufrechtzuerhalten, ohne den vorhandenen Gesch?ftslogikcode online zu ?ndern, hat libco innovativ die Netzwerkaufrufschnittstelle (Hook) übernommen und die übergabe und Wiederherstellung der Coroutine als Ereignis im asynchronen Netzwerk-IO mit Rückrufen registriert . Wenn die Gesch?ftsverarbeitung auf eine synchrone Netzwerkanforderung st??t, registriert die Libco-Schicht die Netzwerkanforderung als asynchrones Ereignis. Diese Coroutine gibt die CPU-Belegung auf und die CPU wird zur Ausführung an andere Coroutinen übergeben. Libco setzt die Coroutine-Ausführung automatisch fort, wenn ein Netzwerkereignis auftritt oder eine Zeitüberschreitung auftritt.

Wir haben die meisten APIs im Synchronisierungsstil über die Hook-Methode übernommen, und libco plant die Coroutine so, dass sie die Ausführung zum richtigen Zeitpunkt wieder aufnimmt.

Dutzende Millionen von Coroutinen werden unterstützt
Standardm??ig erlaubt libco, dass jede Coroutine ihren eigenen laufenden Stapel hat. Wenn die Coroutine erstellt wird, wird ein Speicher fester Gr??e aus dem Heap-Speicher als laufender Stapel zugewiesen für die Coroutine. Wenn wir eine Coroutine verwenden, um eine Zugriffsverbindung am Front-End abzuwickeln, wird bei einem massiven Zugriffsdienst die Parallelit?tsbeschr?nkung unseres Dienstes leicht durch den Speicher begrenzt. Zu diesem Zweck bietet libco auch einen stapellosen Coroutine-Sharing-Stack-Modus, der es Ihnen erm?glicht, mehrere Coroutinen so einzurichten, dass sie denselben laufenden Stack teilen. Beim Wechsel zwischen Coroutinen unter demselben gemeinsam genutzten Stack muss der aktuell ausgeführte Stack-Inhalt in den privaten Speicher der Coroutine kopiert werden. Um die Anzahl solcher Speicherkopien zu reduzieren, erfolgt die Speicherkopie des gemeinsam genutzten Stapels nur beim Wechsel zwischen verschiedenen Coroutinen. Wenn sich der Beleger des gemeinsam genutzten Stapels nicht ge?ndert hat, besteht keine Notwendigkeit, den laufenden Stapel zu kopieren.

Der Shared-Coroutine-Stack-Modus von libco coroutine macht es einer einzelnen Maschine leicht, auf zig Millionen Verbindungen zuzugreifen, indem einfach genügend Coroutinen erstellt werden. Wir erstellen 10 Millionen Coroutinen (E5-2670 v3 bei 2,30 GHz * 2, 128 G Speicher) über den libco-Shared-Stack-Modus. Jede 100.000 Coroutine verwendet 128 KB Speicher, und der gesamte echo-Dienst ist stabil Der Gesamtspeicherverbrauch ist etwa 66G.
Private Coroutine-Variablen
Wenn ein Multiprozessprogramm in ein Multithread-Programm umgewandelt wird, k?nnen wir Threads verwenden, um globale Variablen schnell zu ?ndern. In der Coroutine-Umgebung haben wir die Coroutine-Variable ROUTINE_VAR erstellt, was das Reduzieren erheblich vereinfacht die Arbeitsbelastung der Coroutine-Transformation.
Da Coroutinen im Wesentlichen seriell innerhalb eines Threads ausgeführt werden, kann es beim Definieren einer privaten Thread-Variablen zu Wiedereintrittsproblemen kommen. Wenn wir beispielsweise eine private Thread-Variable eines Threads definieren, wollten wir ursprünglich, dass jede Ausführungslogik exklusiven Zugriff auf diese Variable hat. Wenn unsere Ausführungsumgebung jedoch auf Coroutinen migriert wird, kann dieselbe private Thread-Variable von mehreren Coroutinen bedient werden, was zu dem Problem des Eindringens von Variablen führt. Aus diesem Grund haben wir bei der asynchronen Transformation von libco die meisten privaten Thread-Variablen in private Variablen auf Coroutine-Ebene ge?ndert. Private Coroutine-Variablen weisen die folgenden Merkmale auf: Wenn der Code in einer Multithread-Nicht-Coroutine-Umgebung ausgeführt wird, ist die Variable Thread-privat. Wenn der Code in einer Coroutine-Umgebung ausgeführt wird, ist diese Variable Coroutine-privat. Die zugrunde liegenden privaten Variablen der Coroutine vervollst?ndigen automatisch die Beurteilung der laufenden Umgebung und geben den erforderlichen Wert korrekt zurück.
Private Coroutine-Variablen spielen eine entscheidende Rolle bei der Umstellung der bestehenden Umgebung von Synchronisation auf Asynchronisation. Gleichzeitig haben wir eine sehr einfache und praktische Methode zum Definieren privater Coroutine-Variablen definiert, die so einfach ist wie nur eine Deklarationszeile Code.
　Hook-Methode von gethostbyname
Für bestehende Netzwerkdienste kann es erforderlich sein, DNS abzufragen, um die tats?chliche Adresse über die gethostbyname-API-Schnittstelle des Systems zu erhalten. W?hrend der Coroutine-Transformation haben wir festgestellt, dass die Socket-Familienfunktion unseres Hooks nicht auf gethostbyname anwendbar ist. Wenn eine Coroutine gethostbyname aufruft, wartet sie synchron auf das Ergebnis, was dazu führt, dass die Ausführung anderer Coroutinen im selben Thread verz?gert wird. Wir haben den gethostbyname-Quellcode von glibc untersucht und festgestellt, dass der Hook haupts?chlich deshalb nicht wirksam wird, weil glibc eine Abfragemethode zum Warten auf Ereignisse anstelle einer allgemeinen Abfragemethode definiert und gleichzeitig auch eine private Thread-Variable zum Umschalten definiert Verschiedene Coroutinen k?nnen zu ungenauen Daten führen. Die endgültige Asynchronisierung der gethostbyname-Coroutine wird durch die Hook-Polling-Methode und die Definition privater Coroutine-Variablen gel?st.
Gethostbyname ist eine von glibc bereitgestellte synchrone Abfrage-DNS-Schnittstelle. Es gibt viele hervorragende asynchrone L?sungen für gethostbyname in der Branche, aber diese Implementierungen erfordern die Einführung einer Bibliothek eines Drittanbieters und erfordern, dass die zugrunde liegende Schicht einen asynchronen Rückrufbenachrichtigungsmechanismus bereitstellt . Durch die Hook-Methode realisiert libco die Asynchronisierung von gethostbyname, ohne den Glibc-Quellcode zu ?ndern.
Coroutine-Semaphor
In einer Multithread-Umgebung müssen wir beispielsweise die Ausführung eines Threads auf das Signal eines anderen Threads warten pthread_signal, um es zu l?sen. In libco definieren wir das Coroutine-Semaphor co_signal, um die Parallelit?tsanforderungen zwischen Coroutinen zu erfüllen. Eine Coroutine kann entscheiden, eine wartende Coroutine zu benachrichtigen oder alle wartenden Coroutinen über co_cond_signal und co_cond_broadcast aufzuwecken.
Zusammenfassung
Libco ist eine effiziente C/C++-Coroutine-Bibliothek, die eine vollst?ndige Coroutine-Programmierschnittstelle, h?ufig verwendete Funktions-Hooks der Socket-Familie usw. bereitstellt und es Unternehmen erm?glicht, synchrone Programmiermodelle für eine schnelle iterative Entwicklung zu verwenden. Mit seinem stabilen Betrieb in den letzten Jahren hat libco als Eckpfeiler des Backend-Frameworks von WeChat eine entscheidende Rolle gespielt.

[Verwandte Empfehlungen]

1. Quellcode der WeChat-Plattform herunterladen

2. Quellcode des Alizi-Bestellsystems kostenlos herunterladen

Das obige ist der detaillierte Inhalt vonErfahren Sie, wie libco gro?e Mengen an Dateninformationen unterstützt. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!