乐博现金登陆_乐博手机版_乐博彩票百度

    
当前位置:首页乐博首页正文
admin

必要,带你吃透分布式的精华!

  2个月前 (05-10)     207     0
简介:带你吃透分布式的精髓!...

1953年,埃布格罗希提出Grosch规律,即核算机功用会跟着本钱的平方而添加。1965年,高登摩尔提出摩尔规律:当价格不变时,集成电路上可包容的元器件的数目,约每隔18-24个月便会添加一倍。

当今,核算机的遍及,也让越来越多的电脑处于搁置状况,即便在开机状况下CPU的潜力也远未被彻底运用。而互联网的呈现,使得衔接和调用搁置核算资源的核算机体系成为了实际。

所以,散布式核算开端遍及,散布式难不难?难!所以更需名师指路!下面要介绍的课程,由京东云高档总监亲身授课哦,从速往下看吧!

本次直播课程由京东云高档总监郭理靖数据库根底下手,从实践运用动身,深度解析从单机数据库到散布式数据库的技能开展与迭代,一同并理论结合实际为咱们叙述企业挑选数据库服务的金科玉律以及京东云针对此方面的运用实践等干货内容。

课程概要

此次课程的共享内容更多关于数据库服务的演化史,要点叙述单机到散布式的改动从何而来以及从单机数据库怎样进行改善才可到达散布式数据库的服务。

以下是郭理靖教师共享的全部内容,期望给各位开发者带来更多协助:

从单机到散布式,数据库服务的演化史

— 京东云高档总监 郭理靖—

(主张在Wi-Fi环境下观看↓)

1

从Redis到MongoDB

从Redis到MongoDB,开端的发作都很简略

许多时分,一门技能乃至一种产品,开端的发作往往都来历十分简略的主意,例如2019年,咱们看到DB-Engines Ranking中有两个比较了解的身影,MongoDB和Redis。

很有意思的是,MongoDB归于DocumentDB。假如咱们调头去看DocumentDB-Engines Ranking的话,能够发现MongoDB是排在榜首位,并且是以绝对性的优势“吊打”第二位到第十位(第二名只需56分),整个DB-Engines中,Oracle和MySQL的分数靠得特别近;可是在DocumentDB中,MongoDB是400多分,但第二名或许就只需100多分。

相同,Redis在K/V的范畴,分数也特别靠前,它146分,第三名是MemcacheD(第二名为Amazon DynamoDB,为56分) 只需28.7分。

所以这两个数据库在自己的专业范畴中都是排名特别靠前的两个数据库,并且互相呈现的时刻都不算特别长,不到十年:Redis呈现的比MongoDB早一些,Redis是2009年,MongoDB差不多也是在2009年左右呈现的。

为什么Redis会呈现,并且成为K/VDB排名榜首的一个数据库呢?

其实,在Redis呈现之前现已有一个K/V的数据库叫Memcached,早在2003年发布,开端用Perl写了一个版别,最终用C言语重写了。在Redis没有呈现之前,Memcached一直是K/V数据库的领头,为什么在2009年,当Redis呈现时就飞快地替代了Memcached,直至今天,大部分的缓存咱们都用Redis。乃至刚入行的同学们底子没有听说过还有Memcached这样的数据库,这个进程中Redis究竟做了什么作业?

作业比较简略,从规划理念动身,便是把原先Memcached的存储结构进行了改动。之前是一个Key对应一个String,然后Redis把String改动成一个能够结构化的Structured storage,也便是说Redis能够支撑一些结构化的数据,包含List、sorted set、hashes等 。

如此小的改动为什么能够让它获得这么大的优势?关于此仍是要回溯下Memcached。

假定咱们自己要规划一个缓存体系的话,规划方针与Memcached相同,进程中就需求规划一个Key String的缓存体系,那么在这个缓存体系上究竟能够供给哪些服务呢?更进一步来说,当存储对象是String,针对此咱们能够做到哪些操作?

能够想见,在一个编程言语中,以以C++或许Java为例,一个字符串能够set一个字符串,还能够get一个字符串,当然也能够delete一个字符串。此外,关于字符串咱们还能够做一些其他操作,例如append、prepend等,也便是字符串的尾巴和头部加些内容,乃至能够将整陈宝柱个字符串替换掉。当然,也能够做insert、erase,还有trim这种操作以及find、substr等。

