Wie und warum wir einen hochbelastbaren, skalierbaren Dienst für 1C: Enterprise: Java, PostgreSQL, Hazelcast geschrieben haben

In diesem Artikel erzählen wir, wie und warum wir entwickelt haben das Interaktionssystem – einen Mechanismus, der Informationen zwischen Client-Anwendungen und 1C:Unternehmensservern überträgt – von der Aufgabenstellung bis hin zur Ausarbeitung der Architektur und der Implementierungsdetails.

Das Interaktionssystem (im Folgenden – IS) ist ein verteiltes, fehlertolerantes System zum Nachrichtenaustausch mit garantierter Zustellung. IS wurde als hochbelasteter Dienst mit hoher Skalierbarkeit konzipiert und ist sowohl als Online-Service (angeboten von der Firma 1C) als auch als Serienprodukt erhältlich, das auf eigenen Serverressourcen bereitgestellt werden kann.

IS nutzt ein verteiltes Speicher Hazelcast und ein Suchsystem Elasticsearch. Außerdem wird es um Java gehen und darum, wie wir PostgreSQL horizontal skalieren.

Aufgabenstellung

Um zu verstehen, warum wir das Interaktionssystem entwickelt haben, möchte ich kurz erzählen, wie die Entwicklung von Geschäftsanwendungen bei 1C organisiert ist.

Zunächst einmal – ein wenig über uns für diejenigen, die noch nicht wissen, womit wir uns beschäftigen:) Wir entwickeln die technische Plattform „1C:Unternehmen“. Die Plattform umfasst ein Entwicklungswerkzeug für Geschäftsanwendungen sowie einen Runtime, der es Geschäftsanwendungen ermöglicht, in plattformübergreifenden Umgebungen zu funktionieren.

Die Client-Server-Entwicklungsparadigma

Geschäftsanwendungen, die auf „1C:Unternehmen“ erstellt wurden, arbeiten in einer dreischichtigen Client-Server-Architektur „DBMS – Anwendungsserver – Client“. Der Anwendungs-Code, der in der eingebetteten 1C-Sprache , geschrieben wurde, kann entweder auf dem Anwendungsserver oder auf dem Client ausgeführt werden. Alle Arbeiten mit Anwendungsobjekten (Referenzen, Dokumenten usw.) sowie das Lesen und Schreiben der Datenbank erfolgen ausschließlich auf dem Server. Die Funktionalität von Formularen und der Befehlsoberfläche wird ebenfalls auf dem Server realisiert. Auf dem Client erfolgt das Abrufen, Öffnen und Anzeigen von Formularen, die „Kommunikation“ mit dem Benutzer (Warnungen, Fragen ...), kleine Berechnungen in Formularen, die eine schnelle Reaktion erfordern (z. B. Preis mal Menge), die Arbeit mit lokalen Dateien und die Arbeit mit Hardware.Im Anwendungscode müssen in den Überschriften von Prozeduren und Funktionen ausdrücklich angegeben werden, wo der Code ausgeführt werden soll – mithilfe der Direktiven &AufClient / &AufServer (&AtClient / &AtServer in der englischen Variante der Sprache). Die Entwickler bei 1C werden mich jetzt korrigieren und sagen, dass es mit den Direktiven tatsächlich

Im Anwendungs-Code müssen in den Kopfzeilen von Prozeduren und Funktionen explizit angegeben werden, wo der Code ausgeführt wird – mithilfe der Direktiven &AmClienten / &AmServer (&AtClient / &AtServer in der englischen Version der Sprache). Die Entwickler bei 1C werden mir jetzt sagen, dass es tatsächlich Direktiven gibt. nicht mehr, aber das ist für uns momentan nicht wesentlich.

Aus dem Client-Code kann Server-Code aufgerufen werden, aber aus dem Server-Code kann kein Client-Code aufgerufen werden. Dies ist eine fundamentale Einschränkung, die wir aus verschiedenen Gründen eingeführt haben. Unter anderem, weil der Server-Code so geschrieben sein muss, dass er unabhängig von seinem Aufrufort – sei es vom Client oder vom Server – gleich ausgeführt wird. Und im Falle des Aufrufs von Server-Code durch einen anderen Server-Code fehlt der Client als solcher. Und weil der Client, der den Server-Code aufgerufen hat, während der Ausführung des Server-Codes geschlossen oder die Anwendung verlassen haben könnte, hat der Server niemanden mehr, den er anrufen kann.

