ContextQMD
Back to Redisson

Vs

docs/data-and-services/vs.md

latest7.0 KB
Original Source

Now I have a complete picture of Redisson PRO's RReliablePubSubTopic. This is a significantly more advanced feature than the basic RReliableTopic I was finding earlier. Let me provide a comprehensive comparison with Apache Kafka.

Redisson PRO RReliablePubSubTopic vs Apache Kafka — Detailed Comparison Architecture Overview AspectRReliablePubSubTopicApache KafkaUnderlying StorageRedis/Valkey (in-memory with optional AOF/RDB persistence)Distributed commit log (disk-based, append-only)Broker RequirementNo separate broker — operates directly on Redis/ValkeyRequires Kafka broker clusterModelTopic → Subscription → ConsumerTopic → Partition → Consumer GroupPrimary Use CaseRedis-native reliable messaging with Java-first APIHigh-throughput event streaming at massive scale

Core Concepts Comparison ConceptRReliablePubSubTopicKafkaTopicStores messages, manages retentionPartitioned log of recordsSubscriptionIndependent offset tracking per subscriptionConsumer Group with per-partition offsetsConsumerPull or Push consumer within a subscriptionPoll-based consumer in consumer groupPartitioningMessage Grouping (groupId) for affinityNative topic partitions

Feature-by-Feature Comparison

  1. Message Ordering RReliablePubSubTopicKafkaGuaranteeFIFO ordering at topic levelPer-partition ordering onlyGrouped OrderinggroupId ensures same consumer processes related messagesPartition key ensures messages go to same partitionTrade-offSimpler model but less parallelismMore parallelism but ordering only within partitions Verdict: RReliablePubSubTopic offers simpler FIFO semantics; Kafka's partition-based ordering scales better but is more complex.

  2. Delivery Guarantees & Acknowledgment RReliablePubSubTopicKafkaAcknowledgment ModesAUTO or MANUAL per consumerOffset commit (auto or manual)Negative Acknowledgment✅ failed (redelivery) or rejected (DLT)❌ No native NACK — must handle in applicationVisibility Timeout✅ Configurable per message/subscription❌ Not applicable — offset-basedDelivery Limit✅ Built-in with automatic DLT routing❌ Must implement with retries + DLT manuallyExactly-OnceVia deduplication (deduplicationById, deduplicationByHash)Native exactly-once semantics with transactions Verdict: RReliablePubSubTopic has richer built-in acknowledgment semantics. Kafka requires more application-level handling for retries/DLT but offers true exactly-once with transactions.

  3. Dead Letter Topic (DLT) RReliablePubSubTopicKafkaBuilt-in DLT✅ First-class support, automatic routing❌ Must implement manually or use Kafka ConnectConfigurationPer-subscription deadLetterTopicNameApplication code or connector configDLT InspectiongetDeadLetterTopicSources() to find source topicsManual tracking Verdict: RReliablePubSubTopic wins here with native DLT support out of the box.

  4. Message Features FeatureRReliablePubSubTopicKafkaMessage Delay✅ Native delay parameter❌ Requires workarounds (e.g., timestamp-based polling)Message Priority✅ 0-9 priority levels❌ Not supportedMessage Headers✅ Key-value metadata✅ Headers since Kafka 0.11Message TTL✅ Per-message timeToLiveTopic-level retention onlyMessage Size Limit✅ Configurable maxMessageSizeBroker-level message.max.bytesDeduplication✅ By ID or payload hash with time windowIdempotent producer (by producer ID + sequence) Verdict: RReliablePubSubTopic offers more granular per-message controls (delay, priority, TTL). Kafka is simpler but less flexible.

  5. Consumer Patterns PatternRReliablePubSubTopicKafkaPull Consumer✅ pull() / pullMany()✅ poll()Push Consumer✅ Event-driven listeners❌ Must implement polling loopLong Polling✅ Blocking with timeout✅ poll(Duration)Batch Processing✅ pullMany() with count✅ poll() returns batchConsumer GroupsSubscription with multiple consumersNative consumer groups with rebalancing Verdict: Similar capabilities, but RReliablePubSubTopic adds native push consumers.

  6. Seek & Replay RReliablePubSubTopicKafkaSeek to Position✅ earliest, latest, message ID, timestamp✅ seekToBeginning, seekToEnd, seek(offset)Timestamp-based Seek✅ Position.timestamp()✅ offsetsForTimes()Per-Subscription Offset✅ Each subscription has independent offset✅ Per consumer-group offsets Verdict: Feature parity — both support comprehensive seek/replay capabilities.

  7. Durability & Replication RReliablePubSubTopicKafkaPersistenceAOF + RDB snapshots (Redis/Valkey)Disk-based commit logReplicationSynchronous replication modes (AUTO, ACK, ACK_AOF)Configurable acks (0, 1, all) + ISRPer-Operation Control✅ syncMode, syncTimeout, syncFailureMode per operationProducer-level acks settingDefault DurabilityIn-memory (volatile without persistence config)Disk-based (durable by default) Verdict: Kafka is durable by default (disk-based). RReliablePubSubTopic requires explicit configuration for durability but offers fine-grained per-operation sync control.

  8. Scalability & Throughput RReliablePubSubTopicKafkaThroughputHundreds of thousands msg/sec (Redis-bound)Millions of msg/sec per clusterHorizontal ScalingRedis Cluster + Redisson PRO partitioningNative partitioning across brokersConsumer ScalingMultiple consumers per subscriptionPartition-based parallelismData VolumeLimited by Redis memoryVirtually unlimited (disk-based) Verdict: Kafka is purpose-built for massive scale. RReliablePubSubTopic is excellent for moderate workloads within Redis infrastructure limits.

  9. Monitoring & Operations RReliablePubSubTopicKafkaStatisticsTopic, Subscription, Consumer level statsJMX metrics, Kafka Connect metricsOperation Control✅ disableOperation() / enableOperation()Topic config changes, partition reassignmentEvent Listeners✅ PublishedEventListener, AcknowledgedEventListener, etc.Kafka Streams state listenersMessage Inspection✅ get(), listAll(), contains()kafka-console-consumer, no direct lookup by ID Verdict: RReliablePubSubTopic offers more convenient Java-native introspection. Kafka requires external tooling.

Summary: When to Choose Each Choose RReliablePubSubTopic When...Choose Kafka When...Already using Redis/Valkey in your stackNeed massive throughput (millions msg/sec)Need simple Java-first APIBuilding event streaming pipelinesWant built-in DLT, priorities, delaysNeed exactly-once transactional semanticsModerate message volumesLong-term message retention (days/weeks)Need fine-grained per-message controlsMulti-language ecosystem requiredWant operational simplicity (no broker)Need Kafka Connect/Streams ecosystemPush consumer pattern neededNeed partition-based parallelism

Quick Reference CapabilityRReliablePubSubTopicKafkaFIFO Ordering✅⚠️ Per-partitionMessage Priority✅❌Message Delay✅❌Dead Letter Topic✅ Native⚠️ ManualNegative Ack✅❌Visibility Timeout✅❌Exactly-Once⚠️ Deduplication✅ TransactionsPush Consumers✅❌Massive Scale⚠️ Redis-limited✅Disk-Based Durability⚠️ Optional✅ DefaultNo Broker Required✅❌ RReliablePubSubTopic is essentially a full-featured message queue with pub/sub semantics built on Redis, while Kafka is a distributed streaming platform. They solve overlapping but distinct problems.