1. Introducción al modo Pub / Sub
Pub / sub es un modelo de comunicación muy utilizado. Utiliza eventos como mecanismo de comunicación básico para proporcionar el modo de interacción débilmente acoplado que requieren los sistemas a gran escala:
Un suscriptor (como un cliente) expresa un evento o un tipo de evento que está interesado en recibir en forma de suscripción a un evento; un editor (como un servidor) puede notificar a los suscriptores relevantes de eventos que son de interés para el suscriptor. en cualquier momento.
De manera similar, pub / sub de Redis es un modo de comunicación de mensajes. El propósito principal es liberar el acoplamiento entre los editores de mensajes y los suscriptores de mensajes. Como servidor pub / sub, Redis actúa como un mensaje entre los suscriptores y los editores. La función de enrutamiento .
2. Escenarios de aplicación
El escenario de aplicación actual es: necesitamos establecer un sistema de monitoreo independiente para monitorear el estado de operación de la interfaz de otro sistema. El trabajo que debe realizarse se divide principalmente en dos partes: publicación de mensajes en el sistema monitoreado y suscripción y consumo de mensajes en el sistema de seguimiento.
Debido a la gran cantidad de información que debe transmitirse, utilizamos el formato json para la interacción de mensajes.
3. Implementación del código
Lado del comunicado de prensa
El final de la publicación de mensajes es el sistema supervisado y se crea una nueva clase RedisPublisher para la publicación de mensajes.
public class RedisPublisher {
private final static Logger logger = LoggerFactory.getLogger(RedisPublisher.class);
private final JedisPool jedisPool;
public RedisPublisher(JedisPool jedisPool) {
this.jedisPool = jedisPool;
}
/**
* 发布一个消息
*
* @param channel
* @param message
*/
public void publishMsg(String channel, String message) {
Jedis jedis = null;
logger.info("发布消息，频道：" + channel + ";内容：" + message);
try {
jedis = jedisPool.getResource();
jedis.publish(channel, message);
} catch (Exception e) {
logger.error("第一次publish发布信息失败,channel:" + channel + "失败原因:",e);
// 再次尝试
try {
if (jedis == null) {
jedis = jedisPool.getResource();
}
jedis.publish(channel, message);
} catch (Exception ee) {
logger.error( "再次publish信息失败,channel:" + channel + "失败原因:",ee);
} finally {
if (jedis != null) {
try {
jedis.close();
} catch (Exception e) {
jedis = null;
}
}
}
}
}
}
La empresa llama internamente al método publishMsg en la clase RedisPublisher
JedisPool jedisPool = new JedisPool(new JedisPoolConfig(), "127.0.0.1", 6379, 0, "123456");
RedisPublisher redisPublisher = new RedisPublisher(jedisPool);
// 将需要发送的消息处理为 json 格式
JSONObject jsonObject = new JSONObject();
jsonObject.put("type", 1);
jsonObject.put("region", "北京");
RdeisPublisher.publishMsg("api_channel", jsonObject.toString());
Receptor de mensajes
El extremo receptor del mensaje es el sistema de monitoreo.Cuando un usuario accede al sistema monitoreado, se liberará un mensaje y el sistema de monitoreo realizará el procesamiento correspondiente después de escuchar el mensaje.
Nueva clase de procesamiento empresarial de suscripción de mensajes BusinessSubService
/**
* 消息订阅业务处理类
*/
@Service
@Slf4j
public class BusinessSubService {
public void receiveMessage(String message) {
try {
// 使用hutool进行json处理
JSONObject jsonObject = new JSONObject(message);
// 具体的业务处理
......
} catch (Exception e) {
log.error("消息订阅处理发生异常", e);
}
}
}
Nueva clase de configuración de procesamiento del servicio de suscripción de mensajes SubscriberConfig
/**
** 消息订阅业务处理配置类
**/
@Configuration
public class SubscriberConfig {
@Autowired
private BusinessSubService businessSubService;
@Bean
public RedisMessageListenerContainer container(RedisConnectionFactory connectionFactory,
MessageListenerAdapter listenerAdapter) {
RedisMessageListenerContainer container = new RedisMessageListenerContainer();
container.setConnectionFactory(connectionFactory);
List<PatternTopic> topicList = new ArrayList<>();
// api_channel 是对应的频道名称
topicList.add(new PatternTopic("api_channel"));
container.addMessageListener(listenerAdapter, topicList);
return container;
}
@Bean
public MessageListenerAdapter listenerAdapter() {
// receiveMessage 是 BusinessSubService 类中的接收信息的方法（名称需要对应起来）
return new MessageListenerAdapter(businessSubService, "receiveMessage");
}
}
Cuatro. Restricciones de publicación y suscripción de Redis
Los mensajes de publicación y suscripción de Redis no tienen un mecanismo de persistencia y pertenecen a un modo de disparar y olvidar, lo que significa que no pueden garantizar que los suscriptores no se pierdan ningún mensaje como los mensajes en MQ, independientemente de si estos suscriptores de mensajes están en línea.
Dado que originalmente es un modo de envío y descarte de mensajes, Redis no necesita formular específicamente un mecanismo de copia de seguridad y recuperación de mensajes.
Redis tampoco prepara ninguna solución para que los editores y suscriptores garanticen el rendimiento del mensaje. Por ejemplo, cuando una gran cantidad de mensajes llegan al servicio de Redis al mismo tiempo, si los suscriptores del mensaje llegan demasiado tarde para completar el consumo, puede causar acumulación de mensajes, y MQ tiene una solución especial para esta situación. Mecanismo de mensaje lento.
Si puede tolerar estas deficiencias, la cola de mensajes de Redis es una buena opción.