1. 先聊清楚实时关系传递到底在解决什么问题1.1 社交场景里的一个真实例子最近在做一个“关系推荐与风险传导”项目从技术选型上就是一个非常典型的 RabbitMQ 大数据图计算组合。先讲一个运营同学一听就懂的例子系统监控到用户小明关注了Ruby几秒后Ruby又点赞了Kevin发布的一条帖子。从图视角看小明、Ruby、帖子、Kevin之间天然形成一条路径小明—FOLLOW→Ruby—LIKE→帖子—AUTHOR→Kevin。业务上想实时给小明推送“你关注的人Ruby点赞了Kevin的内容”这种提醒就是在做实时关系传递。这里的关系不是简单的一对一好友关系而是图上节点通过边串起来的间接关系。传统做法是离线任务每小时或每天跑一遍全量图把新产生的二度人脉或者风险链路刷出来但到那会儿用户早就离开了当时的互动场景运营想抓住的就是关系发生之后那几十秒的变化窗口。于是需求就变成一条关系事件发生后要在秒级把它追加到全局关系图里再沿着新增边做多跳传递计算。这套逻辑术语上叫实时关系传递实现上则强依赖消息队列和图计算引擎的配合。1.2 为什么不能指望定时批处理真正开始做实时后会发现数据源非常多用户关注接口、点赞服务、交易系统、内容举报、设备指纹上报每个系统都可能产生节点与节点之间的关系变更。如果让图计算平台直接去各业务系统拉数据第一个问题是数据接口五花八门第二个问题是高峰期所有系统同时产生大量关系变更图数据库写入压力会陡增。更严重的是业务系统不能因为图计算模块挂了就一直阻塞生产流程否则一个辅助链路会把核心链路拖垮。这就是需要一套异步事件管道的原因。业务系统只负责把“发生了关系变更”这个事实扔到 RabbitMQ不关心后面有多少消费者、图计算模块是否 ready。RabbitMQ 在这里承担的是削峰缓冲、事件分发和故障隔离让上游业务和图计算引擎解耦。你可以把它理解成快递中转仓所有商家把包裹统一送到中转中心末端再按区域分给快递员。商家不会因为某个片区快递员请假而无法寄件快递员也不会因为瞬间涌进大量包裹而被商家直接堵门。1.3 关系事件在图中最终是什么形态要聊实现得先统一语义。我把图上每个实体都称为 Entity 节点比如用户、帖子、设备、银行卡实体之间通过关系边连接比如 FOLLOW、LIKE、AUTHOR、TRANSFER、REGISTER_DEVICE。每当业务系统产生一条新的关系边就对应一个关系事件RelationEvent。RabbitMQ 里传递的对象不是“图计算结果”而是这些原始关系变更消息真正算关系、做传递计算的活应该放在消费端和图引擎那边。这么拆开之后分工非常清楚RabbitMQ 管消息可靠到达大数据图计算管节点和边的增量维护与路径查询。两者结合实时关系传递才