咱们在规划进程中无妨想一想,为什么在Memcached中不支撑insert或find、substr这样的操作呢?

这其实是一个很有意思的论题。理论上Memcach三极管ed能够支撑这些操作,包含针对Memcached的源代码进行修正之后,也能够支撑这些函数和调用,但之所以挑选不支撑或许更多仍是功率方面的考量。

例如在Memcached中支撑substr或许find的操作的进程中,却浪费了Memcached服务器的功用。由于find能够把整个字符串搬运到本地再做find,substr也是相同,其实都归功于功用。

当然Memcached也能够供给更高档的一些操作,例如add或许一必要,带你吃透散布式的精华!些ge料组词ts操作,还能够做incr/decr,对一个数字进行原子性加减,都能够。假如去研讨Memcached整个release history的话,它是2003年开端发布的一个版别,前期支撑的作业是十分有限的,所今后续的高档功用也是渐渐逐步加进去的。

再看一下Redis,能够支撑的数据结构有许多,包含Strings、Lists、Sets、Sorted sets、Hashes、Bit arrays,还有HyperLogLogs、streams,streams是5.0,最新的版别乃至能够支撑一些时序性的数据。

纵观整个迭代进程,Redis开端的简略主意便是能不能将Strings的结构和存储结女性交配构,让其支撑的多一些。从这个主意动身,才会逐步开展成渐渐去支撑越来越多的数据结构,支撑越来越多操作类型的局势。

以C++为例,一个List操作支撑pop/push,也能够支撑在List中心去Insert/erase。关于Redis而言,除了常见的操作之外,我看了一下Redis全体的release history,最开端的时分也支撑的是一些比较简略的操作,例如pop/push;跟着时刻的开展,支撑越来越多的高档功用,都是树立在一般的操作上。

比方说BRPOPLPUSH这个功用,便是从一个List中POP一个数据出来,刺进到别的一个List中去,这算是比较高档的功用表现了,但这个也是在用户发现其需求此种场景之后才去添加的事项。

再来探求下MongoDB。MongoDB的“作业”其实与Redis有点相似,能够以为Redis便是运用K/V结构,将Strings换成了一个相似于JSON的类型,JSON中能够支撑的数据结构也十分多。

MongoDB所表现的功用相似度很高。曾经在规划数据库的时分,假如是联系型数据库,一开端就需求将Schema规划好,然后去做一个DDL操作。当需求添加一列或许削减一列的时分,以上的操作并不是很便利;特别在表单很巨大的状况下,操作时刻会很长。

跟着业务的开展,是否能够用一个JSON来替代原型MySQL Schema?以这样一种简略的主意动身,现在虽然MySQL或许联系型数据库仍是以Schema为中心,可是MongoDB就以Document,也便是JSON这个格局为中心去构建整个数据库的功用和生态。

能够看到,MySQL的常见SQL句子在MongoDB中指令长度不太相同,由于一切的指令都与JSON的格局有关,包含底层的存储结构也会由于要保存JSON格局而做出很大改动。

这部分会集想要表达的观念便是许多什么鬼套路全集数据库以及技能产品的演进,其实都是有头绪可寻的,首要便是设定处理问题的方针从而完结底层数据结构的修正,其间底层结构确认之后还会在必定程度上影响产品功用,例如MongoDB在很长一段时刻内都不支撑业务,不是不想去测验支撑,而是取决于底层存储结构的存储引擎,无法支撑业务。

相同的道理,探求Memcached联合利华和Red必要,带你吃透散布式的精华!is的内存办理规划,也会发现,Memcached的开发者或许说社区,也想去支撑像Redis相同的功用,但事实上由于底层的存储结构注定无法供给此类服务。

2

散布式从何而来?

为什么会有散布式?首要仍是由于处在信息爆破的年代,业务量逐步巨大导致单机数据库并不能更好满意需求,天然要寻觅一些可行的处理计划。

这儿的处理计划能够分为两种,一类相当于表层的处理计划,操作起来比较简略,其间触及客户端的计划以及共同署理的计划等,例如proxy的计划。

相比之下,底层的计划能够分为三类。榜首类是散布式块存储计划,第二类是核算与存储别离计划,第三类便是要重整旗鼓了。

