hi, 章老师
我们的项目是一个App的api接口，
：
client的request到达nginx, 经过nginx的反向代理，将请求转发至nginx所在的机器的200个tornado进程，由tornado来处理真正的业务罗辑，
在tornado的接口有一层memcached缓存，在走到真正的业务逻辑代码之前，判断是否请求命中缓存，如果命中则返回memcached中的结果作为response，
然后返回给nginx，再返回给client；如果未命中缓存，则直接走tornado的业务逻辑拿到response，返回给nginx，同时存入memcahced．下次有同样的uri请求时，
就会命中缓存．
：
client的request到达nginx, 在nginx这一层使用srcache，通过uri判断是否命中缓存，如果命中，则直接返回memcached中的结果作为response，返回给client；
如果未命中缓存，则通过proxy_pass将请求反向代理到后端的tornado进程，由tornado返回数据作为response，返回给nginx，nginx返回response给client,同时通过
srcache_store存入memcached，下次有同样的请求时，就会命中缓存．
现在我碰到的问题如下：
通用性的接口（key的份数不多），通过架构的调整之后，整个的平均响应时间降低很多，性能得到很大的提升，在此感谢章老师的openresty~~.
唯一性的接口（key的份数很多，比如用id作为参数来调用接口），通过架构的调整之后，整个的平均响应时间反而增大了，通过对所有请求的响应时间的一个分析，
发现响应时间的分布比架构调整之前有改善，比如之前5ms的2000万次，现在4ms的2500万次．但是拖后腿的部分的请求比架构调整之前要多（比如之前
大于3s的有1000次，现在调整之后，大于3s的有2000次这样）．想问问章老师，整个的过程，．
下面是我其中一个接口的nginx的location的配置
upstream xxx {
#中间省略剩下的198个
}
upstream xxx_memc {
hash $arg_key consistent;
server x.x.x.x:11211;
server x.x.x.x:11211;
server x.x.x.x:11211;
server x.x.x.x:11211;
server x.x.x.x:11211;
server x.x.x.x:11211;
server x.x.x.x:11211;
server x.x.x.x:11211;
keepalive 1024;
}
location = /memc {
internal;
memc_connect_timeout 100ms;
memc_send_timeout 100ms;
memc_read_timeout 1000ms;
memc_ignore_client_abort on;
set $memc_key $arg_key;
set $memc_exptime $arg_exptime;
memc_pass xxx_memc;
}
location = /v4/play/detail {
access_by_lua_file conf/lua/xxx/check_pid.lua; #防刷限制的lua文件
set_by_lua_file $key conf/lua/xxx/cache_keys/common.lua; #生成memcached的key的lua文件
if ($http_is_update_cache = "Yes") {
srcache_fetch DELETE /memc key=$key;
}
set $exptime 1200;
srcache_fetch GET /memc key=$key;
srcache_store PUT /memc key=$key&exptime=$exptime;
srcache_store_statuses 200 301 302;
proxy_connect_timeout 1;
proxy_send_timeout 1;
proxy_read_timeout 3;
proxy_pass http://xxx;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $x_remote_addr;
proxy_set_header Host $proxy_host;
proxy_set_header Range $http_range;
proxy_set_header X-NginX-Proxy true;
}
