亿级流量下平滑扩容(TDSQL水平扩容 VS 垂直扩容)
数据库水平扩容的背景和挑战
首先我们看水平扩容的背景。扩容的原因其实非常直观,一般来说主要是随着业务的访问量,或者是需要的规模扩大,而现有的容量或者性能满足不了业务的需求,主要表现在TPS、QPS不够或者时延超过了业务的容忍范围,或者是现有的容量不能满足要求了,后者主要是指磁盘或者网络带宽。一般碰到这种问题,我们就要扩容。扩容来说,其实比较常见的就是两种方式,一种是垂直扩容,一种是水平扩容。这两种有不同的特点,优缺点其实也非常明显。
1.1 水平扩容 VS 垂直扩容
首先我们看一下垂直扩容。垂直扩容,主要是提高机器的配置,或者提高实例的配置。因为,我们知道,大家在云上购买一个数据库或者购买一个实例,其实是按需分配的,就是说对用户而言,可能当前的业务量不大,只需要两个CPU或者是几G的内存;而随着业务的增长,他可能需要对这个实例进行扩容,那么他可能当前就需要20个CPU,或者是40G的内存。这个时候,在云上我们是可以通过对资源的控制来动态地调整,让它满足业务的需求——就是说可以在同一台机器上动态增加CPU。这个扩容的极限就是——当整台机器的CPU和内存都给它,如果发现还不够的话,就需要准备更好的机器来进行扩容。这个在MySQL里面可以通过主备切换:通过先选好一台备机,然后进行数据同步;等数据同步完成以后,进行主备切换,这样就能利用到现在比较好的那台机器。大家可以看到,这整个过程当中,对业务来说基本上没有什么影响——进行主备切换,如果换IP的话,其实是通过前端的或者VIP的方式,对业务来说基本上没有什么影响。那么它一个最大的不好的地方就是,它依赖于单机资源:你可以给它提供一个更好的机器,从而满足一定量的要求。而随着业务更加快速的发展,你会发现现在能提供的最好的机器,可能还是满足不了,相当于扩不下去了。因此,垂直扩容最大的缺点就是,它依赖于单机的资源。
跟垂直扩容对比,另外一种方式我们叫水平扩容。水平扩容最大的优点是解决了垂直扩容的问题——理论上水平扩容可以进行无限扩容,它可以通过增加机器的方式来动态适应业务的需求。
水平扩容和垂直扩容相比,它可以解决垂直扩容的问题,但是会引入一些其他的问题。因为水平扩容比垂直扩容更加复杂,下面我们分析下可能遇见的问题,以及后面我们会介绍TDSQL的解决方案:
首先,在垂直扩容里面,系统经过扩容以后,其实数据总体来说还是存在一个节点,一主多备架构中,备机上也存储着所有数据。而水平扩容过程中数据会进行拆分,面临的第一个问题是,数据如何进行拆分?因为如果拆分不好,当出现热点数据时,可能结果就是,即使已经把数据拆分成很多份了,但是存储热点数据的单独节点会成为性能瓶颈。
第二点,在整个水平扩容过程中,会涉及到数据的搬迁、路由的改变。那么整个过程中能否做到对业务没有感知?或者是它对业务的侵入性大概有多少?
第三,在整个扩过程中,因为刚才有这么多步骤,如果其中一步失败了,如何能够进行回滚?同时,在整个扩容过程中,如何能保证切换过程中数据高一致性?
再者,在扩容以后,由于数据拆分到了各个节点,如何能保证扩容后的性能?因为理论上来说,我们是希望我随着机器的增加,性能也能做到线性提升,这是理想的状态。实际上在整个水平扩容的过程中,不同的架构或者不同的方式,对性能影响是比较大的。有时候会发现,可能扩容了很多,机器已经增加了,但是性能却很难做到线性扩展。
同样的,当数据已经拆分成多份,我们如何继续保证数据库分布式的特性?在单机架构下,数据存储一份,类似MySQL支持本地做到原子性——可以保证在一个事物中数据要么全部成功,要么全部失败。在分布式架构里,原子性则只能保证在单点里面数据是一致性的。因此,从全局来说,由于数据现在跨节点了,那么在跨节点过程中怎么保证全局的一致性,怎么保证在多个节点上数据要么全部写成功,要么全部回滚?这个就会涉及到分布式事务。
所以大家可以看到,水平扩容的优点很明显,它解决了垂直扩容机器的限制。但是它更复杂,引入了更多的问题。接下来大家带着这些问题,下面我会介绍TDSQL如何进行水平扩容,它又是如何解决刚才说的这些问题的。
2 TDSQL水平扩容实践
首先我们看一下TDSQL的架构。TDSQL简单来说包含几部分:
第一部分是SQL引擎层:主要是作为接入端,屏蔽整个TDSQL后端的数据存储细节。对业务来说,业务访问的是SQL引擎层。
接下来是由多个SET组成的数据存储层:分布式数据库中,数据存储在各个节点上,每个SET我们当做一个数据单元。它可以是一主两备或者一主多备,这个根据业务需要来部署。有些业务场景对数据安全性要求很高,可以一主三备或者一主四备都可以。这个是数据存储。
还有一个是Scheduler模块,主要负责整个系统集群的监控、控制。在系统进行扩容或者主备切换时,Scheduler模块相当于是整个系统的大脑一样的控制模块。对业务来说其实只关注SQL引擎层,不需要关注Scheduler,不需要关注数据是怎么跨节点,怎么分成多少个节点等,这些对业务来说是无感知的。
整个扩容流程大家可以看一下:一开始数据都放在一个Set上,也就是在一个节点里面。那么扩容其实就是会把数据扩容到——这里面有256个Set,会扩容到256台机器上。整个扩容大家可以看到有几个要点:
一开始虽然数据是在一个节点上,在一台机器上,但是其实数据已经进行了拆分,图示的这个例子来说是已经拆分成了256份。
水平扩容,简单来说就是把这些分片迁移到其他的Set上,也就是其他的节点机器上,这样就可以增加机器来为提供系统性能。
总结起来就是说,数据一开始已经切分好了,扩容过程相当于把分片迁到新的节点,整个扩容过程中,节点数是增加的,可以从1扩到2扩到3,甚至扩到最后可以到256,但是分片数是不变的。一开始256个分片在一个节点上,扩成两个节点的话,有可能是每128个分片在一个节点上;扩到最后,可以扩到256个节点上,数据在256台机器,每台机器负责其中的一个分片。因此整个扩容简单来说就是搬迁分片。具体细节我们后面会讲到。
在私有云或者是公有云上,对整个扩容TDSQL提供了一个统一的前台页面,用户在使用的过程中非常方便。
我们看一下这个例子。现在这个案例中有两个Set,也就是两个节点,每一个节点负责一部分的路由,第一个节点负责0-31,另一个名字是3,负责的路由信息是32-63。现在是两个节点,如果要进行扩容,在前台页面上我们会有一个“添加Set”的按纽,点一下“添加Set”,就会弹出一个对话框,里面默认会自动选择之前的一个配置,用户可以自己自定义,包括现在这个Set,需要多少资源以及内存、磁盘的分配等。
文章图片
此外,因为扩容要进行路由切换,我们可以手动选择一个时间,可以自动切换,也可以由业务判断业务的实际情况,人工操作路由的切换。这些都可以根据业务的需要进行设置。
第一步创建好以后,刚才说大脑模块会负责分配各种资源,以及初始化,并进行数据同步的整个逻辑。最后,大家会看到,本来第一个节点——原来是两个节点,现在已经变成三个节点了。扩容之前,第一个节点负责是0-31,现在它只负责0-15,另外一部分路由由新的节点来负责。所以整个过程,大家可以看到,通过网页上点一下就可以快速地从两个节点添加到三个节点——我们还可以继续添加Set,继续根据业务的需要进行一键扩容。
【亿级流量下平滑扩容(TDSQL水平扩容 VS 垂直扩容)】
文章图片
推荐阅读
- 开学第一天(下)
- 【故障公告】周五下午的一次突发故障
- 生活随笔|好天气下的意外之喜
- MongoDB,Wondows下免安装版|MongoDB,Wondows下免安装版 (简化版操作)
- 汇讲-勇于突破
- Android中的AES加密-下
- 说的真好
- 放下心中的偶像包袱吧
- Linux下面如何查看tomcat已经使用多少线程
- 【1057快报】深入机关,走下田间,交通普法,共创文明