首要客户端计划,能够以友商开源的项目称为TDDL为代表,计划思路较为明晰。假如咱们本身需求做一个散布式体系的话,将散布式处理计划放入客户端内,最重要的便是“通知”客户端SQL句子应该链接到背面哪个数据库,究竟不同的数据存储在不同的机器傍边。关于客户端的计划,比较重要的便是与后端的一些衔接,以及怎样解析这个SQL句子。

第二种计划便是Proxy计划。Proxy计划相对客户端计划而言,开发难度略微高一些,但思路上仍是十分共同的。举例说明,一张用户表,用户表的组件是ID,咱们对ID的散布式key进行散布,查询详细某一个用户ID的时分其实就有一个Proxy,假如说查询这个用户ID为0,从而就知道0是存在于后台的哪一台MySQL。

所以关于Proxy而言,十分重要的一点仍是需求去解析详细的SQL句子,这个进程中有必要需求有一个自己的路由,就能够完结辨认。

客户端的计划与Proxy计划的差异在哪里?差异在于客户端的计划开发起来相对比较简略一点,在JDBC中或许要求客户端调用时,客户端能够不解析SQL句子,完结导向很简单。

关于Proxy计划,它需求兼容原有的MyS必要,带你吃透散布式的精华!QL协议,中老年秋装怎样树立MySQL衔接,怎样与后端坚持衔接,这个难度比较大。但相对而言,Proxy计划的约束也比较多,不管是客户端的表层计划,仍是Proxy的表层计划,它们对SQL的运用要求都是比较高的,例如一些join是比较难支撑的,并且要与业务方到达共同。

此外,无论是客户端计划仍是Proxy计划,全体架构仍是比较相似的。例如Proxy计划,它会触及前端怎样与客户端进行衔接以及后端的Backend connection,还要与后端真实供给MySQL服务的坚持衔接,这是两个衔接的办理。

通过了解,整个Proxy一般的规划都会采纳无状况,由于路由信息都是保存在Proxy本机的;但路由方面必定有一个相对的路由办理中心去分发和更改操控。业界大部分Proxy规划,咱们都会发现,Proxy署理的计划其架构规划十分相像,差异在于工程质量不同罢了。

别的,关于Proxy计划的缺陷便是怎样去做一个散布式业务,没办法确保次第。一般在一个散布式的状况下,其实很难确保每个节点上的业务履行是依照咱们想像中的次第去做。

讲完表层的处理计划之后,咱们还需求讲讲比较深层次的底层处理计划。从表层动身,不管是客户端计划仍是Proxy计划,都并没有去改动底层MySQL的全体协议,也没有改动数据库原生服务,能够以为底子就没有让MySQL底层代码发作改变。

现在可知晓的底层处理计划首要有三个,榜首个计划是块存储计划,包含SAN处理计划,触及云端便是云硬盘处理计划,都是同一类型的。

但假如真实要做一个数据库的处理计划,现在的干流思路仍是核算与存储别离,为什么会呈现核算与存储别离呢?首要原因有以下几点:现在的网络延时一直在下降,带宽一直在添加,从我个人的作业经验来看,未来或许还有更大的网络带宽呈现;但与此一同,磁盘IO的吞吐量并没有添加得像网络这么快。

此外,存储的虚拟化有利于本钱下降,散布式存储有利于进步卢海鹏试咪IOPS。假如在一个机器上做Raid的话,它的功用会比单个硬盘要好许多;假如选用散布式体系写入,它的IOPS其实会更高。

现在业界比较有名的几个核算与存储别离的处理计划,最著名的便是亚马逊的Aurora。

Aurora为什么挑选核算存储别离?关于这一点,还需求探求其时秀才亚马逊做RDS的处理计划怎样。亚马逊RDS,便是它们的Realtional Database Service,全体数据存在local disk/EBS上面。

咱们能够看到,整个IO的写入链条是比较长的,要把数据落盘,binlog落盘,redo log落盘,并且整个binlog两头要同步,最终还要把EBS的数据适当地备份到云存储中去。(这个仅仅备份,与实时写入无关)。

由于链路比较长,并且包含整个EBS的完结中,EBS便是个散布式的快存储,实质上也是多副本的。在多副本的状况下,EBS在远端也要做整个数据的同步,所以Aurora的规划方针便是考虑能不能把存储与核当作一些相应的别离。动身点便是数据库存储引擎能不能与散布式块存储融合在一块,融组成一个新的存储引擎。

别的一个计划是F1/Spanner的计划,思路又是什么呢?

