在大量请求发生的情况下，缓存本身设计已经足够的快速，这时候你会发现性能瓶颈已经不在于缓存读取上面了，而在于往返的请求。假如有如下一段代码：
public string getUserInfo(int userId){
UserInfo userInfo=redis.getUserInfo(userId);
int followCount=redis.getFollowCount(userId);
int fansCount=redis.getFansCount(userId);
int skuCount=redis.getSkuCount(userId);
JsonObject result=new JsonObject();
result.add(“user",gson.toJson(userInfo));
result.add("followCount",followCount);
result.add("fansCount",fansCount);
result.add("skuCount",skuCount);
return result.toString();
}
这个api中访问了4次redis，因为每个变量都存储在不同的业务和redis db中，这样在返回用户相关信息的时候，需要多次从redis读取数据，读取数据的过程类似tcp/ip握手，在下一次命令请求发起的时候，必须等到上一次命令返回。
考虑上述代码发生的一个场景，由于做了活动，导致pc端和手机端都需要大量请求获取用户信息api，假设10w的请求打到了getUserInfo api上，那么会发生多少次请求，getUserInfo一共访问了4个变量，所以请求量就是40w ，所以在大量请求的情况下，性能瓶颈就产生了，大量的请求导致耗时。
非常幸运的是，redis本身提供了管道命令，管道命令的原理就是通过把命令打包，合并请求，将多次请求作为一次发送，这样可以有效节省请求时间，这个命令在大量请求的情况下非常有用。getUserInfo api用管道命令可以减少3/4的请求量。此外，管道命令还适合在复杂的业务中，多次操作redis的情况。这好比搬家的时候，你没有工具，每次只能依靠自己的手，每次搬少量的东西，这样每次往返，这样必然导致搬家的时间延长，如果你有工具，可以一次搬很多东西，这样就能有效的减少搬家的时间。
网友评论