技术圈的“绯闻女孩”:Gossip是如何把八卦秘密传遍全网的?

ESP-IDF的安装及其在VScode中编译环境的搭建 从安装目录的\Espressif\frameworks\esp-idf-v5.3.2\examples路径中拷贝一个工程到项目中,比如拷贝\get-started下的hello_world文件夹。安装时可能会遇到如下问题,提示:"e:\ssc\software\ESP-IDF\v5.3.2\Espressif\tools\idf-python\3.11.2\python.exe -m pip" is not valid. (ERROR_INVALID_PIP)接着等待安装完成即可,其他步骤同方式1。 阅读详情

Gossip协议,中文可译为“流言蜚语”“闲话”或“八卦”,形象地描述了该协议的工作方式——类似于人类社会中的信息传播模式。Gossip协议最早由Xerox公司的Palo Alto研究中心(PARC)在一篇论文中提出,论文中将其称为八卦算法或病毒算法(Epidemic Algorithm),但最终“Gossip”这一名称被接受并沿用至今。
Gossip协议是一种去中心化的分布式协议,旨在实现多个节点之间的状态信息共享。其核心思想是通过随机选择节点进行信息交换,逐步将状态数据传播到整个系统。
在分布式系统中,元数据(Metadata)是描述系统状态的关键信息,例如节点负责的数据范围、主从关系、节点健康状态(是否故障)等。Gossip协议通过周期性的、轻量级的通信机制,确保这些元数据能够在节点间高效、可靠地同步。

Gossip 的基本工作模式
1)周期性活动: 每个节点定期(例如每秒)启动一轮Gossip。
2)随机对等选择: 节点从其已知的集群成员列表中随机选择一个或少数几个目标节点(通常是k个,k远小于总节点数N)。
3)信息交换: 节点向选中的目标节点发送其持有的部分或全部信息(例如,自身状态、已知的其他节点状态、元数据更新等),并从目标节点接收类似信息。
4)状态合并与更新: 节点根据接收到的信息更新本地状态。例如,如果收到的信息版本更新,则采纳新信息。

Gossip 的信息传播方式变体
Gossip协议主要是通过直接邮寄、反熵和谣言传播三种方式来实现数据的最终一致性。

直接邮寄
直接邮寄(Direct mail),当一个节点自身状态发生重要更新时(例如,它检测到一个新数据),它主动将这个更新推送给随机选择的邻居。这是信息快速传播的一种方式,但不保证送达。
如图所示:当节点A的数据更新时,会直接将新数据传给节点B、节点C,然后各个节点再更新自己的数据。

添加图片注释,不超过 140 字(可选)

需要说明的是:当队列溢出或长时间无法访问其目的地时,消息可能会被丢弃,也就是说,只采用直邮的方式是无法实现最终一致性的。

反熵
反熵(Anti entropy/ Pull or Push-Pull style),中的熵是指混乱程度,在此处,熵可以理解成不同节点中数据的差异性。反熵就是指消除混乱程度,提升节点间数据的相似度,降低熵值。反熵主要有推、拉和推拉三种方式。

添加图片注释,不超过 140 字(可选)

1)推方式,节点A定期选择节点B,将A的所有(或部分摘要)数据推送给B,让B修复其与A不一致的部分。

添加图片注释,不超过 140 字(可选)

2)拉方式,节点A定期选择节点B,从B拉取其所有(或部分摘要)数据,修复A自身与B不一致的部分。

添加图片注释,不超过 140 字(可选)

3)推拉方式,节点A选择节点B,双方交换数据并各自修复差异。这是最常见和鲁棒的方式。

添加图片注释,不超过 140 字(可选)

反熵通过异步方式修复数据差异,可以实现“最终一致性”,但是,节点之间需要相互交换和比较数据,如果集群节点数比较多且动态变化,代价就成直线上升(比如k8s环境中检测节点故障,并动态维护集群节点状态)。因此,反熵方式适合节点数固定且有限的集群实现数据一致性。