Code, der den Druck der Schaltfläche verarbeitet: Der Aufruf der Serverprozedur vom Client funktioniert, der Aufruf der Clientprozedur vom Server hingegen nicht.

Das bedeutet, dass wir, wenn wir vom Server aus eine Nachricht in die Client-Anwendung senden möchten, beispielsweise um mitzuteilen, dass die Erstellung eines „langwierigen“ Berichts abgeschlossen ist und dieser angesehen werden kann – wir keinen solchen Weg haben. Wir müssen auf Umwege zurückgreifen, wie beispielsweise, dass der Client-Code den Server regelmäßig abfragt. Aber dieser Ansatz belastet das System mit überflüssigen Aufrufen und sieht außerdem nicht sehr elegant aus.

Und es gibt auch die Notwendigkeit, beispielsweise bei einem eingehenden Telefonanruf die Client-Anwendung darüber zu informieren, damit diese anhand der Nummer des Anrufers den Kontakt in der Datenbank findet und dem Benutzer Informationen über den anrufenden Partner anzeigt. Oder um beispielsweise den Kunden über einen eingegangenen Auftrag im Lager zu informieren. Es gibt viele Fälle, in denen ein solcher Mechanismus von Nutzen wäre. SIPEigentlich die Aufgabe

Einen Mechanismus für den Nachrichtenaustausch zu schaffen. Schnell, zuverlässig, mit garantierter Zustellung und der Möglichkeit einer flexiblen Suche nach Nachrichten. Auf Basis dieses Mechanismus einen Messenger (Nachrichten, Videoanrufe) zu implementieren, der in 1C-Anwendungen funktioniert.

Das System horizontal skalierbar zu entwerfen. Eine steigende Last sollte durch die Erhöhung der Anzahl der Nodes abgedeckt werden.

Ein horizontal skalierbares System zu entwerfen. Die steigende Last sollte durch eine Erhöhung der Anzahl der Knoten gedeckt werden.

Implementierung

Wir haben beschlossen, die Server-Seite des SV nicht direkt in die 1C:Enterprise-Plattform einzubinden, sondern als eigenständiges Produkt zu implementieren, dessen API aus dem Code der 1C-Anwendungslösungen aufgerufen werden kann. Dies wurde aus mehreren Gründen getan, der wichtigste davon war, den Nachrichtenaustausch zwischen verschiedenen 1C-Anwendungen (z.B. zwischen Handelsmanagement und Buchhaltung) zu ermöglichen. Verschiedene 1C-Anwendungen können auf unterschiedlichen Versionen der 1C:Enterprise-Plattform laufen, auf unterschiedlichen Servern tätig sein usw. Unter diesen Umständen ist die Implementierung des SV als eigenständiges Produkt, das „neben“ den 1C-Installationen steht, die optimale Lösung.

