[New] Metadata Desgin（etcd）

[joey0612]

Metadata Classification

During the operation of kvrocks cluster, the following four types of metadata are more important and need to be stored in etcd cluster, so that when the controller switches between leader and follower, the new leader load metadata from etcd can continue to run.

1. cluster topu: topology information of the cluster(shards, slotrangs, nodes etc.).
2. migrate info: related to metadata of migration(source node, target node, migrate slotranges etc.).
3. failover info: related to metadata of failover(node, noderole etc.).
4. config info: including the configuration of namespace, cluster, migrate, and failover etc.

Memory and Remote Consistency

The difficulty of the etcd + controller architecture is that the inconsistency between the controller memory data and the remote etcd persistent data. It causes the leader-follower switch of the controller to have a great impact on the availability of the cluster. The update of metadata mainly comes from the following two aspects:

1. Devops operation need to update metadata, such as cluster initialization, cluster expansion and contraction, and manual failover of specified nodes, etc. First update the metadata before operating the cluster.
2. The leader controller initiated by internal logic, such as auto failover, migrate slot, etc. need to operate the cluster first and then update the metadata.

For the first case above, you can force all operations that need to update metadata to be sent to the leader controller. After the leader controller receives the request, it will first verify it according to the local memory data. After the verification is passed, the remote etcd will be updated, and after the update success, update the local memory of the leader controller (after verification, the memory update must be successful by default).

For the second case above, in order to ensure the availability of the cluster, first update the memory and then synchronize to the full cluster nodes, and then update etcd. If the update etcd fails, the background goroutine will periodically pull etcd storage until success, by compare cluster version guarante correct. If a leader-follower switch during this period, the new leader first collect the cluster information on the node and perform integrity verification, then compare it with the metadata inside etcd, and update etcd based on the collected node information.

Metadata Organization

Metadata in Etcd

/*
 * etcd data format desgin principle: 
 * 1. continuous storage among cluster data(topo and meta) under the same namespace
 * 2. minimize multiple etcd accesses for one upper-layer operation
 *
 * namespace format:
 *    `/namespace/${ns}:${ns}`
 *    all namespace name has the same prefix `/namespace/`, convenient for list namespace
 *
 *  cluster topo format:
 *    `/${ns}/cluster/${cl}:${Clsuter-json}` 	
 *    all clusters(topo and meta) hava the same prefix /${ns}/
 *    all clusters topo data hava the same prefix /${ns}/cluster/
 *
 * migrate metedata format:
 *    `/${ns}/${cl}/migrate/tasks/${timestamp}_${sub_id}:${MigrateTask-json}`
 *    `/${ns}/${cl}/migrate/doing:${MigrateTask-json}`
 *    `/${ns}/${cl}/migrate/history/${timestamp}_${sub_id}:${MigrateTask-json}`
 *    all migrate metedata under specified cluster hava the same prefix /${ns}/${cl}/migrate/
 *
 * failover metedata format:
 *    `/${ns}/${cl}/failover/tasks/${nodeid}:${timestamp}`
 *    `/${ns}/${cl}/failover/doing:${FiloverTask-json}`
 *    `/${ns}/${cl}/failover/history/${timestamp}_${nodeid}:${FiloverTask-json}`
 *    all failover metedata under specified cluster hava the same prefix /${ns}/${cl}/failover/
 */

Metadata logic organize

${var} 表示变量，${var...} 表示相同类型变量多个，‘:’ 之后表示结构的 json 格式

/*
 * /namespace/${ns_name}
 *    /${ns_name}/cluster/${clsuter_name}: ${Clsuter-json}
 *    /${ns_name}/${clsuter_name}/migrate
 *                                       /tasks
 *                                             /${timestamp}_${sub_id...}:${MigrateTask-json}
 *                                       /doing:${MigrateTask-json}
 *                                       /history
 *                                              /${timestamp}_${sub_id...}:${MigrateTask-json}
 *    /${ns_name}/${clsuter_name}/failover
 *                                       /tasks
 *                                             /${nodeid...}:${timestamp}
 *                                       /doing:${FiloverTask-json}`
 *                                       /history
 *                                               /${timestamp}_${nodeid}:${FiloverTask-json}
 *     /${ns_name}/cluster/${clsuter_name...}: ${Clsuter-json}
 * /namespace/${ns_name...}
 */

