实际：如何抉择分区键
方才咱们说，咱们心愿在创立表的时候业务参加进行表结构设计的时候，能考虑一下分区键的抉择。如何抉择分区键呢？这里依据几种类型来简略介绍一下。
如果是面向用户的互联网利用，咱们能够用用户对应的字段，比方用户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数据库工作组下三大产品系之一，是一款腾讯自研的金融级分布式数据库产品，目前广泛应用于金融、政务、物联网、智慧批发等行业，领有大量的分布式数据库最佳实际。