广告业务系统 之 承前启后 —— “消息中心”
消息中心
消息中心，是为 投放引擎 做客户信息及素材同步的环节，与 bp 平台、结算侧、投放引擎 进行数据实时交互，是 链路中承前启后的重要环节。
欢迎关注文末公众号
物料同步链路图
物料由 DSP 发起，至 Message_center ，为 投放引擎 提供候选支撑。
广告主[后续以DSP代称]，通过 BP 平台，将自身的资质信息、标识信息、及投放的免审素材 等其他信息进行上传，BP 平台自身进行落地并进行审核，存在信息未通过审核、通过、下线、上线、暂停 等状态。
- 其中 Dsp 信息将会与 Client 信息进行耦合，作为表示当前素材的 UUID，会随流量进入到曝光日志中，最终流转至结算侧，而结算侧将以此为依据作为计量，估算订单/合同到量的主要判定条件。
- 广告素材包含两种，送审和免审。
- 免审素材包含两种类型，打底和非打底。打底素材即兜底素材，当 DSP 无相关素材返回时，进行兜底使用。非打底素材将随具体的投放计划进行曝光展示。
送审素材会随业务自然结果进行统一审核，故不在此链路。
- 场景投放信息，这里是把具体的投放场景按类型分隔为多个场景。比如，同城流、feed流、落地页等等。DSP 需要圈定，自身业务对应的用户群体所在的场景，有针对性的投放广告。
欢迎关注文末公众号
模块设计之 “一分为二”
看到这里，感兴趣的同学可能会发现，一个问题。
“消息中心的数据全都是从 BP 平台来的，为什么把数据流一分为二？”
这里解释一下原因，看看 “一分为二” 有哪些妙处，是否和你想的一致。
- 数据使用方不同
- BP 平台，使用方为 DSP。对外提供服务，需要存在外网域名、签名校验、等专属逻辑功能。
- 消息中心，使用方为 投放引擎。只对内服务提供数据支撑。
- 数据使用细节不同
- BP 平台，数据包含多个维度，多个类型。包含未审核、审核、暂停、新建、变更 等等状态及 Dsp 身份校验、历史操作记录等数据。
- 消息中心，数据仅需要为全部审核通过且当前可用、投放中的素材、Dsp、Client 等数据，状态单一，规模极小。
- 数据使用性能要求不同
- BP 平台，toB 类型，无过硬性能要求。
- 消息中心，承接实时流量，对数据读取性能要求极高。
- 模块功能专一性
- …
通过上面一通的分析，再加上你对微服务外延的理解，回到上面的问题。相信你已经得到了对应的答案！
欢迎关注文末公众号
模块交互图之 “强一致性设计”
Message_center 上游是 BP 平台，下面是两模块交互流图。
这样的交互图，乍一看比较奇怪。
“不是简单的上下游数据同步嘛，直接进行 Http/Https 接口调用不就行了嘛，好多业务上下游都是这样做的…”
当结合整个背景仔细思考后，你就会觉得上面的发言差点意思！
先介绍 上面交互图中的数据链路。
奇怪交互图的数据链路
数据源是 BP ，数据直接走中间件【kafka】进行生产落地；下游的 Message_center 模块通过消费中间价的形式获取数据。
> 注意：这里传递的数据为 命令形式【雷同于设计模式中的——命令模式】。
{
"type":"dsp",
"action":"update_all",
"env":"test",
"source":"bp",
"version":2,
"time":"2021-08-18 11:33:06"
}
Message_center 获取到命令数据后，通过 API 接口的形式，访问 BP 数据库，拉取符合命令规则的数据后，进行落地。
注意：BP 侧落地为 DB，Message_center 为读性能更优、承载量更大的 Redis/MC 组件。
数据一致性问题
假如，我们使用 Http/Https 接口形式进行上下游交互。一个问题，我们不可避免：就是网络问题。
网络对于通信来讲，是完全不可信的，要不然 TCP 协议里也不会花大部分精力处理数据包次序及重传等涉及数据完整性的策略。
- 数据包丢失 和 数据包乱序 是我们首要考虑的问题。
在怪异的交互图中，我们采用 API 拉 DB 数据的方式，有效避免此类问题。 - 数据命令发送后，与 DB 数据更新的 时间 Gap 问题。
当接受到命令并同步 DB 数据后，此时 BP 侧 DB 才完成数据变更，意味着前次同步数据为旧数据。对比，Message_center 持有 cron 任务，定期刮擦 DB 数据，进行同步。
上述问题解决了，但细心的同学可能会发现，更多的是图中右侧的链路，左侧 kafka 相关无涉及。
那么，“命令触达的方式是不是可以用 Http/Https 方式替代呢？“
- 为何使用中间件支持 命令触发呢？
不错，是可以使用 API 功能性替代的。唯一的不足是，kafka 数据完整性更高，消息落地更可靠。不过从何说起呢？- 了解 中间件 的同学可能知道这个点。
就是 在消费数据时，可以手动提交 offset。这个设置可保障 Message_center 在拿到数据后，业务处理异常可在此重新消费同一条数据，避免数据未同步的问题。如果是 API ，收到的响应仍是 200，无法发现此类问题。
- 了解 中间件 的同学可能知道这个点。
奇奇怪怪的设计，从来不是画蛇添足，只是为系统安全、高效、稳定运行而护航！
欢迎关注文末公众号
日志中心
日志中心，是广告链路中数据的中转站。实时监控全链路服务健壮性、及支撑 结算、曝光、互动 等监测上报。在后链路中发挥着举足轻重的作用…
见后续文章！
推荐阅读：
暨 广告、推荐、搜索 三大顶级复杂业务之 “广告业务系统详叙”
广告业务系统 之 承前启后 —— “消息中心”
广告业务系统 之 数据中转站 —— “日志中心-实时服务监控”
广告业务系统 之 数据桥梁 —— “日志中心-曝光数据流转结算”
广告业务系统 之 核心通道 —— “日志中心-s2s监测上报”
广告业务系统 之 辅助决策 —— “ AB 实验平台”
广告业务系统 之 框架沉淀 —— “数据消费型服务框架”
广告业务系统 之 智能保险丝 —— “智能流控”
广告业务系统 之 敏捷交付 —— “基于 Docker 容器同机部署”
广告业务系统 之 业务串联 —— “ PDB - 广告投放【保量保价】”
三行代码搞定 —— 反转链表…
Kafka 高吞吐、高性能核心技术及最佳应用场景…
HTTPS 如何保证数据传输安全 —— TLS 协议…
五分钟搭建基于 Prometheus + Grafana 实时监控系统…