Cluster Metadata

/* 
 * /namespace/${ns_name}
 *    /${ns_name}/cluster/${clsuter_name}: ${Clsuter-json}
 */

type ClusterConfig struct {
  Name              string `json:"name"`
  HeartBeatInterval uint64 `json:"heartbeatinterval"`
  HeartBeatRetrys   uint64 `json:"heartbeatretrys"`
  
  // Global migration configuration information, the configuration information inside MigrateTask will cover the configuration 
  // information of the cluster, so that the task granularity can be adjusted
  MigrateMeta  MigrateConfig{}   // TODO: migrate  submodel

  // Global Failover configuration information, the configuration information inside MigrateTask will cover the configuration 
  // information of the cluster, so that the task granularity can be adjusted
  FailoverMeta FailoverConfig{}   // TODO: failover submodel
}

type Cluster struct {
   Version int64          `json:"version"`
   Shards  []Shard        `json:"shards"`
   Config  ClusterConfig  `json:"config"`
}

Migrate Metadata

/* 
 *    /${ns_name}/${clsuter_name}/migrate
 *                                       /tasks
 *                                             /${timestamp}_${sub_id...}:${MigrateTask-json}
 *                                       /doing:${MigrateTask-json}
 *                                       /history
 *                                              /${timestamp}_${sub_id...}:${MigrateTask-json}
 *
 * migrate_${timestamp}_${sub_id} one expansion may involve multiple relocation tasks (different nodes, different slots)
 * they have the same timestamp, distinguished by sub_id
 */
type MigrateTask struct {
   Source      string    // soucre nodeid
   Target      string    // target nodeid
   MigrateSlot SlotRange // migrate slots

   // statistics
   CreateTime  uint64    
   DoingTime   uint64    
   DoneTime    uint64    

   Status        int     // init,doing,success/failed
   Err           error   // if failed, Err is not nil
   MigrateMeta   MigrateConfig
}

type MigrateConfig struct {
	ConcurrencyNodes  int // max migrate task among nodes
         ConcurrencySlots  int // mas migrate slots between Source and Target
}

Failover MetaTask

/*
 *    /${ns_name}/${clsuter_name}/failover
 *                                       /tasks
 *                                             /${nodeid...}:${timestamp}
 *                                       /doing:${FiloverTask-json}`
 *                                       /history
 *                                               /${timestamp}_${nodeid}:${FiloverTask-json}
 *
 * failover_${nodeid}, there is only one failover task inside a node and failover queue
 */

type FailoverTask struct {
   Source  string // fault node id
   Target  string // if Source is master，new master nodeid
   Role    string // node role
   // auto or manual, if manual failover will probe Source healthy
   // enforce Target promote new master
   Type    int    // auto or manual
   
   // statistics
   CreateTime  uint64    
   DoingTime   uint64    
   DoneTime    uint64    

   Status        int     // init,doing,success/failed
   Err           error   // if failed, Err is not nil
   FailoverMeta  FailoverConfig
}

type FailoverConfig struct {
   FailoverTimeout uint64
   FailoverRetrys  int    // after retrys, task failed

   // failoverNodes > clusterNodes * FailoverRaito / 10, enter SafeMode
   // FailoverRaito between 0-10
   FailoverRaito   int 
}

[git-hulk]

@joeylichang 整体我觉得挺棒的，你这边有兴趣来尝试实现吗？

[joey0612]

ok～

[LykxSassinator]

Metadata Classification

kvrocks cluster 运行期间，有如下四类 metadata 比较重要需要存储在 etcd cluster 内部，便于 controller 发生主从切换时，新主从 etcd load metadata 继续运行。

1. cluster topu: 集群的拓扑信息。
2. migrate info：数据搬迁 or 集群扩所容相关数据。
3. failover info：节点 failover 相关数据。
4. config info：配置信息，包括namespace，cluster，migrate，failover 等维度的配置信息。

Memory and Remote Consistency

etcd + controller 架构的难点是 controller 内存数据与远程 etcd 持久化的数据不一致导致 controller 发生主从切换对集群的可用性影响较大。metadata 的更新主要来自一下两个方面：

1. 运维相关操作需要更新元数据，例如：集群初始化，集群扩缩容，指定节点 manual failover等先更新元数据再对集群进行操作。
2. 主 Controller 发起的更新元数据操作，例如：auto failover，migrate slot等需要先对集群操作再更新元数据。

