Redis的发布与订阅

业务：

运用数据与信息指导小药工的采购生产与销售行为

需求背景：

（1）药工汇小程序用户（即小型中药初加工用户）需要知道自己加工的品种的价格涨跌信息和品种相关资讯）

需求分析拆解：

（1）使用爬虫程序脚本从中药材天地网上爬取价格和资讯相关信息（爬虫）

（2）此爬虫程序的执行使用定时任务管理（定时任务）

（3）爬虫获取的信息持久化到mongodb数据库（数据持久化）

（4）药工汇得到的信息的过程使用发布订阅模型，每个指向相同Redis主机数据库的连接为一个订阅者或发布者，一级分发频道为平台名称，二级分发频道为品种名称，订阅者无需点击订阅，订阅是根据主营品种自动默认完成订阅的（发布与订阅）

（5）统一调度守护程序轮询所有消息，根据频道将信息使用消息模板分发到每个订阅者，这样，此守护进行长时间占用CPU，效率低；可以改为使用定时任务，例如8:00-20:00每隔1小时执行一次消息轮询脚本；使用微信服务号的模板消息向用户推送信息（统一调度轮询守护进程）

技术理论：

1. 观察者模式与发布订阅模型的区别

（1）观察者模式图解

（2）发布-订阅模型图解

（3）两者的区别

a. 从图解中可以看出，观察者模式没有调度中心作为中转，直接将观察者注册到目标，发生事件时目标直接更新通知观察者； 发布订阅模型则以调度中心作为中转，订阅者将事件注册到调度中心，发生事件时发布者将信息发送给调度中心进行统一调度，调度中心将信息推送给订阅者

b. 相对来说，观察者模式是存在依赖的；发布订阅模型是松耦合的

2. 发布订阅与RestAPI的优缺点场景对比

（1）发布订阅的优缺点及场景

发布订阅本质上是服务器（发布者）向客户端（订阅者）反向推送的机制；

优点：

a. 是达到了最高的实时性，因为服务器数据的更新同时推向了客户端；

b. 一次性为单条数据同步

c. 采用事件回调的方式更新数据，总体上是异步的

缺点：

a. 是用户可能会很烦，因为用户是被动接收的（即使是用户根据标签，用户自己订阅的，用户依然可能会很烦），而且信息很可能不是精准用户想要的信息；

b. 每更新一条数据则同步一次，同步次数频繁

场景：

是用户迫切需要某一标签的信息或者数据

（2）RestAPI的优缺点及场景

RestAPI本质上是客户端向服务端正向请求的机制，原理和发布订阅刚好相反；

优点：

a. 是客户端根据自己的意愿请求数据，得到的信息是精准的；

b. 一次性同步一个时间段内所有数据， 体现为数据同步的批量操作

c. 采用主动同步请求的方法，是同步的

缺点：

是没有发布订阅的高实时性，不过一般来说，用户不需要这么高的实时性；

场景：

是通用情况

例如：下面的信息平台和药工汇平台数据同步的方案比较

方案	详细说明	特点	需要做什么
方案1：使用发布订阅模型同步更细数据	信息平台已经向频道发布数据， 需要做的是在时间回调函数中 调用药工汇平台提供的RestAPI，此RestAPI的内容为更新药工汇的数据， 为INSERT操作，PUT操作；	1. 及时同步 2. 异步执行 3. 单条多批次同步 4. 事件触发	1. 只需药工汇平台提供RestAPI， 此RestAPI为PUT操作，INSERT操作； 需传入的参数有访问药工汇平台的平台级access_token，药工汇平台做access_token验证； 需关心药工汇平台数据库结构（主要工作在药工汇）
方案2：使用定时任务请求RestAPI获取数据	信息平台已经向频道发布数据， 需要做的是使用定时任务跨域请求 信息平台提供的RestAPI，此RestAPI的内容为从频道中获取数据， 为SELECT操作， LIST操作	1. 延时同步 2. 同步执行 3. 批量同步 4. 定时任务触发	1. 只需信息平台提供RestAPI，此RestAPI为LIST操作，SELECT操作； 需传入的参数有访问信息平台的平台级access_token，信息平台做access_token验证； 无需关系药工汇平台数据库结构；药工汇配置定时任务（主要工作在信息平台）

2. Redis中发布订阅的架构

（1）图解

包括：

a. 订阅者订阅一个或多个频道

b. 订阅者使用模式匹配订阅多个频道

c. 订阅者取消订阅频道

d. 发布者向某个频道发布消息

3. Redis的发布订阅实验（验证已订阅的客户端是否会自动收到消息）

预期：

Redis-client_2在步骤（2）不会收到消息

Redis-client_2在步骤（3）不会收到消息

Redis-client_2在步骤（4）收到消息

步骤：

（1）启动Redis服务器和两个Redis客户端：启动Redis-server，启动Redis-client_1和Redis-client_2

结果：服务器和两个客户端已经成功启动

（2）在Redis-client_1向频道channel_1发送一条消息，消息内容为 "Hello, Word!"； 观察Redis-client_2是否收到此消息

结果：客户端2未订阅任何频道则无法收到消息

（3）在Redis-client_2订阅频道channel_1； 观察Redis-client_2是否收到消息Hello,World!

结果：客户端2订阅了频道1无法收到订阅前发送到频道1的任何消息

（4）在Redis-client_1向频道channel_1发送一条消息，消息内容为 "Good afternoon!"； 观察Redis-client_2是否收到此消息

结果：客户端2能收到订阅后发送到此频道的任何消息

结论：实验结果和预期猜想相符，Redis客户端只能被动接收到订阅此频道发送的消息

4. Redis发布订阅实验（原生PHP+php_redis扩展）

准备：

（1）安装好php_redis扩展（在windows上需要下载php_redis.dll并放入php/extra中；在php.ini中加入extension=php_redis.dll）

注意：

a. 下载php_redis.dll对应版本时需要查看phpinfo中php的版本，php是32位还是64位的，php的thread是否为safety

b. 需要将extension=php_redis.dll放入apache/php.ini和php/php.ini中

（2）启动Redis服务器及启动Redis客户端1

（3）编写Redis客户端2订阅的脚本，如下：

<?php
//避免在默认的配置下，1分钟后终端了与redis服务器的链接
ini_set('default_socket_timeout', -1);
$redis = new Redis();
$redis->connect('127.0.0.1',6379);
$redis->subscribe(['channel_1'], function($redis, $channel, $msg){
    var_dump($redis);
    var_dump($channel);
    var_dump($msg);
});
?>

启动脚本运行，并在客户端1发送一条消息，观察客户端2：

3. 其他发布订阅框架例如ActiveMQ与 Redis的区别

平台交互图：

编码实现：

服务器运维：

参考：

1. 观察者模式与发布订阅模式的区别

https://www.cnblogs.com/lovesong/p/5272752.html

2. Redis的发布订阅机制

https://www.cnblogs.com/yitudake/p/6747995.html