对于Share-Nothing架构的分布式数据库来说，如何将数据均匀的分布到各个节点、在线扩容，以获取更大的存储容量和更高的并发访问量。成为各大分布式数据库系统的一大挑战，今天我将对腾讯云数据库TBase的数据节点在线扩容方案做一个简单的分享。
为了迎接业务的快速增长，系统不可避免的需要进行扩容，传统的分布式数据库所采用hash(row)%nofdn，也就是说先对分布列计算hash值，然后使用这个值对节点个数取模来决定row存储在哪个节点。这里有一个致命的问题，扩容后节点数会变多，数据分布的计算逻辑会导致已经存在的数据无法正常访问。为解决这个问题，传统的分布式数据库必须把业务停掉，把所有数据导出，扩容后重新导入，在数据量较多时，这个过程可能会持续几天，这对于7*24小时的交易系统来说显然是不能接受的。为了解决这个问题，TBase引入了一种新的分表方案:sharded table。
TBase的数据分布采用如下的方式：
1. 引入一个中间层shard map,shard map中存储每一项shardid【通过hash(key)计算，key表示分布式键值】和DN的映射关系。
2. 分布式表中的每条记录通过hash(key)% #shardmap 来决定记录存储到哪个数据节点。
3. 每个数据节点上存储分配到本节点的shardid 信息，进而进行可见性判断。
如下图所示，当hash(key)=1时，此行数据会存放在DN001数据节点，当hash(key)=2时，此行数据存储在DN002数据节点上，以此类推。
这样做有什么好处呢？比如我们向default_group中新增加节点时，我们只需要把一些shardmap中的id映射到新加的节点，并把对应的数据迁移过去就可以了。
如下图所示，向default_group中新增数据节点DN003，那么只需要把DN001中的shardid=1和DN002中的shardid=4的数据迁移到DN003中，就可以实现数据的重新分布，并达到节点间数据平衡。
TBase的在线扩容过程：
1. 选择要迁移到新添加数据节点的shardid。
2. 通过shardid找到要迁移的数据，采取存量 增量的方式把数据迁移到新的数据节点。
3. 当新节点中的数据和数据源的数据达到一致时，切换协调节点(CN)中的shardmap信息，把shardid=3，shardid=4映射到DN003中（shardmap切换时数据库集群处于只读状态，该操作会在秒级完成）。
4. 数据清理，释放空间。如上图所示，清理DN001中shardid=3和DN002中shardid=4的数据。