针对上述第一种情况，可以强制所有需要更新元数据的运维操作发送给主 controller，主 controller 收到请求后先根据本地内存数据进行校验，校验通过后更新远程 etcd ，更新成功之后再更新主 controller 本地内存（经过校验之后，默认更新内存一定成功）。

针对上述第二种情况，为了保证集群的可用性先更新内存然后向全集群节点进行同步，之后更新 etcd，如果更新 etcd 失败，会启动后台协程周期性的拉取 etcd 信息进行比对，以主 controller 为准更新etcd，直到更新成功为止。如果 controller 在此期间发生了主从切换，先收集节点上的集群信息并进行完整性校验，然后与 etcd 内部的 metadata 进行比对，以收集的节点信息为准更新 etcd。

Metadata Organization

‘｜-’ 表示目录结构，${var} 表示变量，${var...} 表示相同类型变量多个，‘:’ 之后表示结构的 json 格式

/* etcd metadata organization
 * |-${namespace_name}: NameSpaceConfig
 *    |-${clsuter_name}: ClusterConfig
 *       |-cluster_topu: Cluster
 *       |-migrate
 *           |-migrate_task 
 *               |-migrate_${timestamp}_${sub_id}: MigrateTask
 *               |-migrate_${timestamp}_${sub_id...}: MigrateTask
 *           |-migrate_doing 
 *               |-migrate_${timestamp}_${sub_id}: MigrateTask
 *                  |-migrate_slot: slot_doing
 *           |-migrate_done
 *               |-migrate_${timestamp}_${sub_id}: MigrateTask
 *               |-migrate_${timestamp}_${.sub_id..}: MigrateTask
 *       |-failover
 *           |-failover_task
 *                |-failover_${nodeid}
 *                |-failover_${...}
 *           |-failover_doing:FailoverTask
 *           |-failover_done
 *                |-failover_${timestamp}_${nodeid}: FailoverTask
 *                |-failover_${timestamp}_${nodeid...}: FailoverTask
 *    |-${clsuter...}: ClusterConfig 
 * |-${namespace...}: NameSpaceConfig
 */

Cluster Metadata

/* 
 * |-${namespace_name}: NameSpaceConfig
 *    |-${clsuter_name}: ClusterConfig
 *       |-cluster_topu: Cluster
 */

type NameSpaceConfig struct {
  Name        string
}

type ClusterConfig struct {
  Name   string
  // heartbeat interval
  HeartBeatInterval    uint64 
  // after retrys of heartbeat fail,judgment node failed
  HeartBeatRetrys      uint64
  
  //全局的搬迁配置信息，MigrateTask 内部的配置信息会覆盖集群的配置信息，做到任务粒度调整
  MigrateMeta   MigrateConfig
  //全局的Failover配置信息，MigrateTask 内部的配置信息会覆盖集群的配置信息，做到任务粒度调整
	FailoverMeta  FailoverConfig
}

type Cluster struct {
	Version int64   `json:"version"`
	Shards  []Shard `json:"shards"`
}

Migrate Metadata

/* 
 *           |-migrate_task 
 *               |-migrate_${timestamp}_${sub_id}: MigrateTask
 *               |-migrate_${timestamp}_&{...}: MigrateTask
 *           |-migrate_doing 
 *               |-migrate_${timestamp}_${sub_id}: MigrateTask
 *                  |-migrate_slot: slot_doing
 *           |-migrate_done
 *               |-migrate_${timestamp}_${sub_id}: MigrateTask
 *               |-migrate_${timestamp}_&{...}: MigrateTask
 *
 * migrate_${timestamp}_${sub_id} 一次扩所容可能涉及多个搬迁任务（不同的节点，不同的slot）
 * 它们有相同的 timestamp，根据 sub_id 进行区分
 */
type MigrateTask struct {
	Source      string    // soucre nodeid
  Target      string    // target nodeid
  MigrateSlot SlotRange // migrate slots

  // statistics
	CreateTime  uint64    
  DoingTime   uint64    
  DoneTime    uint64    

  Status        int     // init,doing,success/failed
  Err           error   // if failed, Err is not nil
  MigrateMeta   MigrateConfig
}

