TDSQL水平扩容实践案例

实践：如何选择分区键

刚才我们说，我们希望在创建表的时候业务参与进行表结构设计的时候，能考虑一下分区键的选择。如何选择分区键呢？这里根据几种类型来简单介绍一下。

如果是面向用户的互联网应用，我们可以用用户对应的字段，比如用户ID，来做分区键。这样保证在拥有大量用户时，可以根据用户ID将数据拆分到各个后端节点。

游戏类应用，业务的逻辑主体是玩家，我们可以通过玩家对应的字段；电商应用的话，可以根据买家或者卖家的一些字段来作为分区键。物联网的则可以通过比如设备的ID作为分区键。选择分区键总体来说就是要做到对于数据能比较好地做进行拆分，避免最后出现漏点。也就是说，通过这个分区键选择这个字段，可以让数据比较均衡地分散到各个节点。访问方面，当有比较多SQL请求的时候，其实是带有分区键条件的。因为只有在这种情况下，才能更好地发挥分布式的优势——如果是条件里面带分区键，那这条SQL可以直接录入到某一个节点上；如果没有带分区键，就意味着需要把这条SQL发到后端所有节点上。

这个大家可以看到，如果水平扩容到更多——从一个节点扩到256个节点，那某一条SQL写不好的话，可能需要做256个节点全部的数据的聚合，这时性能就不会很好。

总结来说，我们希望业务在创建表，在设计表结构的时候尽量参与进来。因为不管是聚合函数或者是各种事务的操作，其实对业务基本上属于无感知，而业务这时参与则意味着能够换来很大的性能提升。

实践：什么时候扩容？

我们什么时候扩容？在TDSQL里面，我们会有大量的监控数据，对于各个模块我们在本地会监控整个系统的运行状态，机器上也会有各种日志上报信息。基于这些信息，我们可以决定什么时候进行扩容。

简单来说，比如磁盘——如果发现数据磁盘使用率太高，这个时候可以进行扩容；或者SQL请求，或者CPU使用率接近100%了——目前基本假如达到80%使用率就要进行扩容。还有一种情况是，可能现在这个时候其实请求量比较少，资源使用比较充足，但如果业务提前告诉你，某个时候将进行一个活动，这个活动到时候请求量会增长好几倍，这个时候我们也可以提前完成扩容。

下面再看几个云上的集群案例。这个大家看到，这个集群有4个SET，每个SET负责一部分的shardkey，这个路由信息是0-127，意思是它最后能扩到128个节点，所以能扩128倍。这个“128”可以由初始化的业务预估先定下来。因为如果池子太大的话，的确最后可以扩到几千台，但是数据将比较散了。事实上今天每台云上的或者实际的机器性能已经非常好，不需要几千台的规格。

这是另外一个集群——它的节点数会多一点，有8个节点，每个节点也负责一部分的路由信息。这个数字只有64，所以这个最后可以扩到64个节点。这个是云上的相关例子。

分享主要是这些内容，大家如果有什么问题欢迎评论留意。

Q&A：
Q：没扩容之前的SET里面的表都是分区表，问一下是不是分区表？

A：是的，在没扩容之前，相当于在这个，简单说我们现在就一个节点，那么我们告诉他256，这个值我们在进行初始化的时候就定下来的。而且这个值集群初始化以后就不会再变了。假设我们这个集群定了一个值是256——因为他可能认为这个数据量后面会非常非常大，可以定256。这个时候，数据都在一个节点上。这个时候用户，按照我们刚才的语法创建了一个表，这个表在底层其实是分成256份的。所以他即使没有进行扩容，它的数据是256份。再创建另外一个表，也是256份。用户可能创建两个表，但是每个表的底层我们有256个分区的，扩容就相当于分区把它迁到其他的地方去。

Q：各个节点的备份文件做恢复时如何保证彼此之间的一致性？

A：各个节点之间没有相互关系，各个节点自己负责一部分的路由号段，只存储部分数据，水平扩容只负责一部分数据，它们之间的备份其实是没有相互的关系，所以这个备份其实是之间不相关的。每个节点我们可能有一主两备，这个其实是我们有强同步机制，在复制的时候来保证数据强一致性。大家可以参考之前的分享里面会比较详细介绍TDSQL在单个节点里面TDSQL一主多备架构是如何保证数据的强一致性的。

Q：两阶段在协调的时候能避免单点故障吗？

A：首先在两阶段提交的时候，我们是用SQL引擎做事务的协调，这个是单个的事务。如果其他的连接发过来，可以拿其他的SQL引擎做事务协调期。而且每个SQL引擎是做到无状态的，可以进行水平扩展。所以这个其实是不会有太多的故障，我们可以根据性能随机扩展的，可以做到性能的线性增长，没有中心化。日志这些都是被打散的，记日志也会记到TDSQL后端的数据节点里面，一主多备，内部保证强一致性，不会有单点故障。

TDSQL是腾讯TEG数据库工作组下三大产品系之一，是一款腾讯自研的金融级分布式数据库产品，目前广泛应用于金融、政务、物联网、智慧零售等行业，拥有大量的分布式数据库最佳实践。