为了让发布操作尽可能快地返回，我们在创建后会仅针对前 1000 个关注者的主页时间线添加新的状态消息，如果当前发布者的关注者超过了 1000 个，则使用 09. 实现任务队列、消息拉取和文件分发 中实现的任务队列异步处理后续的关注者。 P192
删除消息时同理操作即可，先删除状态消息本身，然后处理发布者自己的统计信息，再从个人时间线中删除该消息 id ，最后再从前 1000 个关注者的主页时间线中删除，若关注者人数超过 1000 ，再使用任务队列异步处理后续的关注者。 P193
流 API P194构建一些函数来广播 (broadcast) 简单的事件 (event) ，然后由负责进行数据分析的事件监听器 (event listener) 来接收并处理这些事件，流 API 请求能在一段比较长的时间内持续地返回数据。 P194
流 API 的作用是随着时间的推移，产生一个由时间组成的序列，以此来让整个网络上的客户端和其他服务及时地了解到网站目前正在发生的事情。 P195
构建流 API 的过程中需要进行各种各样的决策，这些决策主要和以下 3 个问题有关： P195
流 API 需要对外公开哪些事件？
需要公开目前实现的四种用户操作：发布消息、删除消息、关注用户和取消关注用户。本节将以创建发布消息事件和删除消息事件为例进行实现
是否需要进行访问限制？如果需要的话，采取何种方式实现？
目前仅在涉及用户隐私或者系统资源的时候，考虑访问限制
流 API 应该提供哪些过滤选项？
既可以通过关注过滤器（基于用户进行过滤）、检测过滤器（基于关键字进行过滤）和位置过滤器来获取过滤后的消息，又可以通过类似推特的 firehose （可以获取所有公开消息） 和 sample （只能获取少量公开消息） 这样的流来获取一些随机的消息。
标识客户端 P198为了区分不同的客户端，需要对其进行标识，大部分情况下来说只用考虑已登陆用户即可，那我么使用用户 id 进行标识，为了同时实现验证用户 id 的功能，可以使用 JWT 。
过滤消息 P200我们将使用 Redis 的 PUBLISH 命令和 SUBSCRIBE 命令（05. Redis 其他命令简介 介绍了这两个命令的用法和缺陷）来实现订阅发布功能：当用户发布一条消息时，程序会通过 PUBLISH 发送给某个频道，而各个过滤器则通过 SUBSCRIBE 来订阅并接收那个频道的消息，并在发现与过滤器相匹配的消息时，将消息回传 (yield back) （如果是发布消息，则回传实体；如果是删除消息，则回传 id 和当前状态）给 Web 服务器，然后由服务器将这些消息发送给客户端。 P200
本文首发于公众号：满赋诸机（点击查看原文） 开源在 GitHub ：reading-notes/redis-in-action