谣言传播
谣言传播(Rumor mongering/ Hot-stuff Propagation),当一个节点有“新”信息(谣言)时,它会积极地向其他节点传播。如果一个节点收到了它之前未曾听闻的谣言,它也会变成一个活跃的传播者,继续向外散播。为了避免谣言无限传播,可以设置传播次数上限,或者当一个节点发现其大多数邻居都已经知道这个谣言时,它就停止主动传播,转为仅在被询问时才告知(即从“活跃”转为“被动”)。

// 定期执行,先随机选择集合S中的s1
// s1再随机选取集合S中的任意其他节点
// 不断解决两两之间的数据冲突
// 最终整个集合中的对象都会达成数据一致性
FOR SOME s1 belong to S DO
   ResolveDifference[S,s1)
 END LOOP

如图所示,当节点A有新数据时,会成为活跃节点,然后向集群中节点B,节点E传播该数据,节点C收到新数据之后也变成了活跃节点,然后向节点D传播新数据,这样其他节点都能更新到新数据。

添加图片注释,不超过 140 字(可选)

未完待续

很高兴与你相遇!如果你喜欢本文内容,记得关注哦!!!

实战测评:4大搜索API(You.com/Tavily/Exa/Perplexity)谁更适合你的AI项目?附Python调用代码 本文实战测评了You.com、Tavily、Exa和Perplexity四大搜索API在AI项目中的集成应用,详细对比了它们的技术特性和Python调用方法。针对LLM实时数据需求,You.com的优化设计表现突出,支持32k大上下文窗口和快速响应。文章提供了完整的代码示例和场景化选型建议,帮助开发者高效集成搜索API到AI项目中。 阅读详情

相关推荐

CANFD升级踩坑实录:DBC转换时DLC大于8的信号怎么处理?

本文详细探讨了CANFD升级过程中DLC大于8的信号处理问题,提供了工程化解决方案和AutoSar BSW层配置要点。通过分析CAN与CANFD的DLC本质差异,提出信号拆分重组、DLC重映射和协议层适配三种策略,并给出验证与测试方案,帮助开发者避免数据截断和通信故障。

weixin_42521843的博客 230

jemalloc思想的极致演绎:深度解构Netty内存池的精妙设计与实现

这种频繁的移动会导致额外的性能开销。最终,当事件驱动降低了线程调度的微观成本,资源复用消除了内存管理的隐性消耗,而分层解耦提升了模块协作的宏观效率时,一个高吞吐、低延迟的健壮系统便水到渠成。例如:在q025的范围为[25%, 50%) 时,即使Chunk的使用率降低到25%,它仍然可以保留在q025中,直到使用率降低到25%以下(即进入q000的范围)。为了提高内存分配的利用率,Netty在分配小于8KB的内存时,不再直接分配整个Page,而是将Page进一步划分为更小的内存块,由Subpage进行管理。

2501_93908980的博客 760

LabVIEW内存泄漏诊断与优化:从报错到高效运行

本文深入探讨LabVIEW内存泄漏的诊断与优化方法,从理解内存泄漏本质到使用专业工具链进行问题定位,再到高频场景的解决方案和高级优化策略。通过实战案例展示如何解决工业数据采集系统中的内存不足问题,帮助开发者提升LabVIEW应用的稳定性和效率。

moon9的博客 197

AI分布式Token中转站网关底层实现-东方仙盟

在终端优先同步架构下,所有终端智能体请求不再直连上游 MaaS 平台(千帆、百炼、DeepSeek 等),全部经由分布式 Token 中转站网关统一中继。网关承担虚拟客户密钥签发、上游子账号路由、前置内容安全审计、事务路由调度、可控网络震荡多上游链路容灾、SSE 流式透传、用量记账、封禁熔断、原始 IP 封包签名溯源等核心职责。本文基于 Go 实现分布式网关核心底座,复用架构原有无状态 Token 穿透、事务 ID 幂等、链路探活、多节点中继能力;区分两层密钥体系:面向终端客户的虚拟 Key。

cybersnow精通 28 门计算机语言,凭借其超凡的技术能力,成功开发过上万个应用,广泛涉及政府、商业、个人等众多领域,甚至在检察院、环保局、公安局等专业场景中也大放异彩。不仅熟练掌握单片机和物联网开发,在软件架构设计方面更是独树一帜,自创了跨平台软件 241