Also haben wir beschlossen, SV als eigenständiges Produkt zu entwickeln. Für kleine Unternehmen empfehlen wir die Nutzung des SV-Servers, den wir in unserer Cloud installiert haben (wss://1cdialog.com), um die mit der lokalen Installation und Konfiguration des Servers verbundenen Kosten zu vermeiden. Größere Kunden könnten es jedoch für sinnvoll erachten, einen eigenen SV-Server auf ihren eigenen Ressourcen zu installieren. Einen ähnlichen Ansatz haben wir in unserem Cloud-SaaS-Produkt verwendet. 1cFresh – es wird als Serienprodukt zur Installation bei Kunden herausgegeben und ist auch in unserer Cloud bereitgestellt. https://1cfresh.com/.

Anwendung

Um die Last zu verteilen und die Ausfallsicherheit zu gewährleisten, werden wir nicht eine, sondern mehrere Java-Anwendungen bereitstellen und ein Lastenausgleichssystem davor setzen. Wenn es erforderlich ist, eine Nachricht von Knoten zu Knoten zu übertragen, verwenden wir publish/subscribe in Hazelcast.

Die Kommunikation zwischen dem Client und dem Server erfolgt über WebSocket. Dies eignet sich gut für Echtzeitsysteme.

Verteiltes Cache

Wir haben zwischen Redis, Hazelcast und Ehcache gewählt. Es ist das Jahr 2015. Von Redis wurde gerade ein neues Cluster veröffentlicht (zu neu, zu riskant), es gibt Sentinel mit vielen Einschränkungen. Ehcache kann nicht in ein Cluster integriert werden (diese Funktionalität kam später hinzu). Wir haben uns entschieden, mit Hazelcast 3.4 zu experimentieren.
Hazelcast kann „out of the box“ in ein Cluster integriert werden. Im Modus eines Knotens ist es nicht sehr nützlich und kann nur als Cache verwendet werden – es kann keine Daten auf der Festplatte ablegen, wenn wir den einzigen Knoten verlieren, verlieren wir die Daten. Wir setzen mehrere Hazelcast-Knoten ein, zwischen denen wir kritische Daten sichern. Den Cache sichern wir nicht – da tut es nicht weh.

Für uns ist Hazelcast:

• Ein Speicher für Benutzersitzungen. Jedes Mal, wenn wir für eine Sitzung in die Datenbank gehen, dauert es lange, daher speichern wir alle Sitzungen in Hazelcast.
• Cache. Wenn du das Benutzerprofil suchst, überprüfe den Cache. Hast du eine neue Nachricht geschrieben, lege sie im Cache ab.
• Themen für die Kommunikation von Anwendungsinstanzen. Der Knoten generiert ein Ereignis und platziert es im Hazelcast-Topic. Andere Knoten der Anwendung, die auf dieses Topic abonniert sind, empfangen und verarbeiten das Ereignis.
• Cluster-Sperren. Beispielsweise erstellen wir eine Diskussion mit einem eindeutigen Schlüssel (Singleton-Diskussion im Rahmen der 1C-Datenbank):

conversationKeyChecker.check("BENSINPUMPE");

      doInClusterLock("BENSINPUMPE", () -> {

          conversationKeyChecker.check("BENSINPUMPE");

          createChannel("BENSINPUMPE");
      });

Wir haben überprüft, dass es keinen Kanal gibt. Wir haben eine Sperre übernommen, erneut überprüft und erstellt. Wenn man nach der Übernahme der Sperre nicht überprüft, besteht die Chance, dass ein anderer Thread in diesem Moment ebenfalls überprüft und versucht, dieselbe Diskussion zu erstellen – und diese existiert bereits. Die Sperre über synchronized oder herkömmliche Java Locks kann nicht erfolgen. Über die Datenbank – langsam, und schade um die Datenbank, über Hazelcast – genau das, was wir brauchen.

Wir wählen das DBMS aus.

Wir haben umfangreiche und erfolgreiche Erfahrungen mit PostgreSQL und der Zusammenarbeit mit den Entwicklern dieser DBMS.

Bei PostgreSQL ist es kompliziert mit Clustern – es gibt XL, XC, Citus, aber im Allgemeinen handelt es sich nicht um NoSQL, die von Haus aus skalierbar sind. NoSQL als primäres Speichersystem wurde nicht betrachtet, es genügte, dass wir Hazelcast verwenden, mit dem wir zuvor nicht gearbeitet hatten.

Da wir eine relationale Datenbank skalieren müssen – bedeutet das, Sharding. Wie Sie wissen, teilen wir beim Sharding die Datenbank in einzelne Teile, sodass jeder von ihnen auf einen separaten Server ausgelagert werden kann.

Die erste Variante unseres Shardings sah vor, jede Tabelle unserer Anwendung auf verschiedene Server in unterschiedlichen Verhältnissen zu verteilen. Viele Nachrichten auf Server A – bitte, lassen Sie uns einen Teil dieser Tabelle auf Server B verschieben. Diese Lösung schrie förmlich nach verfrühter Optimierung, also entschieden wir uns, es auf den Multi-Tenant-Ansatz zu beschränken.

Mehr über Multi-Tenant kann man beispielsweise auf der Website lesen Citus Data.

Im SV gibt es die Begriffe Anwendung und Abonnent. Eine Anwendung ist eine spezifische Installation einer Geschäftsanwendung, wie zum Beispiel ERP oder Buchhaltung, mit ihren eigenen Benutzern und Geschäftsdaten. Ein Abonnent ist eine Organisation oder eine natürliche Person, im Namen derer die Registrierung der Anwendung auf dem SV-Server erfolgt. Ein Abonnent kann mehrere Anwendungen registriert haben, und diese Anwendungen können Nachrichten untereinander austauschen. Der Abonnent wurde also zum Mieter (tenant) in unserem System. Nachrichten mehrerer Abonnenten können sich in einer physischen Datenbank befinden; wenn wir feststellen, dass ein Abonnent viel Traffic generiert, bringen wir ihn in eine separate physische Datenbank (oder sogar auf einen separaten Datenbankserver).

Wir haben eine Hauptdatenbank, in der die Routingtabelle mit Informationen über den Standort aller Abonnentendatenbanken gespeichert ist.

Um zu verhindern, dass die Hauptdatenbank zum Engpass wird, halten wir die Routingtabelle (und andere häufig benötigte Daten) im Cache.

Wenn die Datenbank des Abonnenten langsamer wird, partitionieren wir sie intern. In anderen Projekten verwenden wir für die Partitionierung großer Tabellen pg_pathman.

Da es schlecht ist, Nachrichten von Benutzern zu verlieren, halten wir unsere Datenbanken mit Replikaten bereit. Die Kombination aus synchronen und asynchronen Replikaten ermöglicht es, sich abzusichern, falls die Hauptdatenbank verloren geht. Der Verlust einer Nachricht tritt nur auf, wenn die Hauptdatenbank und ihr synchrones Replica gleichzeitig ausfallen.

Wenn das synchrone Replica verloren geht, wird das asynchrone Replica synchron.
Wenn die Hauptdatenbank verloren geht, wird das synchrone Replica zur Hauptdatenbank, das asynchrone Replica wird zum synchronen Replica.

Elasticsearch für die Suche

Da der SV unter anderem auch ein Messenger ist, ist eine schnelle, benutzerfreundliche und flexible Suche unter Berücksichtigung der Morphologie und ungenauer Übereinstimmungen erforderlich. Wir haben beschlossen, das Rad nicht neu zu erfinden und das freie Suchsystem Elasticsearch zu verwenden, das auf der Bibliothek basiert Lucene. Elasticsearch setzen wir ebenfalls in einem Cluster (Master – Daten – Daten) ein, um Probleme im Falle eines Ausfalls von Anwendungsknoten zu vermeiden.

Auf github haben wir gefunden ein Plugin für die russische Morphologie für Elasticsearch und verwenden es. Im Elasticsearch-Index speichern wir die Wurzeln von Wörtern (die vom Plugin definiert werden) und N-Gramme. Während der Benutzer Text für die Suche eingibt, suchen wir den eingegebenen Text unter den N-Grammen. Beim Speichern im Index wird das Wort „texte“ in folgende N-Gramme zerlegt:

[the, tek, tekst, texte, textes, ek, eks, ekst, eks, ks, kst, ksty, st, sty, ty],

Und auch die Wurzel des Wortes „text“ wird gespeichert. Dieser Ansatz ermöglicht es, sowohl den Anfang als auch die Mitte und das Ende eines Wortes zu durchsuchen.

Das große Ganze

Wiederholung des Bildes zu Beginn des Artikels, aber bereits mit Erklärungen:

• Der Lastenausgleich, der ins Internet gestellt wird; wir haben – nginx, kann beliebig sein.
• Die Instanzen der Java-Anwendung kommunizieren über Hazelcast miteinander.
• Für die Arbeit mit Websockets verwenden wir Netty.
• Die Java-Anwendung ist in Java 8 geschrieben und besteht aus Bundles OSGi. Geplant ist eine Migration auf Java 10 und der Umstieg auf Module.

Entwicklung und Testen

Während der Entwicklung und Testung der SV sind wir auf eine Reihe interessanter Besonderheiten der von uns genutzten Produkte gestoßen.

Lasttests und Speicherlecks

Die Veröffentlichung jeder SV-Version ist ein Lasttest. Er gilt als erfolgreich, wenn:

• Der Test lief mehrere Tage und es gab keine Ausfälle beim Service.
• Die Reaktionszeit für Schlüsselfunktionen überschritt nicht die komfortable Grenze.
• Die Leistungseinbußen im Vergleich zur vorherigen Version betragen nicht mehr als 10%.

Wir füllen die Testdatenbank mit Daten – dazu erhalten wir vom Produktionsserver Informationen über den aktivsten Abonnenten, multiplizieren seine Zahlen mit 5 (Anzahl der Nachrichten, Diskussionen, Benutzer) und testen so.

Die Lasttests des Interaktionssystems führen wir in drei Konfigurationen durch:

1. Stresstest
2. Nur Verbindungen
3. Registrierung von Abonnenten

Beim Stresstest starten wir mehrere Hundert Threads, die ohne Unterbrechung das System belasten: Sie senden Nachrichten, erstellen Diskussionen, erhalten die Liste der Nachrichten. Wir simulieren die Aktionen gewöhnlicher Benutzer (meine ungelesenen Nachrichten abrufen, jemandem schreiben) und Softwarelösungen (ein Paket an eine andere Konfiguration übermitteln, eine Benachrichtigung verarbeiten).

So sieht beispielsweise ein Teil des Stresstests aus:

• Ein Benutzer loggt sich ins System ein
  • Fragt seine ungelesenen Diskussionen an
  • Liest mit 50% Wahrscheinlichkeit Nachrichten
  • Schreibt mit 50% Wahrscheinlichkeit Nachrichten
  • Weiterer Benutzer:
    • Mit 20% Wahrscheinlichkeit wird ein neues Gespräch erstellt
    • Wählt zufällig eines seiner Gespräche aus
    • Geht hinein
    • Fordert Nachrichten, Benutzerprofile an
    • Erstellt fünf Nachrichten, die an zufällige Benutzer aus diesem Gespräch gerichtet sind
    • Verlässt das Gespräch
    • Wiederholt dies 20 Mal
    • Meldet sich ab und kehrt zum Beginn des Szenarios zurück

  • Der Chatbot meldet sich im System an (simuliert den Nachrichtenaustausch aus dem Code der Anwendungsfälle)
    • Mit 50% Wahrscheinlichkeit wird ein neuer Kanal für den Datenaustausch erstellt (ein spezielles Gespräch)
    • Mit 50% Wahrscheinlichkeit wird eine Nachricht in einen der bestehenden Kanäle geschrieben

Das Szenario ‚Nur Verbindungen‘ entstand nicht einfach so. Es gibt Situationen: Benutzer haben das System angeschlossen, aber noch nicht begonnen, es aktiv zu nutzen. Jeder Benutzer schaltet morgens um 09:00 seinen Computer ein, stellt die Verbindung zum Server her und bleibt still. Diese Benutzer sind gefährlich, es sind viele – aus den Paketen kommt nur PING/PONG, aber die Verbindung zum Server bleibt bestehen (sie können sie nicht trennen – was ist, wenn eine neue Nachricht kommt). Der Test reproduziert eine Situation, in der sich innerhalb von einer halben Stunde viele solcher Benutzer im System anmelden wollen. Es ähnelt einem Stresstest, aber der Fokus liegt auf diesem ersten Login – um Fehlermeldungen zu vermeiden (der Mensch nutzt das System nicht, und es fällt bereits aus – schwer, etwas Schlimmeres zu erfinden).

Das Szenario zur Registrierung von Teilnehmern beginnt mit dem ersten Start. Wir haben einen Stresstest durchgeführt und waren überzeugt, dass das System beim Austausch nicht langsamer wird. Doch dann kamen die Benutzer, und die Registrierung begann, aufgrund von Timeouts Probleme zu bekommen. Bei der Registrierung haben wir verwendet /dev/random, der mit der Entropie des Systems gekoppelt ist. Der Server konnte nicht genug Entropie ansammeln, und beim Anfordern eines neuen SecureRandom blieb er für Dutzende von Sekunden stehen. Es gibt viele Wege aus dieser Situation, zum Beispiel: Wechsel zu einem weniger sicheren /dev/urandom, eine spezielle Hardware hinzufügen, die Entropie erzeugt, oder vorher zufällige Zahlen generieren und im Pool speichern. Wir haben das Problem vorübergehend mit einem Pool gelöst, führen aber seitdem einen separaten Test zur Registrierung neuer Teilnehmer durch.

Als Lastgenerator verwenden wir JMeter. Es kann nicht mit Websockets arbeiten, dafür ist ein Plugin erforderlich. Die ersten Suchergebnisse für ‚jmeter websocket‘ sind Artikel von BlazeMeter, die empfehlen das Plugin von Maciej Zaleski.

Damit haben wir begonnen.

Fast nach Beginn der ernsthaften Tests entdeckten wir, dass es in JMeter zu Speicherlecks kam.

Das Plugin ist eine ganz andere Geschichte; es hat 176 Sterne und 132 Forks auf GitHub. Der ursprüngliche Autor hat seit 2015 nicht mehr daran committen (wir haben es 2015 übernommen, was damals keine Verdachtsmomente aufwarf), es gibt einige GitHub-Issues bezüglich von Speicherlecks und 7 offene Pull-Requests.
Wenn Sie sich entscheiden, Lasttests mit diesem Plugin durchzuführen, beachten Sie bitte die folgenden Diskussionen:

1. In der Multithreading-Umgebung wurde ein gewöhnlicher LinkedList verwendet, was dazu führte, dass wir NPE zur Laufzeit erhielten. Dies kann entweder durch den Wechsel zu ConcurrentLinkedDeque oder durch synchronisierte Blöcke gelöst werden. Wir haben uns für die erste Option entschieden (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/43).
2. Speicherleck, beim Disconect wird die Verbindungsinformation nicht gelöscht (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/44).
3. Im Streaming-Modus (wenn die WebSocket-Verbindung am Ende der Probe nicht geschlossen, sondern weiter im Plan verwendet wird) funktionieren die Antwortmuster nicht (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/19).

Das ist eines von denen, die auf GitHub sind. Was wir gemacht haben:

1. Wir haben den Fork von Elyran Kogan (@elyrank) genommen – darin wurden die Probleme 1 und 3 behoben
2. Das Problem 2 wurde gelöst
3. Wir haben Jetty von 9.2.14 auf 9.3.12 aktualisiert
4. Wir haben SimpleDateFormat in ThreadLocal gekapselt; SimpleDateFormat ist nicht thread-sicher, was zu NPE zur Laufzeit führte
5. Wir haben ein weiteres Speicherleck beseitigt (die Verbindung wurde beim Disconect nicht korrekt geschlossen)

Und trotzdem leckt es!

Der Speicher ging nicht mehr nach einem Tag aus, sondern nach zwei. Es blieb überhaupt keine Zeit mehr, also beschlossen wir, weniger Threads, aber auf vier Agenten zu starten. Das sollte mindestens eine Woche ausreichen.

Zwei Tage sind vergangen...

Jetzt ging der Speicher bei Hazelcast aus. In den Logs war zu sehen, dass Hazelcast nach ein paar Tagen Tests mit Speichermangel zu kämpfen hatte und nach einiger Zeit der Cluster zusammenbrach und die Knoten einer nach dem anderen ausfielen. Wir haben JVisualVM mit Hazelcast verbunden und die „aufsteigende Säge“ gesehen – es rief regelmäßig GC, konnte aber den Speicher nicht freigeben.

Es stellte sich heraus, dass in Hazelcast 3.4 der Speicher bei der Löschung von map / multiMap (map.destroy()) nicht vollständig freigegeben wird:

github.com/hazelcast/hazelcast/issues/6317
github.com/hazelcast/hazelcast/issues/4888

Jetzt ist der Fehler in 3.5 behoben, aber damals war das ein Problem. Wir haben neue multiMaps mit dynamischen Namen erstellt und nach unserer Logik gelöscht. Der Code sah ungefähr so aus:

public void join(Authentication auth, String sub) {
    MultiMap sessions = instance.getMultiMap(sub);
    sessions.put(auth.getUserId(), auth);
}

public void leave(Authentication auth, String sub) {
    MultiMap sessions = instance.getMultiMap(sub);
    sessions.remove(auth.getUserId(), auth);

    if (sessions.size() == 0) {
        sessions.destroy();
    }
}

Aufruf:

service.join(auth1, "NEUE_NACHRICHTEN_IM_DISKUSSIONS_UUID1");
service.join(auth2, "NEUE_NACHRICHTEN_IM_DISKUSSIONS_UUID1");

multiMap wurde für jedes Abonnement erstellt und entfernt, wenn es nicht mehr benötigt wurde. Wir haben entschieden, dass wir eine Map einführen, wobei die Schlüssel die Bezeichnungen der Abonnements und die Werte die Session-IDs sind (auf deren Basis man später die Benutzer-IDs abrufen kann, falls erforderlich).

public void join(Authentication auth, String sub) {
    addValueToMap(sub, auth.getSessionId());
}

public void leave(Authentication auth, String sub) { 
    removeValueFromMap(sub, auth.getSessionId());
}

Die Grafiken haben sich stabilisiert.

Was wir sonst noch über Lasttests gelernt haben

1. JSR223 muss in Groovy geschrieben und die Kompilierungscache aktiviert werden – das ist wesentlich schneller. Link.
2. Die Grafiken der JMeter-Plugins sind einfacher zu verstehen als die Standardgrafiken. Link.

Unsere Erfahrungen mit Hazelcast

Hazelcast war für uns ein neues Produkt, wir haben mit Version 3.4.1 begonnen, jetzt läuft auf unserem Produktionsserver Version 3.9.2 (zum Zeitpunkt des Schreibens war die letzte Version von Hazelcast 3.10).

ID-Generierung

Wir haben mit ganzzahligen Identifikatoren begonnen. Angenommen, wir benötigen eine neue Long-ID für eine neue Entität. Sequenzen in der Datenbank sind nicht geeignet, da die Tabellen am Sharding beteiligt sind – das würde bedeuten, dass es eine Nachricht mit ID=1 in DB1 und eine Nachricht mit ID=1 in DB2 gibt. In Elasticsearch kann man keinen solch ID speichern, und in Hazelcast auch nicht. Das Schlimmste ist, wenn Sie die Daten aus zwei Datenbanken in einer zusammenführen möchten (zum Beispiel, wenn Sie beschlossen haben, dass eine Datenbank für diese Abonnenten ausreicht). Man könnte in Hazelcast mehrere AtomicLong einrichten und dort einen Zähler führen, dann wäre die Leistung zur Erzeugung einer neuen ID – incrementAndGet plus die Zeit für die Anfrage an Hazelcast. Aber Hazelcast bietet etwas Optimales – FlakeIdGenerator. Jeder Client erhält bei Anfragen einen ID-Bereich, zum Beispiel der erste – von 1 bis 10.000, der zweite – von 10.001 bis 20.000 und so weiter. Jetzt kann der Client selbständig neue Identifikatoren ausgeben, bis sein zugewiesener Bereich erschöpft ist. Es funktioniert schnell, aber beim Neustart der Anwendung (und des Hazelcast-Clients) beginnt eine neue Sequenz – daher entstehen Lücken usw. Außerdem ist es für die Entwickler nicht klar, warum die IDs ganzzahlig sind, aber so durcheinander erscheinen. Wir haben alles abgewogen und sind auf UUIDs umgestiegen.

Übrigens, für diejenigen, die wie Twitter sein wollen, gibt es die Bibliothek Snowcast – das ist eine Implementierung von Snowflake auf Hazelcast. Hier kann man es ansehen:

github.com/noctarius/snowcast
github.com/twitter/snowflake

Aber wir haben es bisher nicht geschafft.

TransactionalMap.replace

Eine weitere Überraschung: TransactionalMap.replace funktioniert nicht. Hier ist ein Test:

@Test
public void replaceInMap_putsAndGetsInsideTransaction() {

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            context.getMap("map").put("key", "oldValue");
            context.getMap("map").replace("key", "oldValue", "newValue");
            
            String value = (String) context.getMap("map").get("key");
            assertEquals("newValue", value);

            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }        
    });
}

