sonic通信机制

内容分享8小时前发布

0 0 0

1. epoll机制

所有的通信机制的底层都是基于epoll机制来传输接收信息的。

1.1 基本的epoll

sonic通信机制

1.2 redis epoll

sonic通信机制

2. redis订阅模式

2.1 频道订阅

Redis将所有频道的订阅关系都保存在服务器状态的pubsub_channels字典，字典的key是某个被订阅的频道，而对应值则是一个链表，链表里记录了所有订阅这个频道的客户端。
sonic通信机制

2.2 模式订阅

模式订阅相当于多个频道订阅。Redis将所有模式的订阅关系都保存在服务器状态的pubsub_patterns链表，链表的每个节点都包含着一个pubsub Pattern结构，这个结构的pattern属性记录了被订阅的模式，而client属性则记录了订阅模式的客户端。
sonic通信机制

如果使用频道订阅了一次频道，模式订阅中也订阅了这个频道，那么订阅了这个频道的客户端会收到多次消息。

3. redis消息队列实现

在acl下发流程中使用了三种消息队列方式来实现基于redis的订阅/发布机制:

一种是基于redis的pub/sub机制 – Redis MQ，支持一对多一种是基于redis的list，结合pub/sub机制，点对点一种是基于redis的set，结合pub/sub机制，点对点

3.1 pub/sub

sonic通信机制
上述是一个redis自带的pub/sub的频道订阅，多个客户端订阅了同一个频道，比如:
SUBSCRIBE CHANNEL1
redis发布频道信息:
PUBLISH CHANNEL1 message
途中订阅了的客户端都能收到发布的通知，是一个一对多的模式。
模式订阅是一样的，模式订阅只是订阅了一组频道而已。
pub/sub机制是redis内部自动处理的，只要对redis进行配置，写入数据库即会产生通知:
sonic通信机制

这里的事件通知仅仅是通知消费者一方当前数据库记录存在改变，可以通过事件通知中的key值去读取数据库，获取详细的更新信息。

3.2 list + pub/sub

list本身就是消费者/生产者的最基本的实现方法，但是只能实现一对一的，即生产者产生了一个消息，这个消息只能被一个消费者消费。
sonic通信机制

redis提供了一些list操作:
sonic通信机制
比如acl下发流程中，针对asic_db数据库，是基于list+pub/sub的机制来实现的:
生产者:

LPUSH list-name key op value: 将详细的事件通知写入listPUBLISH CHANNEL 'G': 每向队列写入一条通知，则针对相关频道发布一条通知，方便消费者计算事件通知的条数
消费者:SUBSCRIBE CHANNEL: 订阅相关频道 – 首先通过订阅频道的通知计算事件数量LPOP ...: 根据事件数量从队列中依次取出每一条通知的详细信息

3.3 set + pub/sub

set与list类似，但是不同的是set具有唯一性，set会自动剔除相同的元素，而list可以存在相同的元素。同样的，也是只能实现一对一的，即生产者产生了一个消息，这个消息只能被一个消费者消费。
sonic通信机制

redis提供了一些set操作:

比如pins写入APPL_DB的流程，是基于set+pub/sub的机制来实现的:
生产者:

SADD key value: 将详细的事件通知value写入对应key值的set中PUBLISH CHANNEL 'G': 每向队列写入一条通知，则针对相关频道发布一条通知，方便消费者计算事件通知的条数
消费者:SUBSCRIBE CHANNEL: 订阅相关频道 – 首先通过订阅频道的通知计算事件数量SPOP ...: 根据事件数量从队列中依次取出每一条通知的详细信息