从Demo到产品:基于ADAU1452的ANC方案,硬件选型、性能优化与避坑指南

本文详细解析了基于ADAU1452的主动降噪(ANC)方案从Demo到产品的实现路径,涵盖硬件选型、性能优化与实战避坑指南。重点探讨了ADAU1452与ADAU1466的性能差异、编解码器选型策略,以及MFXLMS算法优化技巧,为工程师提供从理论验证到量产落地的系统级解决方案。

weixin_30542079的博客 451

Unity多渠道APK打包:同一工程稳定输出不冲突安装包

Android应用多渠道分发是移动开发的基础场景,其核心在于解决包名唯一性、渠道可识别性与构建可重复性三大问题。原理上,Unity安卓打包本质是三阶段流程:生成Android工程、Gradle编译、APK签名,而包名冲突根源在生成阶段对PlayerSettings的强依赖。技术价值体现在规避人工配置失误、支撑CI/CD自动化、满足华为/小米等商店合规要求。典型应用场景包括应用宝、TapTap、B站等渠道独立包管理,以及AB测试、灰度发布等运营需求。本文聚焦Unity原生方案,通过BuildPlayerOpt

weixin_33736048的博客 794

EtherCAT从站实现(三):DC同步机制与分布式时钟实现

本文详解EtherCAT伺服从站DC同步机制,解决高精度控制中因主站抖动与传播延迟导致的相位偏差问题。通过ESC硬件维护1ns分辨率全局时间,实现从站自主同步,确保PDO更新与控制环采样精准对齐。核心流程包括传播延迟测量、时钟初始化、漂移补偿及SYNC0/SYNC1信号生成。从站需正确配置DC能力与同步模式,主站则通过DCM机制保障发送周期稳定。调试建议结合示波器与寄存器监控,分阶段验证时序关系,确保多轴协同无误。

yangmu3203的博客 114

[记录一个bug]av_hwdevice_ctx_create出现Cannot allocate memory(附带库运行时路径)[已解决]

新写的程序里调用ffmpeg的av_hwdevice_ctx_create()这个函数,出现Cannot allocate memory。但是另个程序一样的代码,居然是成功的。 反复检查之后无果,就跳出去查了一下,看到一个问答: Have you tried to use ffmpg executables with the same libs that you using when you run the app? Have you tried to use ffmpg executables

熊猫Ben的博客 3586

集中式与分布式怎么选:从订单读写看 KingbaseES 的架构边界

以订单系统为例,一笔付款会扣账户余额、写一条流水、更新订单状态;月末报表则可能按日期统计所有租户的订单。前者要求几项变更一起提交,后者关心查询会覆盖多大范围。讨论集中式与分布式,先把读写请求分开,比先数数据库节点更容易看清问题。KingbaseES 核心数据库是集中式关系数据库。KES RAC 和 KES TDC 也都可以部署为多节点形态,但它们的数据组织方式并不相同。

todoitbo的博客 1万+

Dify智能体开发:大语言模型(LLM)问题分类

通过定义分类描述,问题分类器能够根据用户输入,使用 LLM 推理与之相匹配的分类并输出分类结果,向下游节点提供更加精确的信息。

王国平的博客 2249

2025年CSP-J初赛真题及答案解析(完整版)

2025年CSP-J初赛真题及答案解析(完整版)

王老师青少年编程 1万+

编队系列(二)|固定翼如何依靠邻居信息保持队形?一致性控制、通信拓扑与分布式仿真实现,附仿真代码

一致性编队将通信关系写入邻接矩阵和拉普拉斯矩阵,各机根据本机与邻居的协同变量误差生成局部修正量。普通位置一致性会使成员趋向同一点;固定翼编队需要对带槽位偏置的虚拟参考点、航迹角、速度或路径参数执行一致性,再由路径跟踪和单机制导层生成可飞参考。本文例程对二维虚拟参考点坐标进行一致性,并将路径速度、路径收敛速度和一致性速度组合为期望运动,再复用 LQR 与姿态控制接口。该结构适合验证静态环形拓扑下的多机编队,但其收敛与安全性仍受消息有效性、通信时延、拓扑变化、速度饱和、转弯曲率和机间避碰约束影响。