type MigrateConfig struct {
	ConcurrencyNodes  int // max migrate task among nodes
  ConcurrencySlots  int // mas migrate slots between Source and Target
}

Failover MetaTask

/*
 *       |-failover: isSafetyMode
 *           |-failover_task
 *                |-failover_${nodeid}
 *                |-failover_${...}
 *           |-failover_doing:FailoverTask
 *           |-failover_done
 *                |-failover_${timestamp}_${nodeid}: FailoverTask
 *                |-failover_${timestamp}_${...}: FailoverTask
 *
 * isSafetyMode 如果为 true ，禁止进行 failover，集群处于安全模式
 * failover_${nodeid}，一个 node 再 failover 队列内部只有一个 failover 任务
 */

type FailoverTask struct {
	 Source  string // fault node id
   Target  string // if Source is master，new master nodeid
   Role    string // node role
   // auto or manual, if manual failover will probe Source healthy
   // enforce Target promote new master
   Type    int    // auto or manual
   
   // statistics
   CreateTime  uint64    
   DoingTime   uint64    
   DoneTime    uint64    

   Status        int     // init,doing,success/failed
   Err           error   // if failed, Err is not nil
   FailoverMeta  FailoverConfig
}

type FailoverConfig struct {
   FailoverTimeout uint64
   FailoverRetrys  int    // after retrys, task failed

   // failoverNodes > clusterNodes * FailoverRaito / 10, enter SafeMode
   // FailoverRaito between 0-10
   FailoverRaito   int 
}

这里，想请教下：

1. Controller之间（Leader和Follower）也需要做Metadata同步么？这里，我理解既然引入了ETCD做Metadata的持久化，而Controller是否就已经是个无状态的Metadata缓存Node了？那第二点说到的向全集群节点同步的意思是？
2. Controller以Metadata缓存存在的情况下，是否可以将Controller 的Leader的信息缓存于ETCD中，由最先Watch到Leader信息的Controller Node成为主？这样是否更简单？Failover的置换上由于Watch的特性，可以保证全节点Controller监听到该Update操作后直接做内存状态变更。
3. 基于Controller本身无状态的情况下，所有Controller是都采用Watch的方式来从ETCD更新Metadata的么？如果这样的话，是否可以将Metadata的Write（包括Add/Delete/Update）操作Redirect至Leader Controller？而Read操作则可由Follower Controller完成？这样，Controller的角色和职责可以更轻量？
4. 而关于第二种情况下的ETCD同步顺序这里，Leader Controller拥有唯一对于ETCD的Write权限，那它的行为就可以变成”更新ETCD -> 更新内存状态 -> Follower在ETCD更新的条件下自动同步Metadata“，这样的话，缓存一致性同样可以保证？这样是否操作更简单？

[joey0612]

Metadata Classification

kvrocks cluster 运行期间，有如下四类 metadata 比较重要需要存储在 etcd cluster 内部，便于 controller 发生主从切换时，新主从 etcd load metadata 继续运行。

1. cluster topu: 集群的拓扑信息。
2. migrate info：数据搬迁 or 集群扩所容相关数据。
3. failover info：节点 failover 相关数据。
4. config info：配置信息，包括namespace，cluster，migrate，failover 等维度的配置信息。

Memory and Remote Consistency

etcd + controller 架构的难点是 controller 内存数据与远程 etcd 持久化的数据不一致导致 controller 发生主从切换对集群的可用性影响较大。metadata 的更新主要来自一下两个方面：

1. 运维相关操作需要更新元数据，例如：集群初始化，集群扩缩容，指定节点 manual failover等先更新元数据再对集群进行操作。
2. 主 Controller 发起的更新元数据操作，例如：auto failover，migrate slot等需要先对集群操作再更新元数据。

针对上述第一种情况，可以强制所有需要更新元数据的运维操作发送给主 controller，主 controller 收到请求后先根据本地内存数据进行校验，校验通过后更新远程 etcd ，更新成功之后再更新主 controller 本地内存（经过校验之后，默认更新内存一定成功）。
针对上述第二种情况，为了保证集群的可用性先更新内存然后向全集群节点进行同步，之后更新 etcd，如果更新 etcd 失败，会启动后台协程周期性的拉取 etcd 信息进行比对，以主 controller 为准更新etcd，直到更新成功为止。如果 controller 在此期间发生了主从切换，先收集节点上的集群信息并进行完整性校验，然后与 etcd 内部的 metadata 进行比对，以收集的节点信息为准更新 etcd。

