发布-订阅模式总结

【1】///////////////////////////////////////////////观察者模式与发布/订阅模式区别////////////////////////////////////////////

(1)观察者模式

比较概念的解释是，目标和观察者是基类，目标提供维护观察者的一系列方法，观察者提供更新接口。具体观察者和具体目标继承各自的基类，然后具体观察者把自己注册到具体目标里，在具体目标发生变化时候，调度观察者的更新方法。

比如有个“天气中心”的具体目标A，专门监听天气变化，而有个显示天气的界面的观察者B，B就把自己注册到A里，当A触发天气变化，就调度B的更新方法，并带上自己的上下文。

(2)发布/订阅模式

比较概念的解释是，订阅者把自己想订阅的事件注册到调度中心，当该事件触发时候，发布者发布该事件到调度中心（顺带上下文），由调度中心统一调度订阅者注册到调度中心的处理代码。

比如有个界面是实时显示天气，它就订阅天气事件（注册到调度中心，包括处理程序），当天气变化时（定时获取数据），就作为发布者发布天气信息到调度中心，调度中心就调度订阅者的天气处理程序。

总结：从两张图片可以看到，最大的区别是调度的地方。

虽然两种模式都存在订阅者和发布者（具体观察者可认为是订阅者、具体目标可认为是发布者），但是观察者模式是由具体目标调度的，而发布/订阅模式是统一由调度中心调的，所以观察者模式的订阅者与发布者之间是存在依赖的，而发布/订阅模式则不会。

【2】///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

pubsub机制摘要

(1)发布接口

op_pub: 实现op间端到端通信，但不能给op自身发消息。 不同的op可以部署在一个执行体内，也可以部署在不同执行体。

(2)发布过程

存在两级模式匹配:

1.1、执行体间: 根据关键字匹配subcache，匹配得到的订阅者为执行体。

1.2、执行体内: 根据关键字匹配bindcache，匹配得到的订阅者为op。

(3)订阅接口 op_sub op_bind

op_sub 完成两个动作:

①向网络(TCFS Server) 注册了本执行体订阅信息，并刷新入所有执行体的subcache;

②在本执行体注册了op订阅者信息，保存入本执行体的bindcache。 op_bind只在本执行体注册了op订阅者信息，保存入本执行体的bindcache。(这在整个网络上不可见，因而需要谨慎使用op_bind。通常只使用于单容器多op实例)

(4)粘滞流程

(5)说明： luc 在stable op上电时sub (s_lucm_luc，“＞”)，在destory时清粘滞。所以luc执行体能sub到lucm执行体pub的消息。通过模糊匹配。 //①sub (s_lucm_luc，“＞”)要放在stable op是因为stable总是收到流程开始的第一条消息。; ②后续如果进入其他特性op，在其他特性op通过精确bind(匹配优先级更高)，从而可以获得消息