背景

手游爆发

2015年,当时是整个手游市场的萌芽期,蓄势待发。在游戏存储上,IEG CROS DBA团队一般推荐使用redis+mysql这样的组合,来满足缓存和存储的不同需求,同时这也是最主流和广泛的使用方式。

但在业务的接入过程中,我们发现有不少代理游戏原来使用纯redis的架构,就是直接使用redis作为存储。当业务正式接入腾讯平台时,业务开发必须将业务逻辑修改为redis+mysql的方式,并需要小心翼翼地处理缓存和存储的一致性问题。

由于redis是一个缓存,用来直接存储用户数据是不可靠而且成本太高,所以开发不得不修改为redis+mysql。感受得到,业务开发并不是十分愿意,也加长了一定的开发周期。

因此,我们就考虑,如果有一个redis协议的存储来替代mysql,这种业务的接入门槛是不是能迅速降低?

成本考虑

2015年,腾讯云已经负责了较多了redis缓存业务。随着业务的不断接入,数据量越来越大,也发现不少业务把redis直接当成了存储,QPS和访问延时其实并不高。这个时候,基于纯内存的redis成本就显得太高,并且存在浪费。redis的存储版需求也越来越强。

tendis开发的初衷,就来源于此。

立项 & 迭代

第一代tendis,内部称为Tendis SSD

  • 2015-4-1 正式立项,基于redis-2.8.17,存储引擎选择rocksdb
  • 2015-8-14 v1.0发布,支持基本数据结构的落地
  • 2016-1-19 v1.1发布,支持binlog增量同步和备份等
  • 2016-4-13 v1.2发布,bug修复,物理备份改进、基于物理备份的slave重做、key数量的统计,slave断开后的重连控制
  • 2016~2017 v1.2版本不断迭代
  • 2018-4-24 v1.3发布,升级rocksdb,解决zset占用大量内存的问题,优化大key删除效率太低的问题。

业务接入

在版本迭代过程中,不断的业务接入,成为游戏业务和平台业务的主存储。

升级Tendis存储版

Tendis SSD是基于单线程的redis改造而来,本质上是一个单线程的架构。从过去几年的运营过程中,出现了一些问题:

  • 删除大key导致全局阻塞
  • 过期数据清理不够及时,甚至影响业务
  • 高可用、扩缩容强依赖管控系统
  • 受限于单线程架构,部分运维指令实现并不方便,运维成本较高

因此,实现一个多线程的tendis变得尤其重要。于是,我们重写了一个Tendis存储版.

  • 2018-8-4 正式立项,设计&实现
  • 2019-5-10 tendisX冷热混合存储项目启动,Tendis存储版需要适配混存和纯存储两个场景,部分模块重新设计
  • 2019-7-20 tendisplus内部版发布,内部灰度和小规模验证
  • 2020-7-14 tendisplus-1.0 发布,实现基于key锁的并发控制,完全兼容redis。(与Tendis ssd的不同
  • 2020-8-13 tendisplus-2.0发布,实现基于去中心化集群化方案,目前已知第一个支持去中心化架构的redis存储方案。并支持tendisX冷热混合存储n:m架构。
  • 2020-11-20 tendisplus-2.1发布,性能提升50%,支持tendisX key降冷能力。