在 work queue 一节 我们创建了work queue，其背后的构思是每个任务都分发给一个确定的 worker 。这一节，我们将会把消息交付给多个消费者，这种模式叫做“发布/订阅” （publish/subscribe）模式。
我们将建立一个简单的日志系统，它由两个程序组成，一个负责发送日志信息，另外一个负责接收并打印日志。
在日志系统中，每一个运行的接受者程序都将收到消息。通过这种方法，我们可以运行一个接受者直接将日志写入硬盘，同事运行另外一个接受者将日志打印到屏幕上。
本质上，发布日志消息将广播给所有的接受者。
在前面的小节，我们构建了一个简单的日志系统，让我们能够向许多接受者广播日志消息。
在这一小节，我们将增加一个特性，让接受者能够只订阅消息的一个子集。例如：我们能够只将重要的错误消息直接存储到日志文件中（写入到硬盘），而继续让所有的日志消息打印到控制台中。
工作队列的主要设计思想是为了避免立即执行“资源密集型”的任务而必须等待其完成。取而代之，我们可以安排任务延迟执行。我们将一个任务封装成信息并发送到队列，在后台运行的“worker”进程将弹出任务并最终执行任务。如果你运行很多个“worker”，他们将共享这些任务。
Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自懂切换。
它的主要功能有以下几点
不时地监控redis是否按照预期良好地运行;
如果发现某个redis节点运行出现状况，能够通知另外一个进程(例如它的客户端);
能够进行自动切换。当一个master节点不可用时，能够选举出master的多个slave(如果有超过一个slave的话)中的一个来作为新的master,其它的slave节点会将它所追随的master的地址改为被提升为master的slave的新地址。
Redis 提供了两种不同的持久化方法来将数据存储到硬盘里面。快照（snapshotting）和 只追加文件（append-only file, AOF），它会在执行写命令时，将被执行的写命令复制到硬盘里面。
在处理Web客户端发送的命令请求是，某些操作的执行时间可能会比我们预期的更长一些。通过将待执行任务的相关信息放入队列里面，并在之后对队列进行处理，用户可以推迟执行那些需要一段时间才能完成的操作，这种将工作交给任务处理器来执行的做法被称为任务队列（task queue）。
计数信号量是一种锁，它可以让用户限制一项资源最多能够同时被多少个进程访问，通常用于限定同时使用的资源数量。
计数信号量和其他锁的区别在于，当客户端获取锁失败的时候，通常会选择等待；而当客户端获取计数信号量失败的时候，客户端通常会选择立即返回失败结果。
根据上一节对 WATCH 高负载情况下的测试结果显示，WATCH、MULTI 和 EXEC 组成的事务并不具有可拓展性，因为程序在尝试完成一个事务的时候，可能会因为事务执行失败而反复地进行重试。保证数据的正确是一件非常重要的事情，但使用 WATCH 命令的做法并不完美。
为了解决这个问题，并以可拓展的方式来处理市场交易，我们将使用锁来保证市场在任一时刻只能上架或者销售一件商品。
一般来说，在对数据进行“加锁”时，程序首先需要通过获取（acquire）锁来得到对数据进行排他性访问的能力，然后才能对数据执行一系列操作，最后还要将锁释放（release）给其他程序。对于能够被多个线程访问的 共享内存数据结构（shared-memory data structure） 来说，这种“先获取锁，然后执行操作，最后释放锁”的动作非常常见。
Redis 使用 WATCH 命令来代替对数据进行加锁，因为 WATCH 只会在数据被其他客户端抢先修改了的情况下通知执行了这个命令的客户端，而不会阻止其他客户端对数据进行修改，所以这个命令被称为 乐观锁（optimistic locking）。
分布式锁也有类似上面描述的动作，但这种锁既不是给同一个进程中的多个线程使用，也不是给同一台机器上的多个进程使用，而是由不同机器上的不同 Redis 客户端进行获取和释放的。
何时使用以及是否使用 WATCH 或者锁取决于 给定的应用程序。
下面会说明“为什么使用 WATCH 命令来监视被频繁访问的键可能引起性能问题”，还会展示构建一个锁的详细步骤，并最终在某些情况下使用锁去代替 WATCH 命令。