目前的流程：
两个Redis：
Redis1： 存储词条的summary信息
Redis2：任务队列，用于暂存Redis中没有summary，需要进行处理获取summary， 队列用的Redis的list结构
两个进程：
1、 进程1：服务进程
接收请求，划内链词，然后从Redis1中去获取词的summary， 如果获取失败，则返回code=4的错误，并将词条id写入任务队列Redis2等待被进程2处理
2、进程2：读取Summary的进程
循环从任务队列Redis2中读取词条id，并调用一个A接口获取词条的summary信息，写入Redis1中，并设置过期时间为3天
最近暴露出来的问题：
一个请求重复请求很多次后，仍然返回code=4的错误
但是按照上述逻辑，如果速度够快的话，第一次请求的时候返回code=4的错误，第二次应该是可以拿到数据的
分析原因：
首先查看了Redis1，的确拿不到对应词条的summary信息
手动获取了summary并存入Redis1后，请求可以获取到数据
看来的确是因为Redis中获取不到数据而导致的
看了下Redis2的长度， 居然积压了1000多万！
的确， 最近 A接口（也就是进程2中获取summary的接口挂掉了很长一段时间）， 而且可以观察到，这个Redis2队列的长度仍然在不断升高，一晚上的时间上升了接近40万
队列长度不断飙升，一方面是因为大量的词条获取不到summary， 导致Redis1大量的miss， 而miss的都会进入到Redis2队列中
此外，进程1和进程2速度不匹配应该也是一个原因， 进程2只有一个进程在工作，而进程1是有4个进程在工作
解决办法：
提高进程2的数量， 当然在提高进程2的数量的时候，我首先得知道获取summary的A接口的服务能力， 因为我这些进程会调这同一个接口
于是我用ab压测了下那个接口，服务能力大概在150 QPS, 于是我可以放心的提高我的进程数了
我将进程数从1提高到了5， 可以看到队列中积压的数据正在逐渐的减少了，大概每秒减少100多个， 这样一天左右，积压的数据就会全部被处理掉