TDMQ for CKafka
- Release Notes and Announcements
- Product Introduction
- Technical Principles
- High Availability
- Purchase Guide
- Billing Overview
- Getting Started
- Obtaining Access Permission
- VPC Access
- Step 4. Send/Receive Messages
- Access via Public Domain Name
- Step 5. Send/Receive Messages
- Development Guide
- Operation Guide
- Instance Management
- Topic Management
- Instance Topic
- Elastic Topic
- Consumer Group
- Monitoring and Alarms
- Smart Ops
- Permission Management
- Migration to Cloud
- CKafka Connector
- Task Management
- Creating Data Access Task
- Creating Data Distribution Task
- Simple Data Processing
- Practical Tutorial
- Practical Tutorial of CKafka Client
- Connector Practical Tutorial
- Reporting over HTTP
- Querying Subscription to Database Change Info
- Log Access
- Troubleshooting
- Topic Failures
- Consumer Group Failures
- Client Failures
- API Documentation
- Making API Requests
- DataHub APIs
- ACL APIs
- Topic APIs
- Instance APIs
- Other APIs
- SDK Documentation
- SDK for Java
- SDK for Python
- SDK for Node.js
- SDK for Connector
- Elastic Topic Message Sending and Receiving
- General References
- Connector
- Database Change Subscription
- FAQs
Multi-Replica and Election Mechanism
Last updated: 2025-04-09 10:10:47
Multi-Replica
The multi-replica design can enhance the availability and reliability of the system.
Replicas are evenly distributed across the entire cluster. The following algorithm is for replicas:
1. Sort all brokers (assuming there are n brokers in total) and unallocated partitions.
2. Assign the i-th Partition to the (i mod n)-th Broker.
3. Assign the j-th Replica of the i-th Partition to the ((i + j) mod n)-th Broker.
Leader Election Election Mechanism
TDMQ for CKafka dynamically maintains an ISR (in-sync replicas) in ZooKeeper. All replicas in the ISR are keeping up with the Leader. Only members in the ISR may be elected as the Leader.
Assume there are f + 1 replicas in ISR, one Partition can ensure that committed messages are not lost.
Tolerate the failure of f Replicas.
Assume there are a total of 2f + 1 Replicas (including Leader and Follower), at least f + 1 must be ensured before commit.
Replica After replicating the message, to ensure that a new Leader is correctly selected, the number of failed Replicas cannot exceed f.
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No