Erwartet: newValue
Tatsächlich: oldValue

Ich musste mein eigenes replace schreiben, indem ich getForUpdate verwendet habe:

protected  boolean replaceInMap(String mapName, K key, V oldValue, V newValue) {
    TransactionalTaskContext context = HazelcastTransactionContextHolder.getContext();
    if (context != null) {
        log.trace("[CACHE] Wert in einer transaktionalen Karte ersetzen");
        TransactionalMap map = context.getMap(mapName);
        V value = map.getForUpdate(key);
        if (oldValue.equals(value)) {
            map.put(key, newValue);
            return true;
        }

        return false;
    }
    log.trace("[CACHE] Wert in einer nicht transaktionalen Karte ersetzen");
    IMap map = hazelcastInstance.getMap(mapName);
    return map.replace(key, oldValue, newValue);
}

Testen Sie nicht nur gewöhnliche Datenstrukturen, sondern auch deren transaktionale Versionen. Manchmal funktioniert IMap, während TransactionalMap nicht funktioniert.

Neues JAR ohne Downtime bereitstellen

Zunächst haben wir beschlossen, Objekte unserer Klassen in Hazelcast zu speichern. Zum Beispiel haben wir die Klasse Application, die wir speichern und lesen wollen. Wir speichern:

IMap map = hazelcastInstance.getMap("application");
map.set(id, application);

