如何用书签 做网站接口,宜昌网站制作,网上做网站怎么防止被骗,网站建设和运营的教程随着互联网应用的广泛普及#xff0c;海量数据的存储和访问成为系统设计的瓶颈问题。对于大型的互联网应用#xff0c;每天几十亿的PV无疑对数据库造成了相当高的负载。给系统的稳定性和扩展性造成了极大的问题。通过数据的切分来提高系统整体性能#xff0c;扩充系统整体容…随着互联网应用的广泛普及海量数据的存储和访问成为系统设计的瓶颈问题。对于大型的互联网应用每天几十亿的PV无疑对数据库造成了相当高的负载。给系统的稳定性和扩展性造成了极大的问题。通过数据的切分来提高系统整体性能扩充系统整体容量横向扩展数据层已经成为架构研发人员首选的方式。 2004年腾讯开始逐步上线互联网增值服务业务量开始第一次爆炸。计费成为所有业务都需要的一个公共服务不再是某个服务的专属。业务量的爆炸给DB层带来了巨大的压力原来的单机模式已经无法支撑。伴随计费公共平台的整合建设在DB层开始引入分库分表机制针对大的表按照某个key预先拆成n个子表分布在不同的机器节点上。逻辑层在访问DB时自己根据分表逻辑将请求分发到不同的节点。在扩容时需要手工完成子表数据的搬迁和访问路由的修改。DB层在业务狂潮之下增加各种工具和补丁来解决容量水平扩展的问题。2012年TDSQL项目立项目标为金融联机交易数据库。 TDSQLTencent Distributed MySQL腾讯分布式MySQL是针对金融联机交易场景推出的高一致性、分布式数据库解决方案。产品形态为一个数据库集群底层基于MySQL对外的功能表现上与MySQL兼容。截至2017年TDSQL已在公司内部关键数据领域获得广泛应用其中之一作为Midas米大师核心数据库经受了互联网交易场景的考验。Midas作为腾讯官方唯一数字业务支付平台为公司移动AppiOS、Android、Win phone等、PC客户端、Web等不同场景提供一站式计费解决方案。 TDSQL规定shardkey为表拆分的依据即进行SQL查询时shardkey作为查询字段指明该SQL发往哪个Set数据分片。在分库分表之前需要Schedule初始化集群我们这里称作一个Group。在初始化Group时要确定最初的分片大小因而需要确定准备几套Set。例如我们需要对逻辑表拆分成四张子表需要我们在初始化集群时准备四个Set同时指定每个Set的路由信息并将这些路由信息写入ZK如图1所示。 图1 TDSQL分库分表 完成集群初始化后Proxy监控ZooKeeper中的路由节点当发现新的路由信息后更新新的路由到本地。当用户通过Proxy创建表时一个建表语句发给Proxy必须指定shardkey例如create table test_shard(a int, b int) shardkeya。然后Proxy改写SQL根据路由信息在最后增加对应的partition clause然后发到所有的后端Set如图2所示。 图2 Proxy建表语句 这样就完成了一次建表任务用户看到的是一张逻辑表test_shard但是在后端创建了4个实体表test_shard后续用户通过网关进行带shardkey的增删改查时Proxy便会根据shardkey的路由将SQL发往指定Set。 在单实例MySQL中用户可以通过auto_increment属性生成一个唯一的值在分布式数据库下利用MySQL的自增属性只能保证在一个后端实例内实现自增和全局唯一无法保证整个集群的唯一。 为了保证整个集群的唯一性很显然不能依赖于后端的数据库而需要Proxy生成对应的值。同时在实际运行中Proxy可能有多个并且可能有重启等操作通过Proxy自身也很难做到全局唯一因此选用了ZooKeeper作为唯一值的生成工具。 通过ZooKeeper的分布式特性可以保证即使多个Proxy同时访问每次只会有一个Proxy能够成功拿到使得生成的值是全局唯一。从性能上考虑不可能每次都与ZooKeeper进行交互获取因此每个Proxy每次都会申请一段值都用完后才会向ZooKeeper进行申请。 图3 全局唯一字段表创建过程 这种设计方式实现了分布式环境下的自增属性全局唯一。每个Proxy缓存一定数量的值并且增加单独线程负责向ZooKeeper申请值使得性能影响降到最低同时具有容灾特性即使Proxy挂了或者重启都能保证全局唯一。但是缺点是多个Proxy一起使用的时候只能保证全局唯一不能保证单调递增。 全局唯一字段的创建方式和普通的自增字段一样 create table auto_inc(a int auto_increment,b int) shardkeyb; 使用方式也相同 insert into shard.auto_inc ( a,b,d,c) values(1,2,3,0),(1,2,3,0); 对应的字段如果赋值为0或者NULL时由Proxy生成唯一的值然后修改对应的SQL发送到后端。同时也支持select last_insert_id()返回上次插入的值每个线程互相独立。 在分布式数据库中数据根据shardkey拆分到后端多个Set中每个后端Set保存的都只是一部分数据。我们可以方便地在一个Set内做各种复杂的操作如JOIN、子查询等。分布式JOIN依赖于网关的语法分析何为语法分析简单来说语法分析主要做两方面的事判断输入是否满足指定的语法规则同时生成抽象语法树。对于词法分析以及语法分析开源有多种现成的工具不需要从头开始做Linux下用的比较多的是Flex和Bison。 图4 语法分析过程 有了语法分析的支持对于涉及分布式JOIN的查询例如表t1和t2要做JOIN操作可能使用不同的字段作为shardkey这样根据shardkey路由后相关记录可能分布在两个Set网关分析后先将数据表t1数据取出然后再根据t1的shardkey去获取t2的数据网关在这个过程中先做语法解析再进行数据聚合最后返回给用户结果集。此外在实际业务中有一些特殊的配置表这些表都比较小并且变动不多但是会和很多其他表有关联对于这类表没必要进行分片因此支持一种叫做全局表的特殊表。如果用户创建时指定是全局表的话g1该表全量存放在后端的所有Set中查询时随机选择一个Set修改时修改所有Set。如果对全局表进行JOIN的话就不需要限制条件即支持select * from t1 join g1。 针对分布式事务TDSQL采用两阶段提交算法来实现分布式事务其中Proxy作为协调者状态数据持久化到全局事务管理系统中目前选用的是TDSQL本身的一个InnoDB表来保存gtid_log所有的Group作为参与者来负责具体子事务的执行。 图5 分布式事务 Begin Statment1 Statment2 … Proxy为该事务分配一个ID并将SQL转为 Xa begin “id” Statment1; Statment2; … Client最终向Proxy发送commit。 Proxy向所有参与该事务的Set发送 Xa end “id” 标识该事务的结束 Xa prepare “id” mysql将事务计入Binlog并通过Binlog传递给Slave不同于普通事务写入Binlog之后该事务仍然没有提交 如果任意Set在 prepare过程中失败或者超时由于此时还没有写存储引擎日志MySQL自动rollback这个事务并向Client返回相应错误信息。 当Proxy收到所有Set的prepare响应之后Proxy更新gtid_log表将对应XID的事务置为commit状态Proxy随后向所有Set发送Xa commit “id”Set收到该请求之后提交该事务。 Proxy等待所有Set的commit响应当所有Set返回成功Proxy返回前台成功。若其中一台返回失败当Set发生重启等故障时需要等待Agent补提交该事务因而当前属于未提交状态Proxy返回前台状态未知稍后请继续查询事务状态。 当Proxy在第四步写完commit后开始逐个Set提交事务当还没有完成所有Set提交时Proxy发生宕机剩余Set中未提交的事务由Agent来提交以此来保证事务的一致性。Agent会定期通过命令Xa recover查询MySQL中处于prepare状态的事务再对照gtid-log表查询该事务是否处于commit状态如果是则comimt。否则可能由于prepare成功后写gtid_log失败因而Agent需要将该事务abort。 TDSQL支持三种模式的读写分离。第一种模式下网关开启语法解析的配置通过语法解析过滤出用户的select读请求默认把读请求直接发给备机。这种方案的缺点有两个1. 网关需要对SQL进行分析降低整体性能2. 当主备延迟较大时直接从备机获取数据可能会得到错误的数据。 除了上述模式TDSQL支持通过增加Slave注释标记将指定的SQL发往备机。即在SQL中添加/slave/这样的标记该SQL会发送给备机即用户能够根据业务场景可控地选择读写分离即使主备延迟比较大用户也能够根据需要灵活选择从主机还是备机读取数据这种模式下网关不需要进行词法解析因而相比第一种方案提高了整体性能。但是这种方案的缺陷是改写了正常SQL需要调整已有用户代码成本较高用户可能不太愿意接受。 表1 三种读写分离模式比较 针对前两种读写分离的不足最新版本的TDSQL增加了基于只读帐号的读写分离模式。这种模式下由只读帐号发送的请求会根据配置的属性发给备机。有两种可配属性IDC属性和备机延迟属性。IDC属性可配置三种属性1. 为同IDC属性即只读帐号的请求必须发往同IDC的备机2. 优先发给同IDC的备机但当同IDC的备机不存在或宕机时发往不同IDC的备机3. 如果找不到满足条件的备机则发往主机。延迟属性如果延迟超过阀值认为该备机不可用。只读帐号能够在既不改变原有用户代码又不影响系统整体性能的前提下同时提供多种可配参数解决读写分离的问题更具有灵活性和实用性。 2014年微众银行设立之初在其分布式的去IOE架构中TDSQL承担了去O的角色以TDSQL作为交易的核心DB承载全行所有OLTP业务。2015年TDSQL和腾讯云携手正式启动“TDSQL上云”的工作接入了一系列传统以及新型金融企业覆盖保险、证券、理财、咨询等金融行业。目前分布式TDSQL正作为腾讯日益重要的金融级数据库搭建着上百个实例部署于上千台机器日均产生TB级数据承载着公司内外各种关键业务。 在未来TDSQL重点会在数据库性能、分布式事务、语法兼容三个方面做改进。目前TDSQL基于MariaDB 10.1.x、Percona-MySQL 5.7.x两个分支版本后续我们会紧密跟进社区并及时应用官方补丁同时不断针对金融场景的特性对数据库内核进行优化以此来提升数据库性能和稳定性。当前分布式事务处于初级阶段对ZooKeeper的依赖性较强后续可能针对分布式事务的可靠性做持续改进。由于TDSQL在分表环节对语法层做了一些限制将来我们希望通过对网关解析器的改进使其能够支持更丰富的语法、词法。转载于:https://www.cnblogs.com/jellyru/p/6894778.html
