网络操作的性能优化

2015-01-26 本文已影响260人军哥ye话

某产品由于某些因素（运营，版本更新及体验等）使得活跃用户及停留时间不断提高，进而使得服务器资源使用增长，原先设定的报警阈值频繁被触发，具体表现为：
- web机器的load与cpu使用都变高
- 依赖的缓存服务redis连接数与cpu不断攀升
- rpc(用于业务分离)的连接数不断攀升

仔细分析stack dump中有相似stackstrace的线程，发现对缓存的操作有不少shit的逻辑：
- "同样的数据取两次"——如：interceptor中会对同一个user对象获取两次
```
e.g.:
User user = userRpcServer.getUser(uid);
// 一些业务逻辑
boolean isForbidderUser = userRpcServer.isForbidderUser(uid);
```
  - 从上面看并没有直接问题，但仔细分析会发现userRpcServer.isForbidderUser(uid)中还会调用一次getUser(id)
- "取到了数据却不用"——如：获取User对象时同时获取其帐启余额，但只有与帐户相关的请求才需要获取余额，大多数接口不需要
```
UserAccount userAccount = userRpcServer.getUserAccount(uid);
UserInfo userInfo = userRpcServer.getUserInfo(uid);
User user =  makeUser(userAccount, userInfo);
```
- "已经知道缓存中不存在数据了，却还去取"——因为调用栈较长，所以隐藏的比较深，限于篇幅，暂不举例。但也正因为隐藏的较深，才造成了资源的浪费不太轻易被发现。
- "有大量用for循环对redis做网络操作的逻辑"——如：根据userIds获取users
```
for(uid : uids) {
    users.add(redisServer.getUser(uid))
}
```
  - 这样的逻辑应该尽量用批量操作的方式去完成
分析redis slow log, 找出其中耗时和频繁的操作（尤其是删除操作），发现有一些优化的空间——此前已做过一次slow log对应key的优化，所以这次在这方面没做太多事情。