[I] [Feature] Leader-Follower Architecture for Discovery and Engine Components in Multi-Replica Deployment [dubbo-admin]

["thunguo (via GitHub)" <gi...@apache.org>]

thunguo opened a new issue, #1425:
URL: https://github.com/apache/dubbo-admin/issues/1425

   <!-- Please only use this template for submitting feature requests -->
   
   **What would you like to be added**:
   
   Introduce a Leader-Follower (Master-Slave) architecture for the `Discovery` and `Engine` components to ensure data consistency when Admin is deployed with multiple replicas.
   
   Two approaches are proposed (see full design in #1380):
   
   1. **Kubernetes Lease**
      Leverage Kubernetes' native `Lease` mechanism for leader election. This approach is widely adopted by Kubernetes-native applications, but requires the `Engine` component to be of Kubernetes type.
   
   2. **GORM + Database**
      Implement leader election using GORM and database atomicity — e.g., combining `UPDATE ... WHERE` statements with unique constraints or version numbers to simulate a lease mechanism and elect a single Leader. See the detailed solution in [#1380 (comment)](https://github.com/apache/dubbo-admin/discussions/1380#discussioncomment-16034446).
   
   Implementation notes:
   - Leader election should be triggered during the `start` lifecycle phase (not `init`).
   - Only components that require leader election should participate in the election process.
   - Follower nodes must not execute business logic (i.e., `list-watch` and DB writes).
   - When the Leader fails, the remaining Follower nodes must be able to re-elect a new Leader and resume business logic.
   
   **Why is this needed**:
   
   Currently, when Admin is deployed with multiple replicas, each replica independently performs `list-watch` operations and writes data to the DB store. Due to factors such as network latency, this can lead to data inconsistencies across replicas.
   
   By evolving `Discovery` and `Engine` into a Leader-Follower architecture, only one replica actively performs `list-watch` and writes to the store at any given time, eliminating race conditions and ensuring data consistency in multi-replica deployments.
   
   Proposal: #1380


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For additional commands, e-mail: notifications-help@dubbo.apache.org

Re: [I] [Feature] Introduce Leader-Follower Architecture for Discovery and Engine Components in Multi-Replica Deployment [dubbo-admin]

["robocanic (via GitHub)" <gi...@apache.org>]

robocanic closed issue #1425: [Feature] Introduce Leader-Follower Architecture for Discovery and Engine Components in Multi-Replica Deployment
URL: https://github.com/apache/dubbo-admin/issues/1425


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For additional commands, e-mail: notifications-help@dubbo.apache.org