2302_80148937的博客 307

IsaacSim环境配置之配置本地资产包

摘要:Isaac Sim官方资产文件默认从美国服务器下载速度慢,影响开发体验。建议下载本地资产包并配置本地资源源。具体步骤包括:1) 下载资产包并解压;2) 修改Isaac Sim安装路径下的配置文件,添加本地资产路径配置,包括机器人、人物、环境等各类资源目录。配置完成后可显著提升资产加载速度,改善开发效率。文中提供了详细的配置文件修改示例和截图说明。

拥抱具身智能,昇腾Ascend C 330

分布式设备列表拿到了,数据通道选错照样传不过去

分布式协作的设计顺序应该是:先确定数据的一致性语义(状态最终一致 vs 操作恰好一次),再选通道(DDO / KV / RPC / 文件),最后把标识和内容分开。离线期间手机加了三个附件,平板重连后 DDO 会把最终的字段列表对齐,中间某一条“附件关联”的副作用如果涉及独立写入,不会因为 DDO 对齐而自动补执行。的 RPC 通道,这四条路解决的是不同的问题。的场景(扣库存、审批、附件关联),DDO 只能承载最终状态,操作序列需要应用层自己的 outbox 和确认水位来兜底。

2602_97267507的博客 380

最新的sdio 4.0 spec 协议标准 带书签 高清完整PDF版

Part-E1-SDIO-Specification-Ver4.00-Final-120220.pdf:最新的sdio 4.0 spec 协议标准 带书签 高清完整PDF版,包括SDIO 接口的外设,SDIO 接口官方协议等。

Camera2Demo

在Camera2 的基础上进行封装,使得Camera2一堆初始化逻辑与Activity分离,降低耦合度,完成预览拍照并保存的操作

分布式详解

分布式系统由多台独立节点通过网络协作,对外提供统一服务。其核心挑战在于部分失败、无全局时钟与网络不可靠。为应对这些难题,系统需在不可靠环境中保证协同正确性。分布式主要解决高吞吐、高可用、业务拆分与数据扩展问题。根据CAP定理,系统需在一致性(C)、可用性(A)与分区容错(P)中取舍,多数互联网应用选择AP,遵循BASE理论:基本可用、软状态、最终一致。分布式ID常用雪花算法,兼顾有序性与唯一性。

m0_50953782的博客 120

LinePhone3.2.7(android端最新版本) sip客户端

SIP客户端For android:LinePhone3.2.7(最新版本),官网地址:http://www.linphone.org/

OpenWiFi与LibreNMS集成实践:构建分布式异构网络管理体系

面向多厂商园区网络,详解 OpenWiFi 与 LibreNMS 的集成架构:SNMP 自动发现、MIB 指纹识别、边缘轮询与统一告警。破解数据孤岛,构建统一运维视图。

asterfusion的博客 312

蓝牙模块HM-10手册

蓝牙模块HM-10手册,该手册对蓝牙模块HM-10进行了详细的介绍和使用方法以及一些AT指令。

用势函数做分布式网络优化

首先是方向一致,玩家想让自己代价变小,一定会让势函数变小,玩家代价变大,势函数也一定变大,其次是收敛性,只要势函数有下界,则所有玩家持续优化自身代价的过程,就是势函数持续下降过程,最终一定会停在一个极小值点,最后,纳什均衡等价于势函数极值,势函数的极小值点即纳什均衡,没任何玩家愿单方改策略,因为自己代价不会再降低,势函数也不会再降。这类博弈属势博弈,即存在一个全局的势函数,每个玩家降低自身代价的动作,都会同步让全局势函数下降,个体自私优化的过程,等价于全局势函数的自动优化,最终一定会收敛到纯策略纳什均衡。

TCP/IP 254

vpls over srv6配置分布式网关

