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

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
分布式场景下，单机锁没有办法保证全局的最终一致性

(2)、分布式锁

相对于单机应用设定的单机锁，为分布式应用各节点对共享资源的排他式访问而设定的锁就是分布式锁。在分布式场景下，有很多种情况都需要实现多节点的最终一致性。比如电商促销，分