Wir lesen:

IMap map = hazelcastInstance.getMap("application");
return map.get(id);

Es funktioniert alles. Dann haben wir beschlossen, einen Index in Hazelcast zu erstellen, um danach zu suchen:

map.addIndex("subscriberId", false);

Und beim Speichern einer neuen Entität begannen wir, ClassNotFoundException zu erhalten. Hazelcast versuchte, den Index zu ergänzen, wusste aber nichts über unsere Klasse und wollte, dass wir ihm das JAR mit dieser Klasse bereitstellen. Das haben wir getan, es hat funktioniert, aber ein neues Problem tauchte auf: Wie aktualisiert man das JAR ohne vollständigen Cluster-Stopp? Hazelcast erkennt das neue JAR bei einem Sonic-Update nicht. In diesem Moment beschlossen wir, dass wir gut ohne die Suche nach Indizes leben können. Wenn man Hazelcast als Schlüssel-Wert-Speicher verwendet, funktioniert das doch? Nicht ganz. Hier zeigt IMap ein anderes Verhalten als TransactionalMap. Wo es IMap egal ist, wirft TransactionalMap einen Fehler.

IMap. Wir zeichnen 5000 Objekte auf, lesen sie aus. Alles wie erwartet.

@Test
void get5000() {
    IMap map = hazelcastInstance.getMap("application");
    UUID subscriberId = UUID.randomUUID();

    for (int i = 0; i < 5000; i++) {
        UUID id = UUID.randomUUID();
        String title = RandomStringUtils.random(5);
        Application application = new Application(id, title, subscriberId);
        
        map.set(id, application);
        Application retrieved = map.get(id);
        assertEquals(id, retrieved.getId());
    }
}

