关注腾讯云开发者，一手技术干货提前解锁👇
01
背景
国内云厂商从2010年左右正式推出云服务开始，关系数据库作为核心产品，18年以前聚焦于传统关系型数据库如何更好的上云托管，提供开箱即用，以及企业级的高性能、高可靠、高稳定的能力。随着泛互联网的持续发展，云计算提供开箱即用的基础设施，帮助企业快速搭建业务无需考虑基建，加速迁移上云，完成云数据库规模极大增长，特别是大众创业，万众创新后，中小用户规模急剧增加。此时，基于各项 PaaS 设施的成熟，进一步推动数据库在成本、弹性、服务质量上的突破，云原生数据库 TDSQL-C 应运而生，应云而生。以上是数据库的简要发展历程，下面以多年业务后台开发的角色，分享自己对如何用好数据库的理解，如有不足欢迎大家指正。
02
如何用好数据库
如何扩展数据库的读写性能？
数据库的扩展可以分为横向扩展和垂直扩展，基于传统的物理机架构，计算和存储资源绑定，扩展存在以下痛点：
规格扩容（垂直扩展），本机资源不足导致跨机扩容，耗时久，需要数小时：因物理机架构下，数据存储在本台机器，在实例进行规格的扩容，但是本机资源不足的情况，需要将实例迁移到其他资源充足的机器，数据需要迁移到目标机器，数据量越大，跨机器数据复制耗时越久；
添加只读节点（横向扩展），耗时久，需要数小时：物理机架构下，每个实例的节点都有独立的数据存储，当添加新节点时，需要将主节点的数据复制到新的节点。常规情况下，需要满足容灾部署模型（节点的反亲和性控制策略），一个数据库实例的 主节点、只读节点、从节点 不允许分布到同一台物理机器，所以添加只读节点会涉及跨机器的数据复制，数据量越大耗时越久；
云原生数据库 TDSQL-C 通过对数据库架构升级，基于计算存储分离 + 分布式共享存储架构，使得在计算资源不足（CPU/内存）时无论是纵向或者横向扩展都无需搬迁数据，这样大大降低了数据库扩容的耗时；存储资源不足时，基于分布式共享存储，可以做到秒级别的扩容。
随着业务对读写并发性能要求越来越高，只读节点的横向扩容有效分担读负载，越来越多的企业会使用多节点的部署模式。虽然云原生数据库存算分离架构很好的解决了添加节点的时效问题，但在实际的应用中，仍然存在以下不足：
每个节点独立提供服务，可能因业务流量不均，部分节点负载高，部分节点负载很低，资源无法有效利用；
一个只读节点故障会直接影响业务访问，高可用能力不足；
多个节点在查询同一条记录时，可能由于主从复制延迟的差别，数据在多个节点上的更新时间有先有后，导致业务在多个节点同时读取到的数据不一致，可能对某些敏感业务不友好；
事务内有大量读请求需要直接访问主节点，主节点的负载压力大；
基于上面的不足演进出数据库代理（Proxy），通过提供统一的访问入口，支持多种负载均衡的策略、多种一致性策略、事务拆分等来解决以上难题。
自适应负载均衡，最大化利用资源
常规的数据库代理会支持按照业务自行配置权重，以及自动权重的两种策略，可以帮助业务做到读的均衡。但是，在实际应用场景中仍然存在资源分配不均的问题（涝的涝死，旱的旱死），有的节点资源不足导致大量慢查询，有的节点资源负载低空闲。例如：客户进行了一个很复杂的大查询，当这个请求转发到只读节点 A，会导致节点 A 的消耗大量资源，基于请求权重的衡策略仍然会按照请求数均衡的方式将新请求转发到 A 节点，这样就会导致 A 节点访问缓慢，出现大量大查询等。究其原因，客户的每个业务请求、每个连接所消耗的资源是无法度量和预测的，所以仅基于客户侧的单一的信息很难做到好的均衡。基于这个痛点，我们进一步演进，引入了只读节点实时性能反馈机制，持续通过动态机制来保障业务的负载均衡，对比业界常规的按请求、按连接的静态均衡策略，能够更好的做到最佳的均衡。例如：上面的 Case，当 A 节点资源负载过高的时，数据库代理此刻可感应到 A 节点的信息，减少请求分配到 A 节点，从而减少 A 的负载压力，以此来保障数据库的响应速度。
一致性策略，满足不同场景对数据的一致性访问诉求
基于数据库代理的读写分离功能会识别不同的语句，将 DDL、DML 等写入的语句会通过主节点执行，读语句会通过只读节点执行，当有多个只读节点同时读取同一个数据 或者 主节点刚写入立马进行查询的场景，可能由于只读节点还未同步主节点的写入 后者 多个只读节点同步主节点的延迟不一样，导致从只读节点的读取数据不是最新版本，从而带来一致性问题。
例如：一主三只读的节点，每次从主节点更新 num，从1更新到30，可能由于三个只读节点的业务负载、网络延迟等原因，更新 num=30的延迟不一致，导致业务从主节点和3个从节点读取 num 的值不一样。
数据库代理通过提供不同的一致性可选的策略，客户可以依据自身业务的一致性和性能要求，使用合理的一致性策略。最终一致性、会话一致性、全局一致性，一致性要求越来越高，性能会有所降低。
1.最终一致性
在数据库代理（Proxy）自动读写分离场景下默认提供数据的最终一致性，从而保证只读实例对已改变写的数据的读取，最终都能取得已更新的数据。但由于主从复制延迟的时间不可控，多个节点回放应用数据的时间上有差异，导致多个只读节点同一时刻查询同一个数据的时候，有的查询到更新前的数据，有的查询到已更新的数据，导致不同节点查询到的结果不同。最终一致性可最大化减轻主节点的压力，让尽量多的度请求通过只读节点来读取。
2.会话一致性
针对最终一致性导致查询结果不同的问题，通常需要将业务进行拆分，将一致性要求高的请求直接发往主节点，而可以接受最终一致性的请求则通过读写分离发往只读节点。这既增加了主节点的压力，影响读写分离的效果，又增加了应用开发的负担。
为解决上述问题，提供了会话一致性，保证了同一个会话内，一定能够查询到读请求执行前已更新的数据，确保了一个会话内的数据一致性。下面是内部实现的原理图：
3.全局一致性
某些场景对一致性要求极高，需要依赖全局一致性来保障不同的会话、不同的连接读取的数据一致性。使用全局一致性可能会导致更多的请求被路由到读写实例（RW），造成读写实例压力增大，业务延迟也可能增加，因此建议在读多写少的场景下选择全局一致性。例如在使用连接池的场景下，同一个线程的请求有可能通过不同连接发送出去。对数据库来说这些请求属于不同会话，但是业务逻辑上这些请求有前后依赖关系，此时会话一致性便无法保证查询结果的一致性。具体原理：每个读请求到达数据库代理时，代理都会先去主节点确认当前最新的 LSN 位点， 然后等待所有只读节点的 LSN 都更新至主节点的 LSN 位点后，代理再将读请求发送至只读节点，这样就确保了读取的数据和主节点保持一致。
数据库连接池，连接复用减少建连开销
会话级连接池用于减少短连接业务频繁与数据库建立新连接，导致 MySQL 消耗较多资源的问题。在业务断开连接的时候，数据库代理和数据库之间的连接不会立马断掉，而是在连接池中保留一定的时间，如果这个保留的时间中，有新的会话就会复用连接池中的连接，从而减少了与数据库建立连接的开销。
03
事务拆分，进一步提升写性能
数据库代理提供事务拆分功能，能够将一个事务中读和写操作拆分到不同的实例上去执行，读请求转发到只读实例，降低主实例负载，提升主节点的写入性能。传统的模式下，数据库代理通过数据库读写分离功能，可以将事务外的读转发到从(只读）节点，写转发到主节点，但针对事务内的读仍然转发给主节点，会消耗大量主节点的资源。因此通过事务拆分可以进一步将读拆分到只读节点，降低主节点资源消耗，来提升主节点的写入性能。
事务写前拆分
写前拆分是指在事务中，数据库代理（Proxy）会将写请求前的读请求发,送到只读节点，从而减轻主节点的负载。由于事务中未提交（COMMIT）的数据在只读节点上是不可见的，为了保证事务中读写一致性，第一个写请求后的所有读写请求仍路由到主节点。这种拆分方式不需要改动应用的代码或配置，就可以将事务中的读压力从主节点转移到只读节点，提高主节点的稳定性。
事务全拆分（写后拆分）
事务全拆分是不仅将写前的读请求发送到只读节点，还将写后的读请求也发送到只读节点，这种方式可以大大降低主节点的负载，以此来提升写性能。事务内在写后读取的情况，需要只读节点能感知到主节点写后的 LSN。
04
如何构建容灾？
数据库容灾能力的建设，业界目前常规的手段：数据库实例的部署结构上构建容灾：通过部署不同容灾级别的 stanby 节点，来满足不同故障阈的恢复；从备份数据上构建容灾：对备份数据进行多地冗余备份，保障极端故障场景下，数据不丢失，以及可基于备份数据进行恢复。具体包含以下几种模式：
从数据库实例部署维度：
机器级故障：主从均部署在同可用区，可以应对可用区内机器故障等场景，但面对大规模的可用区级别故障场景，无法恢复。但相比跨可用区的部署结构，主从的网络延迟更低；
可用区级故障：基于物理机架构的产品形态，常规场景两节点跨可用区，针对金融场景可使用三节点的跨可用区；
地域级故障：构建跨地域的灾备集群；
云级别故障：基于 IDC+云厂商 或者 A 云厂商 + B 云厂商的跨云容灾；
从数据安全性的维度，提供不同维度的的安全能力，在极端故障场景，保障业务可以基于备份数据进行恢复
数据备份：常规情况下，默认的数据备份会存储在主实例的同可用区；可依据数据的敏感度，备份时长可自由设定，例如有部分敏感客户会讲敏感数据备份3年；
跨地域备份：备份数据的跨地域存放，在出现地域级别的场景下，可以基于异地的备份恢复；
4.1 同可用区部署
部署说明：
部署在同一个可用区机房，主从多节点的情况，默认会跨机架部署。
机器、机架故障场景，可恢复；可用区级别的网络、组件故障无法恢复。
常规部署成本：
单个节点成本 *2（或者3）
常规部署模式为：主从两节点、主从三节点模式。
4.2 跨可用区部署
部署说明：
部署在同一个地域，跨多个可用区机房部署。
机器、机架、可用区范围内的故障可恢复。
常规部署成本：
单个节点成本 * 3
常规部署模式为：主从三节点模式，其中主+1从在同可用区，用于保障可用区内部故障的场景快速切换；另一个从部署在其他可用区，用于可用区级别故障的自动切换。
4.3 跨地域部署
部署说明：
异地部署一个灾备集群，可仅一个主节点 or 主从多节点，灾备地域通过异步复制进行数据的同步。
随着近几年企业出海热潮，客户们对多地就近访问的数据库模式诉求越来越强烈，逐步演进到全球数据库模式。通过提供跨地域/国家的全球数据库模式，提供异地多活的能力，在满足全球多点就近读写的同时，也可以进一步提供跨地域/国家的容灾能力。
常规部署成本：
单个节点成本 * 3 （跨可用区三节点） + 单个节点成本 * 2 （跨地域主从）
常规部署模式为：主地域部署：主从三节点（不考虑跨可用区切换速度稍大于同可用区切换的情况，也可考虑主从两节点跨可用区部署）。
跨地域部署：主从两节点，跨地域部署可与主地域的部署结构不一致，可减少成本；例如 主地域 主从三节点，跨地域可以部署主从两节点。
4.4 跨地域备份
部署说明：
这是一种很经济极端容灾方式，对比跨地域的部署容灾，成本会大大降低。跨地域备份是仅针对备份数据复制一份到其他地域，例如 数据库实例部署在广州，默认备份文件会存储在广州地域，开启跨地域备份之后，我们可以将备份存储一份到北京。在面临极端故障场景下，业务可以通过跨地域的数据恢复出实例，避免数据大规模丢失问题。恢复场景下也会存在几点不足：
由于恢复需要基于备份导入数据到实例，恢复耗时相比跨地域的灾备集群模式会大大增加；
可能会丢失部分未来得及备份的数据。
常规部署成本：
单个备份成本 * 2（例如备份广州+北京）
常规部署模式为：跨2个地域备份，例如 广州地域一份、北京地域一份。
4.5 同可用区部署
部署说明：
跨云部署，数据实时同步，极端故障场景下，主云出现故障，切换到备云；多云容灾可以进一步提升业务连续性，但复杂度和成本上较高，较少厂商会构建跨云容灾的能力。主要存在下面几种挑战：
多云网络互联互通，在单云的架构下，网络环境由云商负责提供。引入多云后需要协调云商，解决连通性问题；
业务层流量调度，需要解决业务层流量调度问题，由 A 云进入的流量要在 A 云闭环，只有在 A 云业务层有故障的时候才会跨云调用；
多云异构可观测，需要屏蔽不同云商监控的区别，在上层构建统一的可观测系统；
数据层跨云容灾建设，在业务没有完成单元化之前，只要做多云多活数据层的多活/容灾就是需要解决的难题，方案也会比较复杂，这里涉及数据同步、仲裁中心、业务切换、数据补偿等问题。
常规部署成本：
常规的模式：IDC+云厂商容灾、A 云厂商+B 云厂商容灾。
05
如何提升业务连续性，屏蔽数据库的抖动？
随着服务的客户越来越多，客户对数据库的可用性要求越来越高，日常的主动运维场景或者数据库异常主从切换的场景都会对业务造成短时间的中断，我们思考怎么去隔离底层数据库的变动对上层业务的感知，有效避免对业务的中断影响。常规的场景，例如 数据库的版本升级，会通过轮转升级的方式（先升级从节点再进行主从切换），主从切换会造成业务的中断等。数据库代理进一步演进出连接保持、事务续传等，来进一步保障数据库连续性。
连接保持（防闪断）
在数据库日常使用过程中，我们可能会因为常规的数据库版本升级、重启或者数据库主节点故障触发主备切换等，导致业务应用和数据库之间的连接中断，引起业务的服务受损。基于这个场景，数据库代理通过支持连接保持的功能来暂时 Hold 业务连接，当数据库恢复后续传数据等来减少业务的抖动。常见的场景主要包含：
计划内：数据库的常规运维操作，包含常规的版本升级、参数变更触发的主节点重启、跨机器的规格扩容、容灾演练触发的人工主备切换等；
计划外：数据库组件异常引发的被动切换，例如主节点异常重启、主节点不可用触发的主从切换等。
流量峰谷明显的业务，如何降低数据库使用成本？
对于波峰波谷明显 或者 朝夕流量特征的业务，在不同时间段流量波动大，例如 赛事直播、教培上课系统等。传统按照预购置资源的模式，按照峰值购置资源，可能导致在业务低谷时期集群资源闲置；若是按照日常流量均值购置资源，容易导致业务高峰资源不足，需要频繁的人工扩缩容，维护成本大。针对这类场景，Serverless 能够很好的帮助业务解决问题，完全根据业务的负载按需自动的扩缩容，面人工扩缩容的运维，并且能够按需使用大大降低资源的闲置降低使用成本。
下面为某实际客户的业务流量变化监控，流量峰值明显，通过转换成 Serverless 实例之后，成本降低超40%+，并且省去了人工的频繁扩缩容操作，大大减轻了人工运维的压力。
TDSQL-C Serverless 现已拥有较为完善的产品功能，在满足客户降本的前提下，保障实例弹的更快，弹的更稳。我们通过资源分配模式，做到秒级扩容；死磕数据库暂停到恢复的冷启动耗时，做到不使用不计费，使用时可秒级恢复响应；专项优化 buffer pool 平滑扩缩，大大提升动态扩缩的性能平滑，消除毛刺；基于数据库代理的连接保持，屏蔽底层数据库计划内外切换带来的业务中断，持续提升了业务访问数据库的连续性；业界首位支持可释放存储，帮助暂停中的业务降低90%存储成本。当然，在产品持续被客户使用过程中，我们仍然面临多项难题在持续攻克中。例如：如何进行预测式扩容，避免基于实时使用率的事后扩容，导致无法及时应对流量洪峰？如何构建更丰富的扩缩容指标，以应对 IO 密集型场景、计算密集型等不同场景的扩缩容，满足业务的性能诉求？等等。
分析场景如何提升查询的性能？
云数据库发展初期，常见的数据分析的架构往往是，将 MySQL 的数据通过 ETL 流程同步到 OLAP 分析型数据库上。随着业务发展，MySQL 可以存储的数据量达到 TB 级别，基于原有ETL的方案构建AP分析链路往往存在多种问题：
实时性差，往往需要 T+1 以上的时间周期；
两份存储成本高，OLTP、OLAP 各一份；
管理流程负载，需要经过ETL复杂的过滤、清晰、转换、存储等流程；以及考虑面对大流量的场景下，会引入消息队列进行系统解耦，进一步增加系统复杂度；
总之，通过 ETL 同步工具 + 消息队列 + 独立 AP 数仓的方案，在稳定性、实时性以及管理成本上也存在诸多问题。为此，业界一直在攻坚轻量一体化的 HTAP 数据库解决方案，来解决轻量复杂查询的实时性问题。
TDSQL-C 采用列式存储索引技术，融合了 TP 与 AP 的双重能力，打造成为一款全面的 HTAP 数据库解决方案。用户只需部署一套数据库系统，便能同时满足 OLTP 事务处理和 OLAP 数据分析的需求，能支持对在线数据进行实时分析。
-End-
原创作者｜陈雪梅
感谢你读到这里，不如关注一下？👇
📢📢来抢开发者限席名额！点击下方图片直达👇
你对本文内容有哪些看法？同意、反对、困惑的地方是？欢迎留言，我们将邀请作者针对性回复你的评论，欢迎评论留言补充。我们将选取1则优质的评论，送出腾讯云定制文件袋套装1个（见下图）。1月29日中午12点开奖。
407
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
