关于监听配置变更的建议

[wolking]

关于监听配置变更的建议

[shima-park]

这样的问题如何处理：可以使用者自己封装一个检查两个map差异的方法，然后根据需要去处理。当然这部分其实也可以给返回的configuration增加一个Different方法

为什么会这么设计：主要是考虑到每个人的使用场景可能不太一样，所以将如何处理的逻辑，放给外部使用者去处理。

参考了谁的设计：例如consul它提供的watch事件通知，也仅仅是将变更后所有的内容推送给使用者，使用者是需要自己保存历史数据，之后也是按照自己的需要比对差异部分做自己的逻辑。

[wolking]

我是觉得大部分使用者只在乎获取变更的内容，不在乎未变更的内容，为了兼容少部分使用者需要历史数据做记录，而放弃大部分使用者的便捷是不值得的，其实他们完全可以在本地维护一份配置，但有配置发生变更时，本地的配置就是历史数据，无需再推送一份未变更的数据。

[shima-park]

并不是为了历史数据而这么做，历史数据只是为了方便而冗余的，抛开历史数据字段不看，完全是参考consul,etcd等类库的标准做法，不会返回差异部分，而是只返回最新的全量数据。

consul
consul将每次更改后的全量数据，通过回调的第二个参数传入。

// HandlerFunc is used to handle new data. It only works for index-based watches
// (which is almost all end points currently) and is kept for backwards
// compatibility until more places can make use of hash-based watches too.
type HandlerFunc func(uint64, interface{})

etcd
我这里的做法跟etcd比较类似,etcd在watch事件后会返回Node(相当于NewValue) PrevNode(相当于OldValue)

type Watcher interface {
	// Next blocks until an etcd event occurs, then returns a Response
	// representing that event. The behavior of Next depends on the
	// WatcherOptions used to construct the Watcher. Next is designed to
	// be called repeatedly, each time blocking until a subsequent event
	// is available.
	//
	// If the provided context is cancelled, Next will return a non-nil
	// error. Any other failures encountered while waiting for the next
	// event (connection issues, deserialization failures, etc) will
	// also result in a non-nil error.
	Next(context.Context) (*Response, error)
}

type Response struct {
	// Action is the name of the operation that occurred. Possible values
	// include get, set, delete, update, create, compareAndSwap,
	// compareAndDelete and expire.
	Action string `json:"action"`

	// Node represents the state of the relevant etcd Node.
	Node *Node `json:"node"`

	// PrevNode represents the previous state of the Node. PrevNode is non-nil
	// only if the Node existed before the action occurred and the action
	// caused a change to the Node.
	PrevNode *Node `json:"prevNode"`

	// Index holds the cluster-level index at the time the Response was generated.
	// This index is not tied to the Node(s) contained in this Response.
	Index uint64 `json:"-"`

	// ClusterID holds the cluster-level ID reported by the server.  This
	// should be different for different etcd clusters.
	ClusterID string `json:"-"`
}

// etcd中的一些测试用例
wantResponse := &Response{
		Action:   "set",
		Node:     &Node{Key: "/pants/foo/bar/baz", Value: "snarf", CreatedIndex: uint64(21), ModifiedIndex: uint64(21)},
		PrevNode: &Node{Key: "/pants/foo/bar/baz", Value: "snazz", CreatedIndex: uint64(19), ModifiedIndex: uint64(20)},
		Index:    uint64(21),
}

wantResponse := &Response{
		Action:   "update",
		Node:     &Node{Key: "/pants/foo/bar/baz", Value: "snarf", CreatedIndex: uint64(19), ModifiedIndex: uint64(21)},
		PrevNode: &Node{Key: "/pants/foo/bar/baz", Value: "snazz", CreatedIndex: uint64(19), ModifiedIndex: uint64(20)},
		Index:    uint64(42),
}

[shima-park]

这部分其实属于语法糖，如果要达到这个效果的话
(1)使用者实现
(2)我找个时间，给Configurations增加方法Different(Configurations) []Change
类似这样：

for _, change := range OldValue.Different(NewValue) {
    switch change.Type{
        case add:
            ...
        case update:
            _, _ = change.Key, change.Value
        case delete:
            ...
    }
}

[wolking]

没错，因为在整个流程中，你是第一个知道哪些是变更的数据，所以我希望能在你这边就做这部分

[mofadeyunduo]

我不觉得应该实现这个变更，比较的逻辑应该由客户端决定，在我这里我就觉得不应是值没变就代表没有变更 @shima-park

[shima-park]

哈哈,是啊,我想法是参考跟consul,etcd类似的处理方式.由使用者去处理比较逻辑.
有同学提就加下算了.