TcaplusDB有损搬迁介绍
TcaplusDB搬迁分为有损搬迁和无损搬迁，有损是指搬迁过程中对外服务有损。
*应用场景*
? 存储层扩容
? 存储层缩容
? 设备搬迁
? shard搬迁
*TcaplusDB架构*
*数据分片模型*
TcaplusDB中会把每张表分成N个shard， shard分布在1个或多个tcapsvr节点上。 根据key计算hash得到对应的shardID。 计算方式：
hash_code = hash(keys) % 10000
| Range | ShardID |
|---|---|
| 0-2000 | 101 |
| 2001-4000 | 102 |
| 4001-6000 | 103 |
| 6001-8000 | 104 |
| 8001-10000 | 105 |
一个表通过hash分表，按照路由数组长度（默认为10000）进行取模运算分片(Mod Sharding)，所以每张表最多可以分成10000个分片(Shard)。以下图为例，1个TcaplusDB表被分为5个shard文件分布到不同存储节点，每个结点分布有1个或多个分片的数据。
*数据访问流程*
GameSvr通过API访问tcaproxy，在tcaproxy中根据key计算出对应的hash值获取路由信息，把请求转发到对应的tcapsvr上。
*搬迁方案*
在业界中，主要有两种数据搬迁方案。
1、先搬迁数据，再切换路由信息。5
2、先切换路由信息，再搬迁数据。
| 方式 | 优势 | 不足 | 难点 |
|---|---|---|---|
| 先搬后切 | 容错性强，状态一致，搬迁过程可随时回退，天然支持所有操作。 | 搬迁过程中不能很快降低源端的负载 | 搬迁过程中的写操作如何同步到目的端 |
| 先切后搬 | 快速分流，可以很快降低源端的负载。 | 容错性差，搬迁过程中不能回退 | 如何在搬迁过程中支持各种请求 |
*业界数据搬迁方式*
| *数据库* | Sharding方式 | *搬迁方式* | *实现步骤* | *优缺点* |
|---|---|---|---|---|
| MySQL | 单机 | 先搬后切 | 裂变扩容 | 有损 |
| MongoDB | key range/hash | 先搬后切 | ①先搬迁 ② binlog同步 ③ 拒绝请求，刷新并切换路由 | 路由更新状态有损 |
| Redis | hash | 客户端路由切换 | ① 搬迁slot ② 请求访问源端slot，没找到数据，返回ASK转向，请求目的端 ③ 该slot若已搬迁完成则更新客户端路由 | 无损，但影响服务性能 |
| TDSQL | hash | 先搬后切 | ① dump所需要数据，搬迁到目的端； ② binlog同步，最后拒绝请求，更新路由 | 路由更新状态有损 |
*TcaplusDB 搬迁方式*
| 搬迁 | 搬迁方式 | 优点 | 应用场景 |
|---|---|---|---|
| 有损搬迁 | 先切后搬 | 能够尽快降低源端的负载，以及避免在搬迁完成时还需要同步写操作到目的端 | 扩容、缩容、设备搬迁、shard搬迁 |
| 无损搬迁--逻辑搬迁 | 先搬后切 | 搬迁过程中业务不感知。搬迁记录数据，搬迁以后能有效减少存储引擎存储空洞率。 | 扩容、缩容、设备搬迁、shard搬迁 |
| 无损搬迁--物理搬迁 | 先搬后切 | 搬迁速度快，减少序列化操作。搬迁速度是逻辑搬迁几倍。 | 设备搬迁，shard搬迁 |
*有损搬迁*
TcaplusDB的有损搬迁为了能够尽快降低源端的负载，以及避免在搬迁完成时还需要同步写操作到目的端，采用了先搬后切的方式。
路由状态的转换由tcapcenter控制，并通知到tcaproxy，路由状态转换为：
*normal--> wait --> reject --> sync --> normal*
*搬迁过程的路由状态*
| *路由状态* | 含义 | *存在意义* |
|---|---|---|
| normal | 正常情况下的路由状态 | 正常情况下的路由状态 |
| wait | 等待搬迁的路由 | 数据搬迁是一个事务，tcapcenter在初始化该事务时，会生成所有需要搬迁的路由，wait状态就是表示这些路由处于等待搬迁状态，该状态下请求包将由源端处理 |
| reject | 拒绝到搬迁路由的所有请求，并进行染色 | 保证数据一致性 |
| sync | 路由正处于数据搬迁中 | 该状态下，就表示请求包应该由目的端处理 |
*为什么需要Reject状态*
假设由wait状态直接转变为sync状态，tcaproxy到源端svr的通道中仍然存在写请求未被处理：
1、源端svr将key对应的记录搬迁到目的端svr
2、源端svr处理通道中的记录更新请求
3、由于是sync状态，tcaproxy会到目的端svr获取
按照该流程，如果没有reject状态的话，proxy会读取记录的旧数据。
*搬迁过程的请求处理*
1、tcaproxy收到请求包之后，检测所请求的记录是否在目的端tcapsvr
若存在目的端tcapsvr，转 步骤4；
若不存在目的端tcapsvr， 转 步骤2；
2、tcaproxy向源端tcapsvr拉取所请求的记录
3、tcaproxy将拉取回来的记录写入到目的端
4、tcaproxy将gamesvr的请求发送给目的端tcapsvr进行处理
*搬迁速度控制*
搬迁过程中使用滑动窗口的方式控制搬迁速度
? pending buffer默认长度为1000，实际表征了并发量
? 指定时间内无ack则重传
? 目的端返回busy，则按照重试策略重试
时间分段
宏观时间
? 23:00 - 07:00， 业务低峰期，搬迁速度可以提高
? 07:00 - 23:00， 业务主要服务时间，搬迁速度可以降低
微观时间
? 以10ms作为粒度，将每秒速度平均分配到100个10ms，从而使搬迁速度更加平滑
TcaplusDB是腾讯出品的分布式NoSQL数据库，存储和调度的代码完全自研。具备缓存+落地融合架构、PB级存储、毫秒级时延、无损水平扩展和复杂数据结构等特性。同时具备丰富的生态、便捷的迁移、极低的运维成本和五个九高可用等特点。客户覆盖游戏、互联网、政务、金融、制造和物联网等领域。