做一个散布式体系,假如去兼容MySQL比较费事的话,那是不是能够重整旗鼓,做一个新的散布式体系。

它的思路很简略,便是从头去改写一些SQL,所以像F1/Spanner并不兼容MySQL的一些协议时,就会引进新的散布式业务办理,把SQL都拆解成K/V的一些操作结构,对这种计划而言,SQL的兼容性是个长时刻耗时并且是无限挨近的一个进程,首要需兼容已有的生态会比较吃力。但假如是一个新业务,用这种散布式计划就没有问题;假如是个旧业肥壮的女性务,有自己老练的SQL,想用它就比较困难了。

能够看到对一个MySQL服务而言,其实有两部分组成,一部分是Server,一部分Storage。Storage规范的架构是redo log加个data,这是InnoDB的一个结构,现在InnoDB现已成为MySQL的一个规范,咱们都是依照这种办法去做的。

关于主从同步,是用binlog仿制的办法,把binlog仿制到Slave这边,Slave对binlog重放,然后Slave就有完好数据,这是传统的一个数据库组成形式。

关于MySQL而言,它的数据流向会是什么姿态的?榜首步,假如针对一个业务或许一个SQL句子,它会写许多redo log。第二步,会写到binlog中,binlog今后会做半同步,会同步到Slave中,回来一个信息,这时分能够进行一个全体的commit。

关于整个数据流向的一个示意图,主从之间用了全体的binlog仿制办法去做。假如想做一个散布式体系的话,并且动身点是不能够将这些相同的数据放在同一个散布式体系中,需求做哪些作业?

咱们发现,假如核算和存储别离之后,把一切的存储都放在一个散布式存储体系中去,master与slave读的是同一个数据,其实就不需求binlog了,这个是比较简单了解的。binlog用来传输详细的数据,由于数据都放在一同。

3

核算和存储别离的长处

在于散布式存储的存储空间会相对大一些;别的一点,假如说要添加一个新的slave,曾经在MySQL的主从仿制中添加一个新的slave,一般怎样做?

要么就新建一个空白的slave,渐渐从组合开端同步数据,总而言之便是运用binlog同步数据;但假如整个数据量比较大的话,树立一个新的从时刻会十分长,或许说依据备份去重建一个新的从,从而仿制数据库备份。在这个根底上再去追新日志,无论怎样添加一个节点,时刻应该仍是要以分钟计,至少以10分钟为单位。

但在核算与存储别离之后,新建一个slave时刻就十分快了,并且备份数据的时分会快许多。由于针对传统主从体系做备份,其实都要去做一个文件体系的备份。做文件体系快照也行,用mysql dum景p也行,需求把本地文件传到云端存储;在散布式存储体系中,能够把这个使命搬运给底层体系去做,当然数据的强共同还要靠底层存储去确保。

假如把核算、存储别离之后,整个高可用切换会是什么姿态的?关于曾经的MySQL而言,一个主从切换其实比较简略,由于主随从是两个独立的存储和核算,之间没有相关联系,主切换到从,最多便是binlog还没有回放完;但关于整个核算存储别离之后,它的改动仍是有一些的。

例如榜首个改动,咱们能够看到关于传统数据库而言,必要,带你吃透散布式的精华!它的R爱大了吧受伤了吧edo日志是一个循环的文件体系,能够是三个Redo日志循环运用;假如在一个存储别离,核算别离的环境,它的Redo日志根本会规划成按编号去排序的状况。

等主从切换之后,必要,带你吃透散布式的精华!log buffer和buffer pool,或许需求一点时刻去重建它的两个buffer pool。由于在传统意义上,传统的MySQL主从切换都需求去依据日志略微重建一下buffer pool。

关于备份而言,根本上改动也比较大,整个备份会根据底层的块存储:一部分能够去备份整个page页的数据;别的一部分,需求去做Redo日志的增量备份,这样很快能完结一个数据库的备份。

其实在云端去做一个数据库的备份会比自己建立两台物理机去做备份更快,为什么?

由于在云端散布式体系中,做备份的时分不是一台机器在备份,由于存储在不同的机器上。 关于一个新建的slave而言,假如咱们在云端核算、存储别离的状况下去新建一个slave的话,新建slave的速度也会比传统的办法快十分多,由于整个数据块是现已存在了,直接去读就行,不需求从头再仿制一份。