Metadata Organization

‘｜-’ 表示目录结构，${var} 表示变量，${var...} 表示相同类型变量多个，‘:’ 之后表示结构的 json 格式

/* etcd metadata organization
 * |-${namespace_name}: NameSpaceConfig
 *    |-${clsuter_name}: ClusterConfig
 *       |-cluster_topu: Cluster
 *       |-migrate
 *           |-migrate_task 
 *               |-migrate_${timestamp}_${sub_id}: MigrateTask
 *               |-migrate_${timestamp}_${sub_id...}: MigrateTask
 *           |-migrate_doing 
 *               |-migrate_${timestamp}_${sub_id}: MigrateTask
 *                  |-migrate_slot: slot_doing
 *           |-migrate_done
 *               |-migrate_${timestamp}_${sub_id}: MigrateTask
 *               |-migrate_${timestamp}_${.sub_id..}: MigrateTask
 *       |-failover
 *           |-failover_task
 *                |-failover_${nodeid}
 *                |-failover_${...}
 *           |-failover_doing:FailoverTask
 *           |-failover_done
 *                |-failover_${timestamp}_${nodeid}: FailoverTask
 *                |-failover_${timestamp}_${nodeid...}: FailoverTask
 *    |-${clsuter...}: ClusterConfig 
 * |-${namespace...}: NameSpaceConfig
 */

Cluster Metadata

/* 
 * |-${namespace_name}: NameSpaceConfig
 *    |-${clsuter_name}: ClusterConfig
 *       |-cluster_topu: Cluster
 */

type NameSpaceConfig struct {
  Name        string
}

type ClusterConfig struct {
  Name   string
  // heartbeat interval
  HeartBeatInterval    uint64 
  // after retrys of heartbeat fail,judgment node failed
  HeartBeatRetrys      uint64
  
  //全局的搬迁配置信息，MigrateTask 内部的配置信息会覆盖集群的配置信息，做到任务粒度调整
  MigrateMeta   MigrateConfig
  //全局的Failover配置信息，MigrateTask 内部的配置信息会覆盖集群的配置信息，做到任务粒度调整
	FailoverMeta  FailoverConfig
}

type Cluster struct {
	Version int64   `json:"version"`
	Shards  []Shard `json:"shards"`
}

Migrate Metadata

/* 
 *           |-migrate_task 
 *               |-migrate_${timestamp}_${sub_id}: MigrateTask
 *               |-migrate_${timestamp}_&{...}: MigrateTask
 *           |-migrate_doing 
 *               |-migrate_${timestamp}_${sub_id}: MigrateTask
 *                  |-migrate_slot: slot_doing
 *           |-migrate_done
 *               |-migrate_${timestamp}_${sub_id}: MigrateTask
 *               |-migrate_${timestamp}_&{...}: MigrateTask
 *
 * migrate_${timestamp}_${sub_id} 一次扩所容可能涉及多个搬迁任务（不同的节点，不同的slot）
 * 它们有相同的 timestamp，根据 sub_id 进行区分
 */
type MigrateTask struct {
	Source      string    // soucre nodeid
  Target      string    // target nodeid
  MigrateSlot SlotRange // migrate slots

  // statistics
	CreateTime  uint64    
  DoingTime   uint64    
  DoneTime    uint64    

  Status        int     // init,doing,success/failed
  Err           error   // if failed, Err is not nil
  MigrateMeta   MigrateConfig
}

type MigrateConfig struct {
	ConcurrencyNodes  int // max migrate task among nodes
  ConcurrencySlots  int // mas migrate slots between Source and Target
}

Failover MetaTask

/*
 *       |-failover: isSafetyMode
 *           |-failover_task
 *                |-failover_${nodeid}
 *                |-failover_${...}
 *           |-failover_doing:FailoverTask
 *           |-failover_done
 *                |-failover_${timestamp}_${nodeid}: FailoverTask
 *                |-failover_${timestamp}_${...}: FailoverTask
 *
 * isSafetyMode 如果为 true ，禁止进行 failover，集群处于安全模式
 * failover_${nodeid}，一个 node 再 failover 队列内部只有一个 failover 任务
 */

