Gossip 1.1
gossip 节点的内部表如何存储?

map:

  • gossip 节点名称 : 版本号, 消息set

gossip 协议并不能完全确保key是唯一的,因为消息可能是有延迟的; 所以这里要在入库的时候想办法对key进行去重,这里因为先在对应的worker上创建服务, 所以可以使得内部的 Key 为 service+(manager), 对外部还是表现为service。这样就可以实现过滤。

本质上,这个gossip node 所维护的是一个写入多,读取少的情景。

延迟删除是为了解决一个结点重复上下线的问题

协议

目前来看,只有 heartbeat 与 search 操作是需要回调的

如果在发送消息前,把节点的版本号更改会发生什么呢?

全slot更新与部分slot更新的区别:全slot更新的收敛速度会更快,因为部分 Slot 会出现后一条消息到达,但是前面一条消息未到达的区别。 相比之下,全slot更新对系统的带宽消耗更大,而部分slot更新则要求每个message都存储版本号,并且还要采用标记删除机制,因此内存开销更大

gossip 协议的大部分本质上只是将本地存储的数据库加入了一层分布式搜索算法,或者允许使用过期数据的情况。

  • handlePullRequest 和 heartbeat 的区别? handlePullRequest 是一个比较耗费带宽的操作,如果 handlePullRequest 操作失败的话,网络带宽的代价是比较大的,因为可以使用heartbeat来更新版本
  • 因为 gossip 网络之间的传输可能存在延迟,所以需要将节点标记为下线,然后一段时间之后再进行删除

还没有做完的

  • 查询目前只允许查本地的 slot 内容
  • 错误处理的原因还没有返回
  • 可以把持续传输的调用,例如心跳包等设置为流式传输
  • slot 需要变成乐观并发控制,因为这本质上是一个多写少读的场景