可是这种状况也带来不少问题。由于底层的文件体系其备份数是有限的,副本数也是有限的,深层次的原因是由于底层的散布式文件体系的IOPS是有限的,关于一个主从联系私密保养,像传统形式下的MySQL,其实并没有这种约束。

4

总结

最终总结一下这几个计划的优缺陷:

比方客户端计划,它的长处是能够接多种数据源,只需数据库是兼容JDBC的,都能够去对接,并且功用上比较好。但进步功用的一同也带来别的一个问题花胶是什么,衔接数或许会比较多,由于客户端十分多,每个客户端都与MySQL进行衔接的话,MySQL衔接会特别多。

缺陷也十分显着,假如公司中只以Java为主,那没问题,开发一个jar包,咱们用起来会十分了解;假如说一个公司用Python、C++,还用Go,每个言语都要写一个客户端,其实是十分苦楚的。别的客户端发布了,SDK发布之后晋级起来也十分费事。

所以绝大部分的厂商会选用Proxy的计划,由于Proxy的计划简单办理,晋级也比较简单,并且语法根本兼容,不存在多言语S红豆红俞静DK的问题。兼容了MySQL的一些语法之后,传统的MySQL客户端,各种言语的SDK都能用,一切MySQL第三方开发的SDK也都能用,缺陷在于不支撑业务,或许对业务的支撑是有限的。

关于核算与存理别离计划而言,它的长处十分显着且性价比特别高,为什么?

云端购买云数据库的时分,许多时分功用与购买有联系。例如买个1C2G10GB的小型数据库,OPS或许只需几百上千;但关于真实的核算与存储别离的计划而言,开端购买的类型或许是比较小的,购买的标准或许也比较小,可是能够到达很高的IOPS功用,数据库功用并不会受限于你购买的标准。

关于缺陷,仍是全体的存储空间有限,或许最大只能支撑64T或许128T,由于每个数据库的散布式存储中其副本数是有限的,只读节点或许受限于,只能有15个或许14个,但这个都不要紧。我信任关于绝大多数的用户而言,这个仍是足够用的。别的一个缺陷是开发难度,但这个缺陷仅仅开发厂必要,带你吃透散布式的精华!商的痛点,与用户没有联系。

关于重整旗鼓,像Spanner/TiDB这种数据库计划,它的可扩展性就比较高。由于关于像Aurora这种核算与存储别离的数据库而言存储空间究竟是有限的,但对这种数据库,它的存储空间能够被以为是无限扩展的,能够支撑一个上P的数据库也没问题。

仍旧谈谈缺陷。便是很难去兼容现有的一些SQL语法,是一个比较大的应战。例如TiDB是国产比较优异的数据库了,也声称对MySQL的语法兼容是比较完美的,但事实上仍是许多句子是无法做到兼容的,不是不想,是由于做起来特别难!由于底层的数据结构决议了一些功用,也决议了要去兼容一些SQL句子其价值是十分大的。

以上为公开课的一切内容

重视京东云开发者社区,回复“PPT0424”获取课程PPT。

Q&A

课程问答

Q

为什么云存储有容量约束?技能上的底子原因是什么?

A

理论上讲咱们做散布式存储的时分,已然讲它是个散布式存储,为什么它还有空间上的约束?包含咱们做快存储,假如咱们用过云borrow都会用像亚马逊的EBS,包含京东云的云硬盘盘,这几个问题的实质是相同的,为什么快存储和核算与存储别离的数据库它的空间都是有容量约束的?咱们为什么无法去请求一个无限大的云硬盘?这个问题能够转化成别的一个问题,为什么咱们在云厂商里边无法去请求一个超大空间的云硬盘?咱们都没有看到过哪个厂商供给10个PB,乃至说100PB的云硬盘,这是为什么?这儿面仍是要回到我最开端讲的,便是说你的功用规划方针和你底层存储结构决议了你的产品功用,决议了你产品的约束。每一家厂商的底层完结的原理都不太相同,可是结构都仍是比较相同的。假如说咱们要供给一个十分大的存储空间的话,它的meta信息办理会受一个很大的约束。一同,为什么不会供给超大规模的云硬盘或许说数据库?也受限于你本机的网络带宽也是有限的。

举个比如,给你供给10PB巨细的数据库或许给你供给10PB的云硬盘,理论上是能够这么做,可是你往里边写的时分,你写的IO仍是受限于你本机网络的带宽。一同对整个云必要,带你吃透散布式的精华!硬盘后端或许数据库后端快信息、TiDB信息的存储也会带来新的应战。