type FailoverTask struct {
	 Source  string // fault node id
   Target  string // if Source is master，new master nodeid
   Role    string // node role
   // auto or manual, if manual failover will probe Source healthy
   // enforce Target promote new master
   Type    int    // auto or manual
   
   // statistics
   CreateTime  uint64    
   DoingTime   uint64    
   DoneTime    uint64    

   Status        int     // init,doing,success/failed
   Err           error   // if failed, Err is not nil
   FailoverMeta  FailoverConfig
}

type FailoverConfig struct {
   FailoverTimeout uint64
   FailoverRetrys  int    // after retrys, task failed

   // failoverNodes > clusterNodes * FailoverRaito / 10, enter SafeMode
   // FailoverRaito between 0-10
   FailoverRaito   int 
}

这里，想请教下：

1. Controller之间（Leader和Follower）也需要做Metadata同步么？这里，我理解既然引入了ETCD做Metadata的持久化，而Controller是否就已经是个无状态的Metadata缓存Node了？那第二点说到的向全集群节点同步的意思是？
2. Controller以Metadata缓存存在的情况下，是否可以将Controller 的Leader的信息缓存于ETCD中，由最先Watch到Leader信息的Controller Node成为主？这样是否更简单？Failover的置换上由于Watch的特性，可以保证全节点Controller监听到该Update操作后直接做内存状态变更。
3. 基于Controller本身无状态的情况下，所有Controller是都采用Watch的方式来从ETCD更新Metadata的么？如果这样的话，是否可以将Metadata的Write（包括Add/Delete/Update）操作Redirect至Leader Controller？而Read操作则可由Follower Controller完成？这样，Controller的角色和职责可以更轻量？
4. 而关于第二种情况下的ETCD同步顺序这里，Leader Controller拥有唯一对于ETCD的Write权限，那它的行为就可以变成”更新ETCD -> 更新内存状态 -> Follower在ETCD更新的条件下自动同步Metadata“，这样的话，缓存一致性同样可以保证？这样是否操作更简单？

1.1 leader 和 follower 之间不需要同步，如果进行了同步（强一直协议）则不需要 etcd cluster（raft），引入 etcd 的目的之一正是将强一致协议的复杂度转移到 etcd，如果controller 引入强一直协议（比如 raft）开发和稳定的周期可能会比较长，controller + etcd 架构使 controller 更轻量级。
另外，follower 可以 watcher etcd 的变更，实时更新内存的 metadata 用于响应查询请求，如果 controller 没有性能瓶颈可以延缓这部分的实现。
1.2 controller 是一个有状态的服务，因为发起集群的运维操作必须是单点（比如，同一个节点的 failover 如果同时有两个 controller 发起是不行的），所以 controller 需要区分 leader 和 follower，follower 只是 leader 的 HA 设计。
1.3 ‘向全集群节点’ 是指当集群的拓扑信息发生变化，例如：发生了 migrate slot ，只有 source 和 target 知道了变更，但是其他节点并不知道，需要 controller 向全集群同步。

2.1 问题2不是很理解，尝试着回答一下。etcd 的更新都是通过 controller 完成的，如果直接更新 etcd ，所有的 controller watch data，理论上没有什么问题，但是尽量少的使用 watch 因为网络等问题 watch 会有延迟（etcd 保证可靠 watch 但是无法保证时效性），如果发生了主从切换，新主的数据可能不是最新。
2.2 leader controller 与 etcd 之间的关系可以认为 etcd 是 controller 的可靠远程备份，理论上二者数据实时一致，发生主从切换可以 load 数据直接运行。缓存是允许一定的数据不一致。当然由于二者之间存在网络，是做不到实时一致，这部分可以在设计和实现上做一些弥补和取舍，对用户透明。

3.在第一个问题中有解释
4.针对第二种情况，又分两类情况（以下各举一例）：
1.auto failover：controller 通过心跳发现了节点故障然后发起的自动 failover，此时可以先更新 etcd 再继续failover操作，但是考虑集群的高可用（如果主 master node 故障此时无法写），优先执行 failover 之后更新 etcd，尽快恢复集群的可用性。
2.migrate slot：slot 搬迁完成之后 source 和 target 上的slot 信息已经更新，此时内存不更新则无法向全集群同步（1.3所述），如果更新 etcd 可能失败或者网络不稳定的时候更新 etcd 可能耗时较长，等情况也会影响集群的可用性。