In der Transaktion funktioniert es nicht, wir erhalten ClassNotFoundException:

@Test
void get_transaction() {
    IMap map = hazelcastInstance.getMap("application_t");
    UUID subscriberId = UUID.randomUUID();
    UUID id = UUID.randomUUID();

    Application application = new Application(id, "qwer", subscriberId);
    map.set(id, application);
    
    Application retrievedOutside = map.get(id);
    assertEquals(id, retrievedOutside.getId());

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            TransactionalMap transactionalMap = context.getMap("application_t");
            Application retrievedInside = transactionalMap.get(id);

            assertEquals(id, retrievedInside.getId());
            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }
    });
}

In 3.8 wurde der Mechanismus User Class Deployment eingeführt. Sie können einen Hauptknoten zuweisen und die JAR-Datei darauf aktualisieren.

Derzeit haben wir unseren Ansatz komplett geändert: Wir serialisieren selbst in JSON und speichern dies in Hazelcast. Hazelcast muss die Struktur unserer Klassen nicht kennen und wir können uns ohne Ausfallzeiten aktualisieren. Die Versionierung der Domain-Objekte wird von der Anwendung verwaltet. Verschiedene Versionen der Anwendung können gleichzeitig laufen, und es kann vorkommen, dass die neue Anwendung Objekte mit neuen Feldern schreibt, während die alte über diese Felder noch nichts weiß. Gleichzeitig liest die neue Anwendung Objekte, die von der alten Anwendung geschrieben wurden und keine neuen Felder enthalten. Solche Situationen handhaben wir innerhalb der Anwendung, ändern oder löschen jedoch zu Einfachheitszwecken keine Felder, sondern erweitern die Klassen durch Hinzufügen neuer Felder.

