计数信号量也是一种锁，它可以让用户限制一项资源最多能够同时被多少个进程访问，计数信号量和锁的区别在于，当客户端获取锁失败时，通常会选择等待；而当客户端获取计数信号量失败时，通常会选择立即返回失败结果。下面模拟一下，最多同时只允许5个进程同时访问一个资源。

构建基本的计数信号量

构建计数信号量时要考虑的事情和构建其他类型的锁时要考虑的事情大部分都是相同的，比如判断时哪个客户端取得了锁，如何处理客户端在获得锁之后奔溃的情况，以及如何处理锁超时的问题。为了使多个信号量持有者的信息都存储到同一个结构里面，将使用有序集合来构建计数信号量。就是为每个尝试获取信号量的进程生成一个唯一标识符，将这个标识符用作有序集合的成员，对应的分值是尝试获取信号量时的Unix时间戳。

本章节，构造分布式锁的目的既不是给同一个进程中的多个线程使用，也不是给同一台机器上的多个进程使用，而是由不同机器上的不同Redis客户端进行获取和释放的。

锁的重要性

回忆一下之前学的Redis事物章节中模拟的市场购物场景，购买商品的时候使用了watch去监视市场以及买家的的个人信息来保证购买流程的正常进行。引用书上的性能测试数据来说明性能扩展的必要性，下表将展示市场在重负载情况下运行60秒的结果：

可以很明显看出watch的性能不具扩展性，下面将使用锁来保证市场在任意时刻只能上架或销售一件商品，看看性能会怎么样。

前面学习了使用Redis来构建应用程序的基本方法以及所需的工具，本章将会学习更多更有用的工具和技术，并使用它们去构建更具规模的Redis应用。现在模拟一个场景，假设有一家叫Fake Game的游戏公司，每天都有好几百万玩家同时在线游戏。代码示例依然位于redis-sample项目的support模块中。

自动补全

在Web领域，自动补全功能大家已经很熟悉了，下面我们用Redis来实现两种自动补全功能，自动补全联系人和通讯录自动补全。

之前学习了如何将Redis用作整个系统的一部分，这一章将来学习写如何使用Redis来构建辅助程序。代码示例位于redis-sample项目的support模块中。

日志

使用列表存储最新的日志记录：

1
2
3
4
5
6
7
8
9
10
11
12

public void logRecent(String name, String message, String severity) {
    final byte[] destination = stringRedisTemplate
            .getStringSerializer()
            .serialize("recent_" + name + "_" + severity);
    RedisCallback<Object> pipelineCallback = redisConnection -> {
        redisConnection.lPush(destination,
                (TIMESTAMP.format(new Date()) + ' ' + message).getBytes());
        redisConnection.lTrim(destination, 0, 99);
        return null;
    };
    stringRedisTemplate.executePipelined(pipelineCallback);
}

前面章节已经涉及过基本的Redis事物，知晓了Redis的事物和传统的关系型数据库的事物并不相同。Redis虽然有简单的方法可以处理一连串相互一致的读操作和写操作，但是没有办法根据读取到的数据为依据来进行相关操作，这种无法以一致性的形式读取数据的行为将导致某一类型的问题变得难以解决。

模拟场景演示Redis事物

下面以一个商品买卖市场为场景，来演示Redis事物的使用，在该场景下，人们可以在市场里自由销售和购买商品。