所以供给10TB的云硬盘是比较简单的,我是说咱们为什么不供给10PB的云硬盘,没有一家厂商供给这么大的云硬盘,不是说技能上不或许,仅仅说这个产品功用上讲,哪怕给你供给了这么大的云硬盘或许说数据库,你在单机运用上也发挥不出这么大容量的优势,首要是这个原因。

Q

京东有专门数据库团队针对兼容MySQL的散布式存储引擎么?

A

有,之前是这样的,京东之前的MySQL散布式处理计划,咱们选用的也是用Proxy的计划,为什么会挑选用Proxy的计划?原因有以下几点:榜首点,Proxy计划开发起来比从头改写引擎仍是要相对简单一些的。第二点,你在一个公司内部去推一个散布式计划,业务部门仍是比较乐意合作的,由于他碰到了存储空间的问题,他需求有团队去处理这个问题。

为什么咱们现在开端要做兼容MySQL的散布式存储引擎?是由于咱们在云端给用户供给一个想比单机版功用更好,空间更大的数据库服务的时分,咱们有必要要考虑到用户的运用场景,用户现有的架构,用户的运用习气。假如说咱们要让用户来用咱们这个Proxy的计划,咱们的Proxy计划在京东云上叫DRDS服务,假如让用户来用咱们DRDS服务的话,其实要针对他自己的业务进行一些分库分表的操作,要约束他的SQL句子,对用户而言他的改造量是比较大的。并且许多时分,关于一些杂乱业务而言,它并不具有有这样的才能去改造它的业务。所以关于用户而言,咱们仍是期望能够供给一个功用也足够好,空间也相对比较大的,比方说空间也能满意它的要求的,又不需求它进行任何代码更改的数据库服务,所以咱们也会做针对兼容MySQL的散布式存储引擎做开发。

Q

云存储有没有分库分表,假如有是怎样做的?

A

云存储跟数据库仍是两个彻底不相同的东西,我了解你想要问的是云存储去存它的meta信息的时分有没有用到分库分表,我觉得你应该是问这个意思。绝大部分的云存储必定是要用散布式的存储体系或许K/V,不管是K/V也好,仍是MySQL也好,它必定需求做散布式TiDB信息的存储。因而咱们能够看到,它对应的云存储的存储办法是一个文件名对应它相应的数据内容,咱们能够了解成它是一个超大规模K/V的耐久化程度结构,仅仅它的value能够变成十分大,能够从一个KB到10个T都行,这个就看你的文件巨细了。文件怎样存储,放在哪些机器上?这其实算一个TiDB信息,这个信息是海量的,关于一切的云存储而言它必定要用到散布式,至少用到散布式K/V的存储。散布式K/V存储触及到的内容跟你做一个散布式数据库的思路和办法仍是十分相似的。

Q

散布式缓存和散布式数据库联系是怎样的?

A

这两个散布式的难度不相同,它处理问题的难度不bareback相同。散布式缓存体系,比方说咱们以Codis为例,Codis做的姿态仍是会很像咱们方才讲的数据库的Proxy的计划,它长的简直一盲女惊心模相同,仅仅一个支撑MySQL的语法,一个支撑Redis的语法罢了。散布式缓存它面对的应战比较小,由于它不需求支撑业务,并且散布式缓存体系支撑的语法里边比较简略,它并没有杂乱的SQL、join查询这种东西,它的句子支撑起来比较简单。关于一个数据库而言,你假如真实想做到一个散布式数据库,并且兼容大部分的SQL语法的话,你要做散布式业务,并且要支撑各种杂乱的SQL,子查询,应战仍是十分大的,这两者的难度彻底不男生英文名相同,能够以为散布式数据库比散布式缓存要做的难度至少乘以10。

END

声明:该文观念仅代表作者自己,搜狐号系信息发布渠道,搜狐仅供给信息存储空间服务。
声明感谢您对我们网站的认可,非常欢迎各位朋友分享本站内容到个人网站或者朋友圈,
转转请注明出处:http://www.sdyrjc.com/articles/70.html
点赞 打赏

打赏方式:

支付宝扫一扫

微信扫一扫

扫一扫
QQ客服:111111111
工作日: 周一至周五
工作时间: 9:00-18:00