awesome-fenix
awesome-fenix copied to clipboard
fenixsoft
「Comment」https://icyfenix.cn/distribution/consensus/gossip.html
“每一个节点收到消息后，如果这个消息是它之前没有收到过的”。
周大哥，判断消息是否收到过，如果是框架统一处理，是不是得记录已处理过消息的标识，或者消息标识是有规律的，可以从某个消息确定已处理过消息的范围？ 我考虑第二种是不可行，那就是需要记录处理过消息的标识。已处理过的消息会越来越多，而节点不能确定哪些消息是全网接收过的，无法做出清理，这样这些数据就会无限堆积，这个问题怎么处理呢？
我还想到另外一种可能性，消息是否处理过，不是通过消息的标识来判断，而是识别消息的内容，跟节点已有的数据去比较。能识别消息内容的话，那就是要绑定具体业务，业务去识别。
周大哥，请问是哪一种呢？我觉得是绑定具体业务的可能性更大。
@dengchaoh “每一个节点收到消息后，如果这个消息是它之前没有收到过的”。
周大哥，判断消息是否收到过，如果是框架统一处理，是不是得记录已处理过消息的标识，或者消息标识是有规律的，可以从某个消息确定已处理过消息的范围？ 我考虑第二种是不可行，那就是需要记录处理过消息的标识。已处理过的消息会越来越多，而节点不能确定哪些消息是全网接收过的，无法做出清理，这样这些数据就会无限堆积，这个问题怎么处理呢？
我还想到另外一种可能性，消息是否处理过，不是通过消息的标识来判断，而是识别消息的内容，跟节点已有的数据去比较。能识别消息内容的话，那就是要绑定具体业务，业务去识别。
周大哥，请问是哪一种呢？我觉得是绑定具体业务的可能性更大。
这个问题是与具体实现相关的，但是一般是不需要一直存储着收到过的消息的，对于每一个节点来说，只要该消息是来源于或发送至这个节点所有的相邻节点之后，它就可以安全丢弃了——因为所有相邻节点都知道了这条消息，而且它们还知道你已经知道了这条消息。
所以，消息存储消耗取决于相邻节点的数量，而一个节点的相邻节点数量是有限的，因此一般消息不会造成太大负担。从实现上看，绝大多数Gossip Agent都不需要一个专门的数据库来支持运作，将消息hold在内存中即可，这点也从侧面说明了消息的存储压力并不大。
@leaosunday “尽管系统内部节点可以存在不一致的状态，但从系统外部看来，不一致的情况并不会被观察到”想问一下为什么内部存在不一致，外部观察会是一致呢？
因为只会给外部达成一致的内容，外部提交也需要内部达成一次才算成功，所以是强一致的
最终一致：内部不一致的情况可能被外部感知；CDN。
Gossip 流行病算法:
- 简单
- 随机性，全网统一的时间难以精准计算
- 随机性可能重复发送给同一节点，消息冗余
- 反墒 VS 传谣
周老师，求问：假设在网络中，节点A设置x值为y，并开始向其他节点进行瘟疫传播。此时另外一个未感染的节点B设置x值为z，也对外进行传播，那么最终在网络上的节点保存的x的值是什么呢？这个是怎么确认以什么消息为准的呢