本文是《华为VPLS over SRV6》的续篇,在原有VPLS over SRv6基础上引入分布式网关和IP前缀路由,实现三层互通。文章依次给出新建三层VPN实例、配置VBD接口与Anycast网关、发布IRB路由、在BGP中发布VPN实例以及模拟三层地址段的具体配置,并通过ping测试、vrf2路由表以及EVPN的Type2(MAC路由)和Type5(IP前缀路由)表项验证主机路由与网段路由的正确学习与转发。接着上篇文章。

186

集中式与分布式怎么选:一次选型复盘,附金仓数据库建表与增删改查实践

本文以真实项目为背景,剖析集中式与分布式架构的适用场景。作者指出,盲目追求“分布式”不仅增加成本与复杂度,更可能因事务延迟、运维难度上升等问题导致系统性能下降。通过对比两类架构在事务、SQL自由度、运维与扩容等方面的差异,强调应基于业务实际需求选择方案——“不是哪个先进,而是哪个解题”。文中还拆解“伪分布式”等常见误区,并以金仓数据库实践为例,展示如何在集中式架构下高效实现订单系统设计,最终倡导“按需选型,不被概念绑架”的务实技术观。

小相探索IT世界 5196

分布式 KV 跨端数据冲突的合并策略

在开发跨设备协作文档应用时,最大的噩梦不是网络断开,而是两台设备分别在离线状态下修改了同一份文档。等它们重新联网同步时,后同步的数据直接覆盖了前面的数据,导致用户的修改凭空消失。此时必须触发预设的业务合并算法(比如把两段文本拼接,或者提示用户手动选择保留哪一份),合并完成后,将本地版本号加一,再重新推送到 KVStore。同时联网后,用你写的版本号合并逻辑去拦截默认的覆盖行为,看看两边最终的数据是否都能保留下来。为了掌控数据的主权,我们必须放弃默认的时间戳策略,在业务层引入版本号机制。

2602_97267507的博客 152

集中式与分布式,KingbaseES 的四种形态共用一套内核

金仓数据库 KingbaseES 提供集中式(单机、ClusterWare、RWC、RAC)与分布式(TDC、Sharding、ADC)双架构,基于同一内核扩展。集中式形态零应用改造,RTO均小于1分钟,RPO为0;RAC共享存储实现多活,支持跨节点并发控制。分布式通过分片管理、分布式事务等模块构建,兼容原有运维体系,避免分库分表的外部耦合。选型核心考量:数据规模、并发量、团队经验,三者皆无则从集中式起步,后续按需扩展,成本可控。

笃行其道的博客 1万+

集中式与分布式怎么选?我把手头11套系统重新过了一遍秤

先定架构,再选产品。架构选错了,后面所有的参数对比、POC 测试、迁移实施,都是白费

倔强的石头的博客 1万+

下篇:Java 异常高阶实战|自定义异常、全局异常、事务陷阱、分布式链路、生产调优(实战篇)

接上篇基础理论,本篇面向 SpringBoot 后端生产开发。从业务异常设计、全局异常处理器、统一返回结果、事务回滚失效、日志规范、分布式链路追踪、性能优化、异常治理规范、线上事故案例完整落地,给你一套可以直接复制到项目里的异常处理方案。

Caiml_1006的博客 463

HarmonyOS 分布式深度:跨端迁移、数据对象与多设备协同

本文深入解析鸿蒙分布式能力实战,聚焦跨端迁移、协同与共享三大形态,详解权限配置、设备发现、onContinue状态管理及分布式数据对象、KV同步机制。强调“先分清场景”“前置条件必全”“数据需重验”,揭示迁移失败、同步失效等七大常见坑,指导开发者规避陷阱,实现真实可用的多设备协同。

信息安全领域优质创作者|操作系统领域专家 106
上一篇: 系统里数据又“打架”了?让“少数服从多数”来终结这场混乱!
下一篇: 绯闻女孩不只会八卦:从“验明正身”到“抓内鬼”,Gossip的进阶玩法
milanyangbo
博客等级 码龄11年 199粉丝 67原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

milanyangbo

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值