[LykxSassinator]

嗯额，对于你的设计我是认同的，同意上面你所说的，而我的问题是基于不同的实现的视角提出的，核心点就是：

1. 对于你说的controller向集群同步这个点上。我最开始的疑问也是这个，不太理解这个同步的意思是指说让controller中的follower通过ETCD watch自动获取还是说由Controller之间的rpc进行通信同步。我的疑问也就是基于此说的，即是否直接借助于watch来保证metadata的一致性；
2. 对于你说的保证Controller的高可用这一点上，我理解可能是实现的侧重不同？我提出的观点说先同步写etcd -> 更新Controller内存的核心也是基于Metadata强一致的角度来考虑的；
3. 对于ETCD的Watch的性能问题这一点上，就我们内部之前可参考的实践经验来说，ETCD的V3版本之后的Watch能力其实能够保证我们集群的扩缩容/Failover信息的正常监听（其实k8s的调度不也是这么做嘛？）。所以既然使用Watch的前提下，是否Follower的Metadata的同步与更新可直接依赖于Watch实现呢？我上一个Comment也是基于此提出的。

[LykxSassinator]

嗯额，对于你的设计我是认同的，同意上面你所说的，而我的问题是基于不同的实现的视角提出的，核心点就是：

1. 对于你说的controller向集群同步这个点上。我最开始的疑问也是这个，不太理解这个同步的意思是指说让controller中的follower通过ETCD watch自动获取还是说由Controller之间的rpc进行通信同步。我的疑问也就是基于此说的，即是否直接借助于watch来保证metadata的一致性；
2. 对于你说的保证Controller的高可用这一点上，我理解可能是实现的侧重不同？我提出的观点说先同步写etcd -> 更新Controller内存的核心也是基于Metadata强一致的角度来考虑的；
3. 对于ETCD的Watch的性能问题这一点上，就我们内部之前可参考的实践经验来说，ETCD的V3版本之后的Watch能力其实能够保证我们集群的扩缩容/Failover信息的正常监听（其实k8s的调度不也是这么做嘛？）。所以既然使用Watch的前提下，是否Follower的Metadata的同步与更新可直接依赖于Watch实现呢？我上一个Comment也是基于此提出的。

Sorry，因为上面的Comment太长了，所以这里单独起了一个新的，我的问题仅仅是讨论下实现上的一些疑问。

[joey0612]

嗯额，对于你的设计我是认同的，同意上面你所说的，而我的问题是基于不同的实现的视角提出的，核心点就是：

1. 对于你说的controller向集群同步这个点上。我最开始的疑问也是这个，不太理解这个同步的意思是指说让controller中的follower通过ETCD watch自动获取还是说由Controller之间的rpc进行通信同步。我的疑问也就是基于此说的，即是否直接借助于watch来保证metadata的一致性；
2. 对于你说的保证Controller的高可用这一点上，我理解可能是实现的侧重不同？我提出的观点说先同步写etcd -> 更新Controller内存的核心也是基于Metadata强一致的角度来考虑的；
3. 对于ETCD的Watch的性能问题这一点上，就我们内部之前可参考的实践经验来说，ETCD的V3版本之后的Watch能力其实能够保证我们集群的扩缩容/Failover信息的正常监听（其实k8s的调度不也是这么做嘛？）。所以既然使用Watch的前提下，是否Follower的Metadata的同步与更新可直接依赖于Watch实现呢？我上一个Comment也是基于此提出的。

Sorry，因为上面的Comment太长了，所以这里单独起了一个新的，我的问题仅仅是讨论下实现上的一些疑问。

1. controller 向全集群同步，指的是向 kvrocks 集群同步，follower-controller 没有数据（后面可以 watch etcd 向外提供读请求）
2. 不是所有的场景先写 etcd 在更新 内存都是可以的，上面举国例子了
3. follower-controller watch 到变更也不会提供 write 和 update 类型操作，如果只是提供 read 操作，watch 是没有问题的（我想表达的是，前期这部分可以先不做，如果请求到 follower ，会 routing 到 leader，这样开发周期短一点）。

slack joey 可以联系到我，我们可以详细的展开讨论 ：）