[性能] IP 定位缓存该如何做？-技术圈

背景

我们有一个站点服务，暴露 HTTP 接口，对接外部流量，类似网关。上线后发现 Full GC 频率比较高，老年代内存使用情况如下图。从图上可以看出平均 3个小时左右会进行一次 Full GC；内存逐步上升，说明每次 YGC 都有一些对象熬过了多次 YGC 并且晋升老年代；另外还可以注意到一点，夜里的时候增长速度比白天慢，说明和流量相关，请求越多，增长越快。那到底是什么对象可以不断的晋升老年代，而同时又可以被 Full GC 掉。

排查

先通过 jstat -gcutil 观察一下 GC 情况：

  S0     S1     E     O      M     CCS   YGC     YGCT    FGC   FGCT     GCT  4.00  0.00  94.34  21.54 93.44  87.29  28738 1107.341    53  18.695 1126.036  0.00  4.70   4.01  21.60 93.44  87.29  28739 1107.378    53  18.695 1126.073

可以看出 YGC 时会有一些对象晋升老年代。并且注意到 YGC 耗时 37ms，也比较长。

使用命令 jmap -histo 可以看出堆上类的统计信息，包含实例数量和占用内存。jmap -histo 有一个选项是live，如果添加了该参数，只会统计存活的对象，代价是进行一次 Full GC。如果没有添加该选项，就会统计当前全部的对象。

想看出哪些对象被回收了，可以在内存占用比较高的时候，分别执行两次 jmap -histo，第一次统计全部的对象，第二次触发 Full GC 只统计存活的对象，然后对比两份数据可以看出是哪些对象被回收了。

在线上进行上述操作，发现 LocalCache 相关的类从 600 多万变成了 100万整。存活对象的统计信息如下：

 num    #instances         #bytes  class name----------------------------------------------   1:        40514       89987016  [B   2:      1574061       78521184  [C   3:      1000000       48000000 com.google.common.cache.LocalCache$StrongAccessEntry   4:      1568771       37650504  java.lang.String   5:      1000000       16000000 com.google.common.cache.LocalCache$StrongValueReference

通过这个信息确定与使用 Guava Cache 相关，看下代码发现是 IP 定位缓存，服务会使调用方传递的 IP 调用公司内部服务获取地域编码，并且使用 Guava Cache 进行缓存，Cache创建代码如下，可以看到最大容量是 100万。

  CacheBuilder.newBuilder()    .expireAfterAccess(1, TimeUnit.HOURS)    .maximumSize(1000000)    .recordStats()    .build();

由于设置了 1 个小时的过期时间，所以不断的会有缓存过期，产生可回收的对象。到这里已经确认了问题出现在 IP 到地域编码的缓存上，那 IP到地域编码的缓存还有优化空间吗？

IP 定位属于基础服务，公司内部有很多调用方，所以缓存也是一个通用的问题。先找定位服务负责人请教一下缓存的经验，沟通未获取到缓存方面更好的实践，不过获取到两个很重要的信息，IP定位只用IP 的前三段，就是说1.12.36.0~1.26.36.255 都会定位到同一个地域编码；另外一个信息是国内记录数不到百万，这说明全量缓存是可行的。

解决方案

这个时候修改 Guava Cache 使用 IP 前三段作为 Key，可以实现全量缓存，可以想到结果就是命中率大幅提升，性能得到改进，但是还是会有垃圾产生。能不能优化的更彻底？

只使用三段，每段取值 256 ，那全量就是 256 * 256 * 256 = 16,777,216。可以创建一个三维 int 型数组，来存储 IP到地域编码的映射，占用内存为 64M，还是可以的。

这时还有一个问题就是过期时间怎么做，IP 到地域编码每天会有少量的调整，所以要实现一个过期机制。考虑到该过期时间为了保证缓存可以更新，所以可以直接使用写入时间，另外考虑到每天的调整很少，可以把过期时间设置的稍微长一点，这里给了四个小时。将三维 int 型数组调整为三维 long 型数组，高 32 位存储写入时间，低 32位存储地域编码。占用 128 M 内存，由于大数组是 Free GC 的所以 Full GC 的问题可以解决，另外就是数组的查找和读写性能都很好，所以对性能也有好处。这是一个空间换时间的实现。

最终缓存的实现如下：

public class FastIpLocalCache {   /**   * 过期时间，单位秒   */  private int expireTime;  private long[][][] store = newlong[256][256][256];  private int baseTime = (int)(System.currentTimeMillis() / 1000);   /**   * 过期时间，单位秒   *   * @param expireTime   */  public FastIpLocalCache(int expireTime) {    if (expireTime <= 0 || expireTime >24 * 60 * 60) {      throw newIllegalArgumentException("expireTime 不合法");    }    this.expireTime = expireTime;  }   /**   * 读取   *   * @param ip   * @return   */  public Integer get(String ip) {    if (ip == null) {      return null;    }    // IP 转数字    short[] s3 = toS3(ip);    if (s3 == null) {      return null;    }    // 读取    long value = store[s3[0]][s3[1]][s3[2]];    if (value <= 0) {      return null;    }    // 获取当前时间    int currentTimeSecond = (int)(System.currentTimeMillis() / 1000);    // 获取写入时间    int writeTime = (int) (value >> 32);    // 判断超时    if (currentTimeSecond - baseTime -writeTime > expireTime) {      return null;    }    // 获取地域    int local = (int) (value & 0x7fffffff);    return local;  }   /**   * 保存   *   * @param ip   * @param local   */  public void put(String ip, Integer local) {    // IP 转数字    short[] s3 = toS3(ip);    if (s3 == null) {      return;    }    // 获取当前时间    long current = System.currentTimeMillis() /1000 - baseTime;    // 拼接时间和地域    long value = current << 32 | local;    // 保存    store[s3[0]][s3[1]][s3[2]] = value;  }   /**   * IP 转数字，只转前 3 段   *   * @param ip   * @return   */  public short[] toS3(String ip) {    if (ip == null) {      return null;    }    short[] result = new short[3];    int index = 0;    int size = ip.length();    short temp = 0;    for (int i = 0; i < size; i++) {      char c = ip.charAt(i);      if (c >= '0' && c <= '9') {        temp = (short) (temp * 10 + (c - '0'));      } else if (c == '.' || (i + 1) == size) {        if (temp > 255 || temp < 0) {          return null;        }        result[index] = temp;        index++;        if (index == 3) {          break;        }        temp = 0;      } else {        return null;      }    }    if (index != 3) {      return null;    }    return result;  }}

效果

上线后老年代使用空间如下图，从图上可以看出 Full GC 频率已经从 3个小时左右变成了超过 24 小时一次，效果很明显。还会有晋升是因为我们还有一些埋点统计等。

再使用 jstat -gcutil 观察一些 GC 情况：

  S0    S1     E      O     M     CCS    YGC    YGCT    FGC    FGCT    GCT  0.00  2.55  96.28  16.74 91.98  84.94  18063 309.983     4    0.797 310.780  2.51  0.00   5.92  16.75 91.98  84.94  18064 309.997     4    0.797 310.794

可以看到 YGC 耗时变成了 14ms，相比最开始的 37ms 也有了大幅的提升。

全量缓存以及更长的缓存时间也大幅减少了对 IP 定位服务的调用量，从 12000 QPS 下降到 2400 QPS。

更高效的缓存定位方案也会减少服务的平均耗时，从平均 11 ms，下降到平均 10ms。虽然只有 1ms，但是比例接近 10%。

[性能] IP 定位缓存该如何做？

背景

排查

解决方案

效果

推荐阅读