Routage des messages
Kafka fournit des fonctionnalités de routage via Kafka Connect et Kafka Streams, y compris le routage basé sur le contenu, la transformation des messages et l’enrichissement des messages.
Le routage des messages Memphis est similaire à la mise en œuvre de RabbitMQ utilisant des clés de routage, des caractères génériques, un routage basé sur le contenu, etc. Semblable à RabbitMQ, il est également intégré au courtier et ne nécessite pas de bibliothèques ou d’outils externes.
Compactage des journaux
Le compactage a été créé pour prendre en charge un magasin d’enregistrements à long terme et potentiellement infini basé sur des clés spécifiques.
Kafka prend en charge le compactage de sujet natif, qui s’exécute sur tous les courtiers. Cela s’exécute automatiquement pour les rubriques compactées, condensant le journal à la dernière version des messages partageant la même clé.
Pour le moment, Memphis ne prend pas en charge le compactage, mais il le fera à l’avenir.
Relecture des messages
La possibilité de réutiliser les messages validés.
Kafka prend en charge la relecture en recherchant des décalages spécifiques car les consommateurs ont le contrôle sur la réinitialisation du décalage.
Memphis ne prend pas encore en charge la relecture mais le fera dans un avenir proche (2023).
Enrichissement de flux
Kafka, avec sa bibliothèque Kafka Streams, permet aux développeurs d’implémenter des applications clientes élastiques et évolutives qui peuvent tirer parti des fonctionnalités essentielles de traitement de flux telles que les tables, les jointures et les agrégations de plusieurs sujets et exporter vers plusieurs sources via Kafka connect.
Memphis offre un comportement similaire et plus encore. Embarqués à l’intérieur du broker, les utilisateurs de Memphis peuvent créer des fonctions de type serverless ou des applications conteneurisées complètes qui agrègent plusieurs stations et flux, décorent et enrichissent des messages provenant de différentes sources, écrivent des fonctions complexes non réalisables via SQL et manipulent le schéma. De plus, les cadres de connecteurs intégrés Memphis aideront à pousser les résultats directement vers un puits défini.
Pull Retry Mécanisme
En cas d’échec ou d’incapacité à accuser réception des messages consommés, il devrait y avoir un mécanisme de nouvelle tentative qui tentera à nouveau d’extraire le même décalage ou lot de messages.
Dans Kafka, il est de la responsabilité du client d’en implémenter un. Certains facteurs clés doivent être pris en compte pour mettre en œuvre un tel mécanisme, comme le blocage ou le non-blocage, le suivi des décalages, l’idempotence, etc.
À Memphis, le mécanisme de nouvelle tentative est intégré et activé par défaut dans le SDK et le courtier. Lors de la création du consommateur, le paramètre maxMsgDeliveries déterminera le nombre de tentatives, la station délivrera un message si un accusé de réception n’arrive pas avant maxAckTimeMs . Le courtier lui-même enregistre les décalages donnés et n’exposera que ceux non reconnus à la demande de nouvelle tentative.