题外话:

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

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

我先简单介绍下我自己:

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

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

本系列篇幅较长,共有 7 篇文章,本文是第 5 篇。文章列表:

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

数据层上云

由于缓存层上云时在 /etc/hosts 文件踩过小坑,后面我们把生产环境上所有绑定 hosts 的业务都整理了一次。

数据层主要是 Redis、MySQL 这两个组件。

a. 先说 Redis ——

Redis 大部分可以参考上一篇文章 缓存层上云最主要的是业务的重试,还有踢除客户端的自动化脚本

数据层需要保证数据的一致性,可以在切换之前简单核对一下 KEY 的数量,或者使用脚本 SCAN 校验。

如果是云厂商的 DTS 同步工具,一般都会自动检查。

我们的 Redis 集群没有使用云产品,使用社区版自己购买虚拟机搭建。

集群与集群的数据同步,使用阿里开源的 RedisShake,测试非常稳定,生产环境下也切换过,没有出现不一致的情况,非常推荐使用。

成本上节省了 DTS 的费用,维护难度也不高。

b. 再说 MySQL ——

MySQL 上云我们采用腾讯云提供的 DTS 同步工具,在后台配置好并同步完成后,数据将实时与 IDC 保持一致,此时也是切换 DNS 解析即可(不要忘了上面提及的重连机制)。

得益于云厂商强大的数据同步和校验,数据层的搬迁非常顺利,没有任何故障产生,DBA 同事也非常细心,合作流程非常丝滑:)

今天就写到这,下次写中间件上云(RabbitMQ)。感谢您的阅读:)

暂无评论