Redis——发布订阅、分布式锁

本文详细介绍了Redis的发布订阅功能及其工作原理,重点探讨了Redis实现分布式锁的不同策略,包括单机锁、基于Redis的分布式锁及其优化方案,并分析了Redis高可用分布式锁的挑战。此外,还对比了Zookeeper实现分布式锁的优势和特点,讨论了其在防止死锁和确保服务可用性方面的解决方案。
摘要由CSDN通过智能技术生成

1、Redis发布订阅

Redis 发布订阅(pub/sub)是一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接收消息。
Redis 客户端可以订阅任意数量的频道

(1)、使用方法

  1. 订阅频道
client1->: SUBSCRIBE channel1
client2->: SUBSCRIBE channel1
client5->: SUBSCRIBE channel1

在这里插入图片描述
2. 发布消息

PUBLISH channel1 "hello world"

在这里插入图片描述

(2)、工作原理

订阅频道

struct redisServer {
   
    // ...
    dict *pubsub_channels;
    // ...
};

每个 Redis 服务器进程都维持着一个表示服务器状态的 redis.h/redisServer 结构, 结构的 pubsub_channels 属性是一个字典, 这个字典就用于保存订阅频道的信息;
其中,字典的键为正在被订阅的频道, 而字典的值则是一个链表, 链表中保存了所有订阅这个频道的客户端。
在这里插入图片描述
执行

client10086->: SUBSCRIBE channel1 channel2 channel3

在这里插入图片描述
伪代码

def SUBSCRIBE(client, channels):

    # 遍历所有输入频道
    for channel in channels:

        # 将客户端添加到链表的末尾
        redisServer.pubsub_channels[channel].append(client)

发布

PUBLISH channel1 "hello world"

伪代码:

def PUBLISH(channel, message):

    # 遍历所有订阅频道 channel 的客户端
    for client in server.pubsub_channels[channel]:

        # 将信息发送给它们
        send_message(client, message)

模式订阅
可以支持模式匹配的方式,订阅channel
在这里插入图片描述
适用场景:群聊消息,公众号推送

2、Redis实现分布式锁

在互联网领域的绝大多数的场景中,都需要牺牲强一致性来换取系统的高可用性,系统往往只需要保证“最终一致性”,只要这个最终时间是在用户可以接受的范围内即可。

在很多场景中,我们为了保证数据的最终一致性,需要很多的技术方案来支持,比如分布式事务、分布式锁等。有的时候,我们需要保证一个方法在同一时间内只能被同一个线程执行。在单机环境中,Java中其实提供了很多并发处理相关的API,但是这些API在分布式场景中就无能为力了。也就是说单纯的Java API并不能提供分布式锁的能力。

(1)、单机锁

Synchionzed
Lock
分布式场景下,单机锁没有办法保证全局的最终一致性<

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值