支持微信支付的国产数据库核心大揭秘
支持微信支付的国产数据库核心大揭秘
在腾讯云数据库举办的【国产数据库专题线上技术沙龙】中，4月30日陈爱声的分享已经结束，没来得及参与的小伙伴不用担心，以下是直播的视频和文字回顾。
关注“腾讯云数据库”公众号，回复“0430陈爱声”，即可下载直播分享PPT。
大家好，我是陈爱声，目前负责腾讯云TBase产品实施和运维相关工作。非常感谢大家百忙之中抽空来到TBase直播间。
今天的分享主题是“TBase优秀的企业级能力原理剖析”，主要分为四个特性。
第一：数据透明加密能力。
第二：基于任意时间点的恢复能力。
第三：异构数据同步能力。
第四：在线扩容能力。
这些都是我们在企业级市场里作为一个企业级数据库必须要具备的基本能力。
1
PartⅠ 数据透明加密能力
第一个部分：数据透明加密能力。首先我们来看一下为什么需要有这样的能力，以及这种能力应用的业务场景。我们在对外交流业务时候经常会遇到一些这样的需求，比如，在政务相关业务中，数据加密这种需求就特别的强烈，他们对数据的存储监管要求非常高，且要求你存储的数据不能是明文，主要是考虑到数据库非正常访问，数据库主机如果一旦发生失窃或者一些非法的访问，物理文件一旦被偷走，那么别人通过访问物理文件是可以拿到里面具体的数据内容，这就要求你的数据必须是加密过的，一旦数据文件被非法拷贝，对方也没办法读出里面正确的内容。
数据加密的能力当前有两种，第一种是应用级的加密解密。第二种是数据库内核本身具备这种能力。从应用的场景来看，如果是应用级的，那带来的问题是挺多。首先可以看到开发语言可能会有非常多种，比如java、c、go、python……所有每一种语言都得编写具备同样的加密和解密能力，它们必须重新编写多次。另外还有第三方数据库管理工具，navicat、pgadmin，再就如数据同步工具，如kattle、dsg、ogg。它们也必须要具备这种加密和解密能力，这种第三方的工具实际上根本没有办法进行二次开发，或者它的二次开发成本非常高。这个时候如果数据库具备这种加密和解密能力的话，对应用来说就是不入侵的，透明的。
TBase是怎样来实现这种加密和解密的呢？
我们可以看下面一张图。
TBase是在内核里实现了加密解密，操作是放在数据库的执行层面。也就是说用户在访问各种接口的时候所写的语句与之前一样，涉及数据是明文，读写都是明文，你原来应用怎么写你还是那样写，在执行时,数据库自动做一层加密解密的动作。而且内存里所有的数据本身也都是加密过的，这样可以防止内存数据给非法访问把数据取走，保存在数据文件中的数据也是加密过的，这样数据文件一旦给别人非法窃取，他要解密就需要有密钥，否则的话他也没办法翻译出正确的明码。
TBase的透明加密能力具体有哪些特性呢？
首先我们可以支持多种加密方式，有AES128，AES192，AES256，SM4国密。第二个就是配置简单，接口非常丰富。第三对用户透明无感知,SQL语句不需要转译，可读性好。
接下来看看TBase数据加密解密具体的操作方法。
首先创建一个加密的算法，相当于你要创建一个加密的密钥，在TBase里创建一个加密的密钥使用一个专门的用户mls_admin。创建密钥需要指定算法，密钥，SM4要求它的token必须是16位的，每个密钥都有一个ID，这个ID就是将来拿来配置表或者schema加密用的。
创建密钥后，你就可以对表进行加密配置。
比如创建一张表，执行这个函数配置，配置完之后这就是一张加密表，写进去的数据就自动加密，读出来的数据自动解密成明文，这个是表加密的配置方法。在使用的过程中我们还可以对一个schema进行加密配置。
schema默认的加密方法配置后，创建存放于这个schema下的表，默认的情况下，用这个密钥进行加密，也就是说你只要配置完schema以后，以后创建表的时候自动会把它配置成加密表，这样基本上达到了一次配置以后不需要重新配置表的加密方式。
接下来看一下保存在数据文件中的内容，可以看到两个表存储的内容是完全不一样的，但读出来的明文是一致的。
这个就是我们TBase提供的透明加密的能力，使用无感知，对应用无入侵性。
1
PartⅡ 基于任意时间点恢复能力
第二个部分：基于任意时间点的恢复能力。在分享之前我们先看下数据库备份的分类。
我们在使用一个数据库的时候可能会出现一些误操作或者是一些灾难性的问题，这就需要一个数据库具备有一个任意时间点的恢复能力，可以把数据恢复到某个时间点。
对于数据库的备份恢复能力，首先数据库必须具备在线执行全量的备份功能，把整个数据库备份起来，通常是周期性的，比如说是一天、一周，或者是N天，这个策略是根据你自己的需要进行配置，有了一份全量基础备份数据，从备份点开始，系统不断的产生新的增量日志数据，我们要把这些增量的日志全部备份起来。有了这些备份的数据文件，在恢复的时候，使用一份全量的备份数据，再加上增量的日志文件，就可以针对任意一个时间点进行恢复。增量的日志备份是实时的执行，只要一个日志文件写满了系统就自动把这个日志文件备份到指定的地方，通常备份存储的服务器可以网络文件存储系统，或者一种分布式存储系统，比如说HDFS,COS。
对于TBase来说，它的日志分为三种：
- 一种是GTM日志
- 一种是CN日志
- 一种是DN日志
这三种日志必须要完整的备份到存储介质里面去。
恢复的时候，增量的日志文件和全量备份的物理文件全部要下载下来，然后在一个新的服务器上面再把它生成新的实例，恢复到指定的时间点，然后再找出你需要的数据，最后再把数据更新到生产的实例中去。
我们的运维系统里提供了一个非常简便的备份系统，目前支持备份数据到HDFS文件系统中，只要配置存储的HDFS的地址，全量备份开始的时间点，间隔多少天做一次全量备份，保留多少份全量快照，然后系统会根据参数自动的去执行。
为了减少备份时对主节点的影响，备份是在备节点上执行的,所以在备份的时候它对系统的影响还是比较小的。
恢复也是在线进行配置的，恢复的时候就点这里，选择你要恢复的时间点，这里恢复的时间点实际上是一个全局的恢复，也就是一个GTM全局的时间点，而不是基于某个节点，因为基于某个点恢复出来的数据是不一致的，我们在选择某一个时间点后，系统会找出相近具体有哪些时间点可以恢复给你二次选择，你在这里选择你需要恢复的时间点。
然后选择你要恢复到哪些机器里，把节点恢复到一个临时的机器上，恢复时长视你全量备份下载时长和你要恢复的多少个日志文件。
1
PartⅢ 异构数据同步能力
接下来跟大家分享一个异构数据同步能力，那么为什么有这种场景呢？
第一种：新老系统并行。新系统只会分流一部分流量，老系统还要继续保留一份全量的数据，这种并行灰度，在解决方案里有多种，其中一种程序双写，这个需要对应用层进行二次开发，对原有的应用有开发成本和运维成本。这个时候如果我们可以把导入到新系统的数据同步出来，然后再开发相应的订阅工具把数据返回老系统中，这种方案相对来说成本方面比较可控。
第二种：数据订阅服务。就是我们业务需要和其他的业务系统进行数据交换，以前是应用程序直接利用接口把数据分发出去，这种方式增加了系统的复杂性，而且对系统的耦合性比较强。这里如果数据库在数据提交后能自动的把提交的数据同步到消息中间件，然后有数据需求的业务现自行订阅，实现数据实时同步，还可以解决耦合的问题，消息中间件还可以解决数据库被多次访问压力的问题，可以让交易库跑得更加轻易。
第三种：数据分发服务。还有业务场景是抽取多个业务库到专职分析平台做数据分析的需求，一般做法是ETL工具抽取，这样如果多次抽取，增大对数据库的访问压力，而且实时性也较差，也可利用Tbase2kafka能力输出数据到消息中间件平台，然后再来订阅需要的数据。
接下来，我们看一下TBase的数据是如何同步到kafka的。
TBase的数据同步到kafka是从DN节点进行同步，因为数据日志都在DN节点，通过一个kafka-connector的连接器连接到所有的DN里，再把它转换成kafka需要的消息格式，最后存放于kafka中。订阅者就能通过订阅kafka里面相关的topic来实现数据同步。
TBase2kafka实际上就是逻辑发布订阅能力，最开始kafka-connector拉取一份全量的数据，然后会根据LSN的位置再去拉取增量数据。订阅程序不断的订阅增量的数据，而且订阅可以实时，也可以是需要时再订阅，这样上下游完全解耦，业务库的运行压力也较低。
我们运维系统提供了TBase同步数据到kafka的配置功能，最简单的配置你只需要指定同步库，用户名，密码就可以同步数据至kafka。我们还提供了数据同步监控能力，可以看到还有多少数据量没有同步。
TBase通过数据同步至消息中间件kafka，从而实现了消息同步业务需求的解耦。
1
PartⅣ 在线扩容能力
接下来给大家分享做为一个分布式数据库最重要、也是必备的能力，在线扩容能力。
分布式数据库利用多个节点来实现服务能力和存储能力的横向扩容，通过扩容不断满足业务的发展的需求。在线扩容的基本要求，对现网的业务影响要尽可能的小，不能因为扩容把业务停了，或者有部分业务不能写，只能读，降级运行对于24小时在线交易业务是无法接受的。
现在我们看看TBase的内核是如何支持在线扩容的。我们知道应用是通过CN节点接入业务，然后由CN算出路由，发到相应的DN节点去执行，在CN上有全部路由数据，用于计算某个shardid值对应的DN节点，而不像其它的分布式数据库他们直接把DN节点当做计算因子。借助全局shardid就可以找到最终的DN落在哪里，扩容时，你只要把你需要指定某一个shardid存放的路由指向新的DN节点即可，如从原来的DN1搬到DN3里，当数据从DN1同步到DN3后，系统只需要变更一下CN上面的路由表，新的访问会路由到DN3上面。
我们看一下下面这张图。
最开始的时候只有一个DN1和DN2，只有两个存储节点，没有DN3节点，上面这些数据都存储在DN1、DN2，每一个DN节点里面有三个分片，一共六个shardid，现在增加了新的节点进来，新节点最开始没有任何分片路由，也就是说新增进来的DN，路由表上是没有它的任何对照信息。现在需要把对应shardid分片的数据同步到新的DN3，利用迁移工具，从DN1和DN2节点里面把S03和S04小分片的数据搬到新的节点里来，这个过程需要把增量的数据一起同步过来。什么时候结束呢？系统认为增量数据同步在能够承受范围之内能够同步完成，比如说当前只有30M的数据没有同步完成，那可能这个时候就会锁定更新，让这DN1,DN2节点都不能写入数据和读取数据，然后等待存量的数据同步完成，接着修改CN的路由，最后释放锁定，然后新的请求访问，计算路由的时候就会将访问S03、S04路由到DN3新节点了。
现在演示在线过程，先增加一个新的节点，新节点是空的，里面什么数据都没有。
然后利用数据搬迁工具，选择要搬迁数据的DN节点，系统会弹出来该节点小分片，系统计算每一个小分片有多少条数据，占用空间，也可以输入搬迁比例，可以从1%到100%，比如说要搬迁50%，你就输一个50%。然后系统就自己在后台进行数据迁移。
删除旧数据，旧DN里把数据搬迁后还继续占用空间，但数据已经不可见，所以我们必须把它删除掉，在运维平台配置一个删除数据任务，可以配置系统什么时候开始清理，什么时候结束。
删了数据后就能彻底回收了。回收操作就是把空间真正的返回给操作系统。
访问前后路由对比，搬迁之前访问一条数据，数据在在DN1里面，搬迁之后，数据变到了DN2，从而实现了路由的切换。
1
PartⅤ Q&A
Q:在线扩容是否需要做快照？
A：在线扩容不需要做快照，在线扩容只是将数据从一个节点搬到一个节点而已，只要识别哪一些数据需要搬迁就行，不需要做快照。在搬的过程中是有增量数据进来，系统会实时同步增量数据，过程相当于逻辑订阅，但又比逻辑发布订阅更复杂一些，逻辑发布订阅最小级别是表级，扩容的最小级别是shard分片。
Q：路由切换时间点？
A：切换路由一般是这样，在扩容的时候有增量数据进来，系统会判断到底还有多少增量数据还没有同步过去，比如只需要5秒就能同步完成，这时候可能就会启动锁定的机制，会把老的节点先锁住，不让读写，这时候老的数据节点写不进来，然后新的会继续把数据同步，同步完成后，修改路由信息表，最后系统切换路由。
Q：加密对系统性能的影响？
A：透明加密对性能肯定有影响，CPU开销更大，TBase在这方面做了一些优化，多线程写盘。如果系统不是百分之百压力跑的情况下，压力应该是感觉不到。
Q：异构迁移是否支持配置某张表？
A：异构迁移这个很灵活，我们可以只配其中的某一张表进行同步就行了，而且同一个库里还可以配多次发布。
Q：TBase是如何把增量的日志数据备份到HDFS上面？
A：这个跟Postgresql的pitr备份方式是一致的，配置archive_command的备份参数即可，就可以把写满的日志传输到hdfs,cos或者其它文件系统中。
Q：TBase对于开源的PGXL做了那些改进？
A：TBase是基于（PGXL）引进过来的，所以和PGXL功能看上去比较相似，但它对比PGXL还是做了很多改进，首先GTM里也是做了很大的性能的优化，另外在可靠性方面比PGXL也做了很多的工作，增加了运维系统。
Q：TBase的租户和实例有什么区别，资源是如何隔离的。
A：租户可以理解成就是公有云上面的用户，实例就是相当于这个用户申请了多套数据库环境。GTM/CN/DN节点当前使用cgroup将运行的资源隔离，同一台机器里面可以部署不同租户的实例。
Q：TBase的扩容使用什么算法？
A：TBase在数据搬迁是按照最小单元shardid进行迁移，从一个dn节点搬迁到另一个节点上，然后再变更shardid上面对应的路由信息。
Q：TBase的分区表是自研的吗？
A：TBase的分区表分两种，TBase自研分区表，TBase的分区表从性能测试来看，要优于社区的分区表，而且从运维层面来看TBase的分区表比社区的分区表比较简单，同时我们也支持社区的分区表。
Q：TBase的某个CN故障的影响范围？
A：某个CN主节点服务故障后，不是所有的DML和DDL无法执行，DDL会受影响，但是DML不会受影响。
以上是今天的分享和Q&A的解答，感谢大家的聆听。
TBase是腾讯TEG数据库工作组三大产品之一，是在开源的PostgreSQL基础上研发的企业级分布式HTAP数据库管理系统。通过单一数据库集群同时为客户提供高一致性的分布式数据库服务和高性能的数据仓库服务，形成一套融合完整的企业级解决方案。大家在数据库领域遇到相关问题时，欢迎随时留言我们。
往期推荐
特惠体验云数据库
↓↓更多惊喜优惠请点这儿~