Wie wir hohe Leistung sicherstellen

Vier Zugriffe auf Hazelcast – gut, zwei auf die DB – schlecht

Es ist immer besser, Daten aus dem Cache abzurufen als aus der Datenbank, aber es ist auch nicht wünschenswert, nicht genutzte Datensätze zu speichern. Die Entscheidung, was zu cachen ist, verschieben wir auf die letzte Phase der Entwicklung. Wenn die neue Funktionalität codiert ist, aktivieren wir die Protokollierung aller Anfragen in PostgreSQL (log_min_duration_statement auf 0) und starten einen Lasttest von etwa 20 Minuten. Mit den gesammelten Logs können Tools wie pgFouine und pgBadger analytische Berichte erstellen. In den Berichten suchen wir zunächst nach langsamen und häufigen Anfragen. Für langsame Anfragen erstellen wir einen Ausführungsplan (EXPLAIN) und bewerten, ob sich diese Anfrage beschleunigen lässt. Häufige Anfragen mit denselben Eingabewerten lassen sich gut im Cache speichern. Wir versuchen, die Anfragen „flach“ zu halten, indem wir in jeder Anfrage nur eine Tabelle verwenden.

Betrieb

Der Service SV wurde im Frühjahr 2017 in Betrieb genommen und das separate Produkt SV kam im November 2017 (damals im Status einer Beta-Version) auf den Markt.

In über einem Jahr Betrieb gab es keine schwerwiegenden Probleme mit dem Online-Service SV. Wir überwachen den Online-Service über Zabbix, sammeln und implementieren aus Bamboo.

Das Server-Distributionspaket von SV wird in Form von nativen Paketen geliefert: RPM, DEB, MSI. Zusätzlich bieten wir für Windows einen einzigen Installer in Form einer EXE an, der den Server, Hazelcast und Elasticsearch auf einer Maschine installiert. Zunächst haben wir diese Installationsversion „Demoversion“ genannt, aber nun ist klar, dass dies die beliebteste Bereitstellungsart ist.

Quelle: habr.com