题外话：

笔者就职于某上市游戏发行公司，主导整个发行业务线从双 IDC 到腾讯云的搬迁。在此过程中踩了不少坑，便以文章的形式记录下来。

如有错漏之处，敬请指正。

我先简单介绍下我自己：

我是业务开发出身，负责渠道登录/支付业务，熟悉前端，研究后台开发框架后，逐步往运维方向摸索。

业务除了登录/支付业务，也做过风控系统、聊天监控系统，主要是一些防刷保护、敏感词判别、垃圾信息过滤等等。

本系列篇幅较长，共有 7 篇文章，本文是第 4 篇。文章列表：

某上市游戏公司从 IDC 上腾讯云的落地经验（1）——上云必要性与方案设计
某上市游戏公司从 IDC 上腾讯云的落地经验（2）——方案实施之接入层上云
某上市游戏公司从 IDC 上腾讯云的落地经验（3）——方案实施之应用层上云
某上市游戏公司从 IDC 上腾讯云的落地经验（4）——方案实施之缓存层上云
某上市游戏公司从 IDC 上腾讯云的落地经验（5）——方案实施之数据层上云
某上市游戏公司从 IDC 上腾讯云的落地经验（6）——方案实施之中间件上云
某上市游戏公司从 IDC 上腾讯云的落地经验（7）——总结与回顾

缓存层上云

缓存，业务主要使用 Redis 和 Memcached 两大组件。

• Memcached 数据量非常小（几十兆，大部分是登录态缓存），我们没有做数据搬迁，直接切换 DNS 解析上云。

• Redis 做了一次主从切换，切换前我们参考了 Go 常见的错误信息，对 PHP 的操作类做了重连处理，保证切换过程无损。

  • 对于部分业务没有改造的不支持重连的，可以配合 CLIENT LIST 和 CLIENT KILL 命令，关闭连接使其重连。
  • 多次 KILL 不掉的业务，我们最终排查发现有台机器绑定了 hosts 到 IDC 机房，此时去掉之后也成功切过去了。

注：切换 DNS 解析，需要留意 TTL，内网 DNS 可以缩短到秒级，具体看业务体量和 DNS 服务器的承载量。

附：go-redis 的重试逻辑：

// github.com/go-redis/redis/[email protected]/error.go:27
func shouldRetry(err error, retryTimeout bool) bool {
    switch err {
    case io.EOF, io.ErrUnexpectedEOF:
        return true
    case nil, context.Canceled, context.DeadlineExceeded:
        return false
    }
    if v, ok := err.(timeoutError); ok {
        if v.Timeout() {
            return retryTimeout
        }
        return true
    }
    s := err.Error()
    if s == "ERR max number of clients reached" {
        return true
    }
    if strings.HasPrefix(s, "LOADING ") {
        return true
    }
    if strings.HasPrefix(s, "READONLY ") {
        return true
    }
    if strings.HasPrefix(s, "CLUSTERDOWN ") {
        return true
    }
    return false
}

总之，缓存这块的上云风险应该是比较低的。

不管怎样，业务都不应该强依赖缓存，如果强依赖，也不是缓存了，而是数据。

我们通过 某上市游戏公司从 IDC 上腾讯云的落地经验（1）——上云必要性与方案设计 提及的神器 packetbeat，配合 Elasticsearch，可以清晰的知道 Redis 具体执行的命令、来源 IP 地址。

开发惊讶地看到自己业务的 Redis 操作可以搜索、过滤，也是兴奋不已，大呼神奇！既然知道它执行了什么命令，用法有误的，该整改就整改。

今天就先写到这里，下一篇继续写数据层上云。感谢您的阅读：）