GitHub user andrewseif added a comment to the discussion: GSoC: Support Seata Multi Raft
This is going to be a check list of what is missing to achieve a full multi raft functionality. - [ ] 1.Build and manage the CG, as well as construct the TXG. - [ ] 1.1Build the CG RaftControllerServer, RaftControllerStateMachine, and RaftControllerServerManager - [ ] 1.2 Initialize the TXG - [ ] 1.3 Design the metadata storage structure for CG, and create communication DTOs for data synchronization between clusters, as well as APIs for scaling in and out - [ ] 1.4 Build CG SNAPSHOT to save snapshots of metadata (TXGs) at specific points in time - [ ] 1.5 Add an interface to query TXG members - [ ] 1.6 Refactor the TXG startup process to obtain the current node’s TXG metadata from CG nodes and complete the TXG startup - [ ] 1.7 Refactor the TXG state machine so that after TXG starts, it reports its metadata to the CG leader instead of the TXG leader - [ ] 2.Develop a cgLockManager to handle global locks within the cluster. - [ ] 2.1 Design the cgLockManager interface, communication method, DTO, and Result objects. - [ ] 2.2 Implement cgLockManager and Locker. - [ ] 2.3 Refactor RaftLockManager on the TXG side into two strategy modes: when a controller group exists, acquire and release locks through the cg; when not, use the old logic for backward compatibility. - [ ] 2.4 Extend GlobalLockFileServiceImpl to implement GlobalLockRaftServiceImpl. Understand the composition of lockKey, and convert branchSession#lockKey into RowLock. Refer to the filterAndMap method in GlobalLockFileServiceImpl (this can be implemented after the project is completed, as it is only used for console queries). - [ ] 3. Use the CG for service discovery, and leverage TXG for load balancing to select a specific TXG for initiating the transaction process. - [ ] 3.1 Add CG address configuration and reading in RaftRegistryServiceImpl. - [ ] 3.2 Add new watch and cluster interfaces to ClusterController for retrieving TXGs and monitoring changes to the corresponding TXGs. - [ ] 3.3 Obtain and cache metadata for all TXGs through the CG. - [ ] 3.4 When the CG side receives leader changes from the TXG side (which is why TXG must first push its changes to the CG), respond to watch requests from clients so that clients can fetch and cache the metadata for the relevant group again. - [ ] 4.Pass the TXG identifier downstream so that the branch’s phase-one requests are also directed to the same TXG. - [ ] 4.1 Add TXG identifier in RootContext to enable reading the TXG to which the current transaction belongs. - [ ] 4.2 Enhance various rpc components in the integration module to support passing the TXG identifier. - [ ] 4.3 Build TXG-based load balancing in seata-discovery-core, and query the leader based on TXG. GitHub link: https://github.com/apache/incubator-seata/discussions/7404#discussioncomment-14216452 ---- This is an automatically sent email for dev@seata.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@seata.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@seata.apache.org For additional commands, e-mail: dev-h...@seata.apache.org
