文档章节

MyCat与TinyDBRouter性能PK

悠悠然然
 悠悠然然
发布于 2015/12/07 12:58
字数 1787
阅读 8541
收藏 116

现在经常说来水平扩展,这个时候一般都会说到数据库的水平扩展,这个时候一般就会用到数据库的分库分表方案。关于这一块,可能大家也都一些开源或商业的方案进行过一些研究。

今天我就简单的拿一些性能测试数据进行简单的展示,看看TinyDbRouter和Mycat与纯纯的JDBC之间的性能差异情况。

环境说明

为了进行这项测试,我就得准备一下测试环境,因为做的是对比测试,因此用多少NB的服务器不是重点。另外,由于虚拟机之间会有CPU、磁盘IO的资源竞争,因此我选择了用独立的计算机进行这项测试,这样才可以真正的模拟水平扩展时的硬件拓展方式。

为此我找了4台笔记本电脑,配置如下:

客户端和服务器 硬件配置:
  硬件平台:windows7旗舰版 32位)物理机
  CPU 4CPUs
  处理器:Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz
  内存:4GB
  硬盘:500G
嗯嗯,配置一般,不过做这项测试应该是OK的。

测试方案

这次主要测试多种方式下数据库的插入和查询方面方面的性能差异。

  1. 使用一个数据库,中间加一道分库分表中件间,然后测试直接使用JDBC和加一层中间件之间的性能对比,看看加了一层对性能的影响
  2. 使用两个物理数据库,对数据进行水平分片,然后测试直接使用JDBC操作一个库和用了中间件分成两个库之间的性能做对比

环境说明:为了更好的进行观察和分析,采用MyCat方式式,MyCat采用了独立部署为一台服务器的方式

测试数据

单个数据库增加TinyDBRouter访问时的插入性能影响

从上面的数据可以看到:在没有压力的情况下,在插入时增加了TinyDbRouter与不增加TinyDbRouter层时的性能对比为下降了6.6%,而在有压力的情况下性能下降大致为15%左右。

而在查询的时候,由于查询的时间较插入时间长许多,因此可以看到TinyDbRouter对于查询的影响可以忽略不计。

相同数据量采用TinyDbRouter分库的查询性能对比


从上面的数据可以看到,在没有压力的情况下,插入的速度较单库相比有些许下降,但是随着压力的增加,分片了的性能逐步上升,虽然压力没有加大到最大,但是处理性能已经是未分片的1.5倍左右,说明通过分片确实可以有效提升插入的TPS数量。


我们再来看看查询方面的性能差异,由于同样的记录数,分片方案中把数据均衡的分配到了两个不同的库中,因此不带分库键查询时,查询性能大致是未分库方式的2倍左右浮动(这里的查询条件是动态生成,因此刨除了缓冲方面的因素);带有分库键进行查询时,查询性能大致是未分库方式的4倍左右浮动。

总结,通过分片的方式进行水平扩展,确实可以有效的提升插入和查询的效率。提升效率的多少与水平扩展的数量大致成正比。(实际上,随着分片个数的增加,每台机器的能力扩展系数是在慢慢减小的)。

相同数据量采用MyCat分库的插入性能对比

通过上面的测试,可以看到,使用 MyCat把数据分到两个物理数据库,也有效的提升了插入效率,这方面和TinyDbRouter的基本相同。

相同数据量采用MyCat分库的查询性能对比


接下来就是对MyCat的查询方面的性能进行对比测试,性能数据较不分库有一定提升,但是相对于TinyDbRouter就有一定的差距。

总结

不论是哪种分库分表方案,都可以有效提升插入和查询的TPS。

有分库键查询和没有分库键查询,性能相差明显。

TinyDbRouter和MyCat的数据库水平扩展中间件在插入方面的性能损耗相差不大,在查询方面TinyDbRouter的性能较MyCat有一定的优势,随着集群大小的变化,会导致性能的差距进一步扩大

原因分析如下:

表明原因分析:MyCat服务器自已的CPU占有率比较高,说明其计算量也非常大,导致在MyCat服务器中产生了一定性能损耗。由于MyCat在这种测试方式下是单点,因此随着水平扩展的数据库数量的增加,其单点压力也会越来越大。

深层次原因分析:MyCat是由独立的服务器来进行查询及结果的合并及相关处理,因此必须把数据从数据库服务器取到MyCat服务器上进行一定的运算后再向客户端进行返回数据;而TinyDBRouter由于部署到数据库客户端,因此这部分计算由数据库客户端进行计算,充分的利用了数据库客户端的计算能力,因此不存在单点问题。

同样的一个处理,MyCat的方式是:客户端->MyCat->Mycat计算后->水平扩展的数据服务器(这里是2)->MyCat合并结果后->客户端

而TinyDBRouter的方式是:客户端->(DBRouter计算后)->水平扩展的数据服务器(这里是2)->(DBRouter计算后)->客户端,网络传输次数较MyCat少了一半。另外由于TinyDBRouter的合并计算在客户端进行,因此可以进行更深入的优化以提升数据获取速度。

声明

我们一开始把MyCat服务器和其中一台数据库服务器部署在一台物理机,结果数据非常不合常理,因此才把它独立部署为一台服务器。

我们一开始是用Delete语句清空数据的,后来发现这种方式对测试数据有比较大的影响,同样的数据量与测试方法,数据相去甚远。采用了DROP表现重建的方式后保证了数据的可验证性,同样的数据量与测试方式,数据非常接近。

我们在测试过程中,秉持了客观公正的心态来进行这项测试,也是为了找准自己的位置,和同类产品学习的态度进行的。

我们保证没有对测试数据进行任何的人为调整,而完全忠实于实验中采集的数据。

即使同样时刻的测试数据,也会有轻微的不同,但是差距非常小。


© 著作权归作者所有

共有 人打赏支持
悠悠然然

悠悠然然

粉丝 2381
博文 184
码字总数 360373
作品 14
杭州
架构师
加载中

评论(99)

悠悠然然
悠悠然然

引用来自“ahyyxx222”的评论

有没有考虑将mycat部署到每个应用服务器上,每个应用服务器节点用本物理机的mycat,这样更接近TinyDBRouter的部署方式,比独立部署mycat少一道网络IO,也充分利用下应用服务器的CPU,而不是单点mycat计算。
这个应该不成立
ahyyxx222
ahyyxx222
有没有考虑将mycat部署到每个应用服务器上,每个应用服务器节点用本物理机的mycat,这样更接近TinyDBRouter的部署方式,比独立部署mycat少一道网络IO,也充分利用下应用服务器的CPU,而不是单点mycat计算。
杨小杨
杨小杨
第一个图,32线程DBRouter数据写错了吗,
乌龟壳
乌龟壳

引用来自“songwie”的评论

测试端模式简单测试性能本来就比中间件模式高,来个join 10个亿客户端试下 客户端不挂了么?只做简单curd 测试没什么对比性,要的是大的join 聚合 及跨集群的大数据量测试才会体验出中间件的优势,而且客户端模式对代码侵入性高,也无法管理数据源连接 容易数据源连接爆掉

引用来自“悠悠然然”的评论

亲,你的理解可能有点偏。 1.数据库不挂,TinyDBRouter就不会挂 2.中间加一层注定影响更大 3.TinyDBRouter是在JDBC层做的,因此对代码没有任何侵入 4.数据源爆掉一说肯定你想歪了,这种模式会爆,代理方式一样会爆。 5.我们可能没有你想的那么聪明,但也没有你想的那么笨

引用来自“乌龟壳”的评论

中间件就像数据库连接池一样,维持一定数量的数据库连接同时,提供大量的透明额外连接给应用层。如果每个应用都直接连数据库,多了就不行了。你的业务场景是独立的应用个数没有超过数据库的承受能力,所以在应用层直接连接多个数据库是可行的。

引用来自“悠悠然然”的评论

其实你这里有个假的逻辑在这里,所以自己感觉抓到的根本,实际上不堪一击。 1.我的方案,如果分成N个库,如果建M个大小的连接池,实际上是每个库上都会产生M个连接,也就是在客户端这边会有N*M个连接,如果再有K台服务器,那么每个数据库服务器上就有K*M*N个连接。 2.你说的方案,那么在每个客户端上只有M个连接,你说得是这个意思吧?如果再有K台服务器,你的意思是也只在K*M个连接,是吧?表面上看看是这样的,好吧到此为止我支持你的观点。但是等等你这么多连接都连到了一台MyCat服务器上,这台服务与数据库之间的连接是多少呢?我告诉你不多不少正好K*M*N个连接。所以,追根到底,本质上没有什么区别,只是多了一层而已。但是这个时候你带来的网络交互及数据解包打包过程都会增加一倍,而且本来是想排除单点的,你这里又人为造出一个单点。CPU,网络IO的瓶颈又会产生。呵呵,我这么解释如果你还不明白或者根本不想明白的话,后面就不用聊了,大家都是搞技术的,都懂的。

引用来自“乌龟壳”的评论

1.中间件维护**固定数量**的到实际DB的连接,提供给应用超越实际DB连接数的支持。2.但是如果某一时刻没有实际DB连接空闲,这些超出的连接里的查询会排队等待。3.数据库连接池不都这样的么。4.这个中间件可以水平扩展消除单点,它只是个路由。5.这样可以提供给任何场景(语言、工具等)只要使用了mysql协议的数据库查询使用。6.网络通信开销确实是增加了一倍,但除了大量数据导入导出,网络开销在数据库场景下都不是压力点。

引用来自“悠悠然然”的评论

亲,如果只是网络转发一下,对性能的影响当然是不大的,但是你这里涉及到一个数据打包与解包的问题,打包和解包的性能压力就不能被忽略了。比如同样执行select * from xxx_table order by some_fields,这个时候服务器的计算量就可想而知了。中间件水平扩展,消除单点,第一会增加成本,第二当水平的数量多的时候,战胜的连接数也会增加。如果放大到和应用服务器数量一样的时候,其实就变成和我们方案一样了(只是还要多一层服务器)。当然,没有任何一种方案都是全是优点没有缺点的。

引用来自“乌龟壳”的评论

比如分库分表的策略,用中间件只用维护一个地方,但是每个应用的话就要每个应用独立去设置。其它就是中间件可以控制对实际数据库的并发数量,而每个应用维护就比较难。每个应用维护方便部署没有单点架构简单,如果数量不大对整体性能损耗小。所以其实看场景,没必要凭空争论哪个好。另外提一下中间件水平扩展一般都伴随着每个中间件维持的数据库连接数减少的配置策略。

引用来自“悠悠然然”的评论

亲,我们有配置中心的,配置信息都从中心拿。

引用来自“乌龟壳”的评论

回看了下这个帖子,发现一个问题,这个方案相比中间件方案来说,可以算是为mysql/sqlserver定制的,因为mysql本身可以支持大量连接,mysql会为这些连接排队,每个连接只是一个线程。但是基于每个连接一个进程的数据库(Oracle/PG)你这个方案在水平扩展到一定程度后就不太合适,需要加中间件了,因为对实际DB的连接数太多了。

引用来自“悠悠然然”的评论

亲,你仔细推演一下,就会发现两种方案区别不大。 当然,你可以举一个最极端的场景来说mycat方案是有优势的。 比如:每次只有一个分片参与处理,那么这个时候,是可以最大量的发挥效能的。 但是实际上我也可以在每个Client分配比较少的连接来达到同样的效果,只有参与分片处理的连接参与执行。

引用来自“乌龟壳”的评论

假设集群中某个时间有1000个应用要操作DB1,用中间件可以限制到DB1的实际连接只有100个,但用这种方案只能1000个。

引用来自“悠悠然然”的评论

嗯嗯,您举的例子是成立的。 但是实际应用过程中,您说的情况是不会出现的。 因为如果进行了分库或分表,业务肯定是高内聚的,就不会是例子中假设的情况情况了。

引用来自“乌龟壳”的评论

如果是同一个应用开了1000个的集群呢?

引用来自“悠悠然然”的评论

我来想一下,比如:阿里巴巴的一个小应用,有没有1000台的集群? 1000台,每台tps就算100好了,大致一秒的TPS是10万,一天按6小时计算,大概是2,160,000,000 也就是21亿的TPS。 那阿里的小应用,何止上千?假设有1000,然后每个都有这么大的流量。 就是一天有2万亿的TPS。地球人就按100亿计算好了,连老得不行的,带还不会动的,全部每天给我点200次,这是什么概念? 如果我有这些流量,我就直接把马云收购了,然后让马云帮我解决问题。

引用来自“乌龟壳”的评论

我只是稍微抽象一下,一个应用对一个数据库一般不止一个连接,一个数据库也不止能负载100个连接。总之够用就行了,退一步说,用中间件还是不用和应用都是解耦的,如果必须需要用到什么的时候再切换就是了。我只能总结地说,如果对于一般规模的应用,如果仅仅是java客户端,tinydbrouter是够用了,足够灵活方便。

引用来自“悠悠然然”的评论

亲,不是抬杠的意思,实际上在绝大多数场景下都是够的。 各种方案都是有其优点和缺点的,这也是大千世界如此瑰丽的原因。
点个赞
悠悠然然
悠悠然然

引用来自“songwie”的评论

测试端模式简单测试性能本来就比中间件模式高,来个join 10个亿客户端试下 客户端不挂了么?只做简单curd 测试没什么对比性,要的是大的join 聚合 及跨集群的大数据量测试才会体验出中间件的优势,而且客户端模式对代码侵入性高,也无法管理数据源连接 容易数据源连接爆掉

引用来自“悠悠然然”的评论

亲,你的理解可能有点偏。 1.数据库不挂,TinyDBRouter就不会挂 2.中间加一层注定影响更大 3.TinyDBRouter是在JDBC层做的,因此对代码没有任何侵入 4.数据源爆掉一说肯定你想歪了,这种模式会爆,代理方式一样会爆。 5.我们可能没有你想的那么聪明,但也没有你想的那么笨

引用来自“乌龟壳”的评论

中间件就像数据库连接池一样,维持一定数量的数据库连接同时,提供大量的透明额外连接给应用层。如果每个应用都直接连数据库,多了就不行了。你的业务场景是独立的应用个数没有超过数据库的承受能力,所以在应用层直接连接多个数据库是可行的。

引用来自“悠悠然然”的评论

其实你这里有个假的逻辑在这里,所以自己感觉抓到的根本,实际上不堪一击。 1.我的方案,如果分成N个库,如果建M个大小的连接池,实际上是每个库上都会产生M个连接,也就是在客户端这边会有N*M个连接,如果再有K台服务器,那么每个数据库服务器上就有K*M*N个连接。 2.你说的方案,那么在每个客户端上只有M个连接,你说得是这个意思吧?如果再有K台服务器,你的意思是也只在K*M个连接,是吧?表面上看看是这样的,好吧到此为止我支持你的观点。但是等等你这么多连接都连到了一台MyCat服务器上,这台服务与数据库之间的连接是多少呢?我告诉你不多不少正好K*M*N个连接。所以,追根到底,本质上没有什么区别,只是多了一层而已。但是这个时候你带来的网络交互及数据解包打包过程都会增加一倍,而且本来是想排除单点的,你这里又人为造出一个单点。CPU,网络IO的瓶颈又会产生。呵呵,我这么解释如果你还不明白或者根本不想明白的话,后面就不用聊了,大家都是搞技术的,都懂的。

引用来自“乌龟壳”的评论

1.中间件维护**固定数量**的到实际DB的连接,提供给应用超越实际DB连接数的支持。2.但是如果某一时刻没有实际DB连接空闲,这些超出的连接里的查询会排队等待。3.数据库连接池不都这样的么。4.这个中间件可以水平扩展消除单点,它只是个路由。5.这样可以提供给任何场景(语言、工具等)只要使用了mysql协议的数据库查询使用。6.网络通信开销确实是增加了一倍,但除了大量数据导入导出,网络开销在数据库场景下都不是压力点。

引用来自“悠悠然然”的评论

亲,如果只是网络转发一下,对性能的影响当然是不大的,但是你这里涉及到一个数据打包与解包的问题,打包和解包的性能压力就不能被忽略了。比如同样执行select * from xxx_table order by some_fields,这个时候服务器的计算量就可想而知了。中间件水平扩展,消除单点,第一会增加成本,第二当水平的数量多的时候,战胜的连接数也会增加。如果放大到和应用服务器数量一样的时候,其实就变成和我们方案一样了(只是还要多一层服务器)。当然,没有任何一种方案都是全是优点没有缺点的。

引用来自“乌龟壳”的评论

比如分库分表的策略,用中间件只用维护一个地方,但是每个应用的话就要每个应用独立去设置。其它就是中间件可以控制对实际数据库的并发数量,而每个应用维护就比较难。每个应用维护方便部署没有单点架构简单,如果数量不大对整体性能损耗小。所以其实看场景,没必要凭空争论哪个好。另外提一下中间件水平扩展一般都伴随着每个中间件维持的数据库连接数减少的配置策略。

引用来自“悠悠然然”的评论

亲,我们有配置中心的,配置信息都从中心拿。

引用来自“乌龟壳”的评论

回看了下这个帖子,发现一个问题,这个方案相比中间件方案来说,可以算是为mysql/sqlserver定制的,因为mysql本身可以支持大量连接,mysql会为这些连接排队,每个连接只是一个线程。但是基于每个连接一个进程的数据库(Oracle/PG)你这个方案在水平扩展到一定程度后就不太合适,需要加中间件了,因为对实际DB的连接数太多了。

引用来自“悠悠然然”的评论

亲,你仔细推演一下,就会发现两种方案区别不大。 当然,你可以举一个最极端的场景来说mycat方案是有优势的。 比如:每次只有一个分片参与处理,那么这个时候,是可以最大量的发挥效能的。 但是实际上我也可以在每个Client分配比较少的连接来达到同样的效果,只有参与分片处理的连接参与执行。

引用来自“乌龟壳”的评论

假设集群中某个时间有1000个应用要操作DB1,用中间件可以限制到DB1的实际连接只有100个,但用这种方案只能1000个。

引用来自“悠悠然然”的评论

嗯嗯,您举的例子是成立的。 但是实际应用过程中,您说的情况是不会出现的。 因为如果进行了分库或分表,业务肯定是高内聚的,就不会是例子中假设的情况情况了。

引用来自“乌龟壳”的评论

如果是同一个应用开了1000个的集群呢?

引用来自“悠悠然然”的评论

我来想一下,比如:阿里巴巴的一个小应用,有没有1000台的集群? 1000台,每台tps就算100好了,大致一秒的TPS是10万,一天按6小时计算,大概是2,160,000,000 也就是21亿的TPS。 那阿里的小应用,何止上千?假设有1000,然后每个都有这么大的流量。 就是一天有2万亿的TPS。地球人就按100亿计算好了,连老得不行的,带还不会动的,全部每天给我点200次,这是什么概念? 如果我有这些流量,我就直接把马云收购了,然后让马云帮我解决问题。

引用来自“乌龟壳”的评论

我只是稍微抽象一下,一个应用对一个数据库一般不止一个连接,一个数据库也不止能负载100个连接。总之够用就行了,退一步说,用中间件还是不用和应用都是解耦的,如果必须需要用到什么的时候再切换就是了。我只能总结地说,如果对于一般规模的应用,如果仅仅是java客户端,tinydbrouter是够用了,足够灵活方便。
亲,不是抬杠的意思,实际上在绝大多数场景下都是够的。 各种方案都是有其优点和缺点的,这也是大千世界如此瑰丽的原因。
乌龟壳
乌龟壳

引用来自“songwie”的评论

测试端模式简单测试性能本来就比中间件模式高,来个join 10个亿客户端试下 客户端不挂了么?只做简单curd 测试没什么对比性,要的是大的join 聚合 及跨集群的大数据量测试才会体验出中间件的优势,而且客户端模式对代码侵入性高,也无法管理数据源连接 容易数据源连接爆掉

引用来自“悠悠然然”的评论

亲,你的理解可能有点偏。 1.数据库不挂,TinyDBRouter就不会挂 2.中间加一层注定影响更大 3.TinyDBRouter是在JDBC层做的,因此对代码没有任何侵入 4.数据源爆掉一说肯定你想歪了,这种模式会爆,代理方式一样会爆。 5.我们可能没有你想的那么聪明,但也没有你想的那么笨

引用来自“乌龟壳”的评论

中间件就像数据库连接池一样,维持一定数量的数据库连接同时,提供大量的透明额外连接给应用层。如果每个应用都直接连数据库,多了就不行了。你的业务场景是独立的应用个数没有超过数据库的承受能力,所以在应用层直接连接多个数据库是可行的。

引用来自“悠悠然然”的评论

其实你这里有个假的逻辑在这里,所以自己感觉抓到的根本,实际上不堪一击。 1.我的方案,如果分成N个库,如果建M个大小的连接池,实际上是每个库上都会产生M个连接,也就是在客户端这边会有N*M个连接,如果再有K台服务器,那么每个数据库服务器上就有K*M*N个连接。 2.你说的方案,那么在每个客户端上只有M个连接,你说得是这个意思吧?如果再有K台服务器,你的意思是也只在K*M个连接,是吧?表面上看看是这样的,好吧到此为止我支持你的观点。但是等等你这么多连接都连到了一台MyCat服务器上,这台服务与数据库之间的连接是多少呢?我告诉你不多不少正好K*M*N个连接。所以,追根到底,本质上没有什么区别,只是多了一层而已。但是这个时候你带来的网络交互及数据解包打包过程都会增加一倍,而且本来是想排除单点的,你这里又人为造出一个单点。CPU,网络IO的瓶颈又会产生。呵呵,我这么解释如果你还不明白或者根本不想明白的话,后面就不用聊了,大家都是搞技术的,都懂的。

引用来自“乌龟壳”的评论

1.中间件维护**固定数量**的到实际DB的连接,提供给应用超越实际DB连接数的支持。2.但是如果某一时刻没有实际DB连接空闲,这些超出的连接里的查询会排队等待。3.数据库连接池不都这样的么。4.这个中间件可以水平扩展消除单点,它只是个路由。5.这样可以提供给任何场景(语言、工具等)只要使用了mysql协议的数据库查询使用。6.网络通信开销确实是增加了一倍,但除了大量数据导入导出,网络开销在数据库场景下都不是压力点。

引用来自“悠悠然然”的评论

亲,如果只是网络转发一下,对性能的影响当然是不大的,但是你这里涉及到一个数据打包与解包的问题,打包和解包的性能压力就不能被忽略了。比如同样执行select * from xxx_table order by some_fields,这个时候服务器的计算量就可想而知了。中间件水平扩展,消除单点,第一会增加成本,第二当水平的数量多的时候,战胜的连接数也会增加。如果放大到和应用服务器数量一样的时候,其实就变成和我们方案一样了(只是还要多一层服务器)。当然,没有任何一种方案都是全是优点没有缺点的。

引用来自“乌龟壳”的评论

比如分库分表的策略,用中间件只用维护一个地方,但是每个应用的话就要每个应用独立去设置。其它就是中间件可以控制对实际数据库的并发数量,而每个应用维护就比较难。每个应用维护方便部署没有单点架构简单,如果数量不大对整体性能损耗小。所以其实看场景,没必要凭空争论哪个好。另外提一下中间件水平扩展一般都伴随着每个中间件维持的数据库连接数减少的配置策略。

引用来自“悠悠然然”的评论

亲,我们有配置中心的,配置信息都从中心拿。

引用来自“乌龟壳”的评论

回看了下这个帖子,发现一个问题,这个方案相比中间件方案来说,可以算是为mysql/sqlserver定制的,因为mysql本身可以支持大量连接,mysql会为这些连接排队,每个连接只是一个线程。但是基于每个连接一个进程的数据库(Oracle/PG)你这个方案在水平扩展到一定程度后就不太合适,需要加中间件了,因为对实际DB的连接数太多了。

引用来自“悠悠然然”的评论

亲,你仔细推演一下,就会发现两种方案区别不大。 当然,你可以举一个最极端的场景来说mycat方案是有优势的。 比如:每次只有一个分片参与处理,那么这个时候,是可以最大量的发挥效能的。 但是实际上我也可以在每个Client分配比较少的连接来达到同样的效果,只有参与分片处理的连接参与执行。

引用来自“乌龟壳”的评论

假设集群中某个时间有1000个应用要操作DB1,用中间件可以限制到DB1的实际连接只有100个,但用这种方案只能1000个。

引用来自“悠悠然然”的评论

嗯嗯,您举的例子是成立的。 但是实际应用过程中,您说的情况是不会出现的。 因为如果进行了分库或分表,业务肯定是高内聚的,就不会是例子中假设的情况情况了。

引用来自“乌龟壳”的评论

如果是同一个应用开了1000个的集群呢?

引用来自“悠悠然然”的评论

我来想一下,比如:阿里巴巴的一个小应用,有没有1000台的集群? 1000台,每台tps就算100好了,大致一秒的TPS是10万,一天按6小时计算,大概是2,160,000,000 也就是21亿的TPS。 那阿里的小应用,何止上千?假设有1000,然后每个都有这么大的流量。 就是一天有2万亿的TPS。地球人就按100亿计算好了,连老得不行的,带还不会动的,全部每天给我点200次,这是什么概念? 如果我有这些流量,我就直接把马云收购了,然后让马云帮我解决问题。
我只是稍微抽象一下,一个应用对一个数据库一般不止一个连接,一个数据库也不止能负载100个连接。总之够用就行了,退一步说,用中间件还是不用和应用都是解耦的,如果必须需要用到什么的时候再切换就是了。我只能总结地说,如果对于一般规模的应用,如果仅仅是java客户端,tinydbrouter是够用了,足够灵活方便。
悠悠然然
悠悠然然

引用来自“songwie”的评论

测试端模式简单测试性能本来就比中间件模式高,来个join 10个亿客户端试下 客户端不挂了么?只做简单curd 测试没什么对比性,要的是大的join 聚合 及跨集群的大数据量测试才会体验出中间件的优势,而且客户端模式对代码侵入性高,也无法管理数据源连接 容易数据源连接爆掉

引用来自“悠悠然然”的评论

亲,你的理解可能有点偏。 1.数据库不挂,TinyDBRouter就不会挂 2.中间加一层注定影响更大 3.TinyDBRouter是在JDBC层做的,因此对代码没有任何侵入 4.数据源爆掉一说肯定你想歪了,这种模式会爆,代理方式一样会爆。 5.我们可能没有你想的那么聪明,但也没有你想的那么笨

引用来自“乌龟壳”的评论

中间件就像数据库连接池一样,维持一定数量的数据库连接同时,提供大量的透明额外连接给应用层。如果每个应用都直接连数据库,多了就不行了。你的业务场景是独立的应用个数没有超过数据库的承受能力,所以在应用层直接连接多个数据库是可行的。

引用来自“悠悠然然”的评论

其实你这里有个假的逻辑在这里,所以自己感觉抓到的根本,实际上不堪一击。 1.我的方案,如果分成N个库,如果建M个大小的连接池,实际上是每个库上都会产生M个连接,也就是在客户端这边会有N*M个连接,如果再有K台服务器,那么每个数据库服务器上就有K*M*N个连接。 2.你说的方案,那么在每个客户端上只有M个连接,你说得是这个意思吧?如果再有K台服务器,你的意思是也只在K*M个连接,是吧?表面上看看是这样的,好吧到此为止我支持你的观点。但是等等你这么多连接都连到了一台MyCat服务器上,这台服务与数据库之间的连接是多少呢?我告诉你不多不少正好K*M*N个连接。所以,追根到底,本质上没有什么区别,只是多了一层而已。但是这个时候你带来的网络交互及数据解包打包过程都会增加一倍,而且本来是想排除单点的,你这里又人为造出一个单点。CPU,网络IO的瓶颈又会产生。呵呵,我这么解释如果你还不明白或者根本不想明白的话,后面就不用聊了,大家都是搞技术的,都懂的。

引用来自“乌龟壳”的评论

1.中间件维护**固定数量**的到实际DB的连接,提供给应用超越实际DB连接数的支持。2.但是如果某一时刻没有实际DB连接空闲,这些超出的连接里的查询会排队等待。3.数据库连接池不都这样的么。4.这个中间件可以水平扩展消除单点,它只是个路由。5.这样可以提供给任何场景(语言、工具等)只要使用了mysql协议的数据库查询使用。6.网络通信开销确实是增加了一倍,但除了大量数据导入导出,网络开销在数据库场景下都不是压力点。

引用来自“悠悠然然”的评论

亲,如果只是网络转发一下,对性能的影响当然是不大的,但是你这里涉及到一个数据打包与解包的问题,打包和解包的性能压力就不能被忽略了。比如同样执行select * from xxx_table order by some_fields,这个时候服务器的计算量就可想而知了。中间件水平扩展,消除单点,第一会增加成本,第二当水平的数量多的时候,战胜的连接数也会增加。如果放大到和应用服务器数量一样的时候,其实就变成和我们方案一样了(只是还要多一层服务器)。当然,没有任何一种方案都是全是优点没有缺点的。

引用来自“乌龟壳”的评论

比如分库分表的策略,用中间件只用维护一个地方,但是每个应用的话就要每个应用独立去设置。其它就是中间件可以控制对实际数据库的并发数量,而每个应用维护就比较难。每个应用维护方便部署没有单点架构简单,如果数量不大对整体性能损耗小。所以其实看场景,没必要凭空争论哪个好。另外提一下中间件水平扩展一般都伴随着每个中间件维持的数据库连接数减少的配置策略。

引用来自“悠悠然然”的评论

亲,我们有配置中心的,配置信息都从中心拿。

引用来自“乌龟壳”的评论

回看了下这个帖子,发现一个问题,这个方案相比中间件方案来说,可以算是为mysql/sqlserver定制的,因为mysql本身可以支持大量连接,mysql会为这些连接排队,每个连接只是一个线程。但是基于每个连接一个进程的数据库(Oracle/PG)你这个方案在水平扩展到一定程度后就不太合适,需要加中间件了,因为对实际DB的连接数太多了。

引用来自“悠悠然然”的评论

亲,你仔细推演一下,就会发现两种方案区别不大。 当然,你可以举一个最极端的场景来说mycat方案是有优势的。 比如:每次只有一个分片参与处理,那么这个时候,是可以最大量的发挥效能的。 但是实际上我也可以在每个Client分配比较少的连接来达到同样的效果,只有参与分片处理的连接参与执行。

引用来自“乌龟壳”的评论

假设集群中某个时间有1000个应用要操作DB1,用中间件可以限制到DB1的实际连接只有100个,但用这种方案只能1000个。

引用来自“悠悠然然”的评论

嗯嗯,您举的例子是成立的。 但是实际应用过程中,您说的情况是不会出现的。 因为如果进行了分库或分表,业务肯定是高内聚的,就不会是例子中假设的情况情况了。

引用来自“乌龟壳”的评论

如果是同一个应用开了1000个的集群呢?
我来想一下,比如:阿里巴巴的一个小应用,有没有1000台的集群? 1000台,每台tps就算100好了,大致一秒的TPS是10万,一天按6小时计算,大概是2,160,000,000 也就是21亿的TPS。 那阿里的小应用,何止上千?假设有1000,然后每个都有这么大的流量。 就是一天有2万亿的TPS。地球人就按100亿计算好了,连老得不行的,带还不会动的,全部每天给我点200次,这是什么概念? 如果我有这些流量,我就直接把马云收购了,然后让马云帮我解决问题。
乌龟壳
乌龟壳

引用来自“songwie”的评论

测试端模式简单测试性能本来就比中间件模式高,来个join 10个亿客户端试下 客户端不挂了么?只做简单curd 测试没什么对比性,要的是大的join 聚合 及跨集群的大数据量测试才会体验出中间件的优势,而且客户端模式对代码侵入性高,也无法管理数据源连接 容易数据源连接爆掉

引用来自“悠悠然然”的评论

亲,你的理解可能有点偏。 1.数据库不挂,TinyDBRouter就不会挂 2.中间加一层注定影响更大 3.TinyDBRouter是在JDBC层做的,因此对代码没有任何侵入 4.数据源爆掉一说肯定你想歪了,这种模式会爆,代理方式一样会爆。 5.我们可能没有你想的那么聪明,但也没有你想的那么笨

引用来自“乌龟壳”的评论

中间件就像数据库连接池一样,维持一定数量的数据库连接同时,提供大量的透明额外连接给应用层。如果每个应用都直接连数据库,多了就不行了。你的业务场景是独立的应用个数没有超过数据库的承受能力,所以在应用层直接连接多个数据库是可行的。

引用来自“悠悠然然”的评论

其实你这里有个假的逻辑在这里,所以自己感觉抓到的根本,实际上不堪一击。 1.我的方案,如果分成N个库,如果建M个大小的连接池,实际上是每个库上都会产生M个连接,也就是在客户端这边会有N*M个连接,如果再有K台服务器,那么每个数据库服务器上就有K*M*N个连接。 2.你说的方案,那么在每个客户端上只有M个连接,你说得是这个意思吧?如果再有K台服务器,你的意思是也只在K*M个连接,是吧?表面上看看是这样的,好吧到此为止我支持你的观点。但是等等你这么多连接都连到了一台MyCat服务器上,这台服务与数据库之间的连接是多少呢?我告诉你不多不少正好K*M*N个连接。所以,追根到底,本质上没有什么区别,只是多了一层而已。但是这个时候你带来的网络交互及数据解包打包过程都会增加一倍,而且本来是想排除单点的,你这里又人为造出一个单点。CPU,网络IO的瓶颈又会产生。呵呵,我这么解释如果你还不明白或者根本不想明白的话,后面就不用聊了,大家都是搞技术的,都懂的。

引用来自“乌龟壳”的评论

1.中间件维护**固定数量**的到实际DB的连接,提供给应用超越实际DB连接数的支持。2.但是如果某一时刻没有实际DB连接空闲,这些超出的连接里的查询会排队等待。3.数据库连接池不都这样的么。4.这个中间件可以水平扩展消除单点,它只是个路由。5.这样可以提供给任何场景(语言、工具等)只要使用了mysql协议的数据库查询使用。6.网络通信开销确实是增加了一倍,但除了大量数据导入导出,网络开销在数据库场景下都不是压力点。

引用来自“悠悠然然”的评论

亲,如果只是网络转发一下,对性能的影响当然是不大的,但是你这里涉及到一个数据打包与解包的问题,打包和解包的性能压力就不能被忽略了。比如同样执行select * from xxx_table order by some_fields,这个时候服务器的计算量就可想而知了。中间件水平扩展,消除单点,第一会增加成本,第二当水平的数量多的时候,战胜的连接数也会增加。如果放大到和应用服务器数量一样的时候,其实就变成和我们方案一样了(只是还要多一层服务器)。当然,没有任何一种方案都是全是优点没有缺点的。

引用来自“乌龟壳”的评论

比如分库分表的策略,用中间件只用维护一个地方,但是每个应用的话就要每个应用独立去设置。其它就是中间件可以控制对实际数据库的并发数量,而每个应用维护就比较难。每个应用维护方便部署没有单点架构简单,如果数量不大对整体性能损耗小。所以其实看场景,没必要凭空争论哪个好。另外提一下中间件水平扩展一般都伴随着每个中间件维持的数据库连接数减少的配置策略。

引用来自“悠悠然然”的评论

亲,我们有配置中心的,配置信息都从中心拿。

引用来自“乌龟壳”的评论

回看了下这个帖子,发现一个问题,这个方案相比中间件方案来说,可以算是为mysql/sqlserver定制的,因为mysql本身可以支持大量连接,mysql会为这些连接排队,每个连接只是一个线程。但是基于每个连接一个进程的数据库(Oracle/PG)你这个方案在水平扩展到一定程度后就不太合适,需要加中间件了,因为对实际DB的连接数太多了。

引用来自“悠悠然然”的评论

亲,你仔细推演一下,就会发现两种方案区别不大。 当然,你可以举一个最极端的场景来说mycat方案是有优势的。 比如:每次只有一个分片参与处理,那么这个时候,是可以最大量的发挥效能的。 但是实际上我也可以在每个Client分配比较少的连接来达到同样的效果,只有参与分片处理的连接参与执行。

引用来自“乌龟壳”的评论

假设集群中某个时间有1000个应用要操作DB1,用中间件可以限制到DB1的实际连接只有100个,但用这种方案只能1000个。

引用来自“悠悠然然”的评论

嗯嗯,您举的例子是成立的。 但是实际应用过程中,您说的情况是不会出现的。 因为如果进行了分库或分表,业务肯定是高内聚的,就不会是例子中假设的情况情况了。
如果是同一个应用开了1000个的集群呢?
悠悠然然
悠悠然然

引用来自“songwie”的评论

测试端模式简单测试性能本来就比中间件模式高,来个join 10个亿客户端试下 客户端不挂了么?只做简单curd 测试没什么对比性,要的是大的join 聚合 及跨集群的大数据量测试才会体验出中间件的优势,而且客户端模式对代码侵入性高,也无法管理数据源连接 容易数据源连接爆掉

引用来自“悠悠然然”的评论

亲,你的理解可能有点偏。 1.数据库不挂,TinyDBRouter就不会挂 2.中间加一层注定影响更大 3.TinyDBRouter是在JDBC层做的,因此对代码没有任何侵入 4.数据源爆掉一说肯定你想歪了,这种模式会爆,代理方式一样会爆。 5.我们可能没有你想的那么聪明,但也没有你想的那么笨

引用来自“乌龟壳”的评论

中间件就像数据库连接池一样,维持一定数量的数据库连接同时,提供大量的透明额外连接给应用层。如果每个应用都直接连数据库,多了就不行了。你的业务场景是独立的应用个数没有超过数据库的承受能力,所以在应用层直接连接多个数据库是可行的。

引用来自“悠悠然然”的评论

其实你这里有个假的逻辑在这里,所以自己感觉抓到的根本,实际上不堪一击。 1.我的方案,如果分成N个库,如果建M个大小的连接池,实际上是每个库上都会产生M个连接,也就是在客户端这边会有N*M个连接,如果再有K台服务器,那么每个数据库服务器上就有K*M*N个连接。 2.你说的方案,那么在每个客户端上只有M个连接,你说得是这个意思吧?如果再有K台服务器,你的意思是也只在K*M个连接,是吧?表面上看看是这样的,好吧到此为止我支持你的观点。但是等等你这么多连接都连到了一台MyCat服务器上,这台服务与数据库之间的连接是多少呢?我告诉你不多不少正好K*M*N个连接。所以,追根到底,本质上没有什么区别,只是多了一层而已。但是这个时候你带来的网络交互及数据解包打包过程都会增加一倍,而且本来是想排除单点的,你这里又人为造出一个单点。CPU,网络IO的瓶颈又会产生。呵呵,我这么解释如果你还不明白或者根本不想明白的话,后面就不用聊了,大家都是搞技术的,都懂的。

引用来自“乌龟壳”的评论

1.中间件维护**固定数量**的到实际DB的连接,提供给应用超越实际DB连接数的支持。2.但是如果某一时刻没有实际DB连接空闲,这些超出的连接里的查询会排队等待。3.数据库连接池不都这样的么。4.这个中间件可以水平扩展消除单点,它只是个路由。5.这样可以提供给任何场景(语言、工具等)只要使用了mysql协议的数据库查询使用。6.网络通信开销确实是增加了一倍,但除了大量数据导入导出,网络开销在数据库场景下都不是压力点。

引用来自“悠悠然然”的评论

亲,如果只是网络转发一下,对性能的影响当然是不大的,但是你这里涉及到一个数据打包与解包的问题,打包和解包的性能压力就不能被忽略了。比如同样执行select * from xxx_table order by some_fields,这个时候服务器的计算量就可想而知了。中间件水平扩展,消除单点,第一会增加成本,第二当水平的数量多的时候,战胜的连接数也会增加。如果放大到和应用服务器数量一样的时候,其实就变成和我们方案一样了(只是还要多一层服务器)。当然,没有任何一种方案都是全是优点没有缺点的。

引用来自“乌龟壳”的评论

比如分库分表的策略,用中间件只用维护一个地方,但是每个应用的话就要每个应用独立去设置。其它就是中间件可以控制对实际数据库的并发数量,而每个应用维护就比较难。每个应用维护方便部署没有单点架构简单,如果数量不大对整体性能损耗小。所以其实看场景,没必要凭空争论哪个好。另外提一下中间件水平扩展一般都伴随着每个中间件维持的数据库连接数减少的配置策略。

引用来自“悠悠然然”的评论

亲,我们有配置中心的,配置信息都从中心拿。

引用来自“乌龟壳”的评论

回看了下这个帖子,发现一个问题,这个方案相比中间件方案来说,可以算是为mysql/sqlserver定制的,因为mysql本身可以支持大量连接,mysql会为这些连接排队,每个连接只是一个线程。但是基于每个连接一个进程的数据库(Oracle/PG)你这个方案在水平扩展到一定程度后就不太合适,需要加中间件了,因为对实际DB的连接数太多了。

引用来自“悠悠然然”的评论

亲,你仔细推演一下,就会发现两种方案区别不大。 当然,你可以举一个最极端的场景来说mycat方案是有优势的。 比如:每次只有一个分片参与处理,那么这个时候,是可以最大量的发挥效能的。 但是实际上我也可以在每个Client分配比较少的连接来达到同样的效果,只有参与分片处理的连接参与执行。

引用来自“乌龟壳”的评论

假设集群中某个时间有1000个应用要操作DB1,用中间件可以限制到DB1的实际连接只有100个,但用这种方案只能1000个。
嗯嗯,您举的例子是成立的。 但是实际应用过程中,您说的情况是不会出现的。 因为如果进行了分库或分表,业务肯定是高内聚的,就不会是例子中假设的情况情况了。
乌龟壳
乌龟壳

引用来自“songwie”的评论

测试端模式简单测试性能本来就比中间件模式高,来个join 10个亿客户端试下 客户端不挂了么?只做简单curd 测试没什么对比性,要的是大的join 聚合 及跨集群的大数据量测试才会体验出中间件的优势,而且客户端模式对代码侵入性高,也无法管理数据源连接 容易数据源连接爆掉

引用来自“悠悠然然”的评论

亲,你的理解可能有点偏。 1.数据库不挂,TinyDBRouter就不会挂 2.中间加一层注定影响更大 3.TinyDBRouter是在JDBC层做的,因此对代码没有任何侵入 4.数据源爆掉一说肯定你想歪了,这种模式会爆,代理方式一样会爆。 5.我们可能没有你想的那么聪明,但也没有你想的那么笨

引用来自“乌龟壳”的评论

中间件就像数据库连接池一样,维持一定数量的数据库连接同时,提供大量的透明额外连接给应用层。如果每个应用都直接连数据库,多了就不行了。你的业务场景是独立的应用个数没有超过数据库的承受能力,所以在应用层直接连接多个数据库是可行的。

引用来自“悠悠然然”的评论

其实你这里有个假的逻辑在这里,所以自己感觉抓到的根本,实际上不堪一击。 1.我的方案,如果分成N个库,如果建M个大小的连接池,实际上是每个库上都会产生M个连接,也就是在客户端这边会有N*M个连接,如果再有K台服务器,那么每个数据库服务器上就有K*M*N个连接。 2.你说的方案,那么在每个客户端上只有M个连接,你说得是这个意思吧?如果再有K台服务器,你的意思是也只在K*M个连接,是吧?表面上看看是这样的,好吧到此为止我支持你的观点。但是等等你这么多连接都连到了一台MyCat服务器上,这台服务与数据库之间的连接是多少呢?我告诉你不多不少正好K*M*N个连接。所以,追根到底,本质上没有什么区别,只是多了一层而已。但是这个时候你带来的网络交互及数据解包打包过程都会增加一倍,而且本来是想排除单点的,你这里又人为造出一个单点。CPU,网络IO的瓶颈又会产生。呵呵,我这么解释如果你还不明白或者根本不想明白的话,后面就不用聊了,大家都是搞技术的,都懂的。

引用来自“乌龟壳”的评论

1.中间件维护**固定数量**的到实际DB的连接,提供给应用超越实际DB连接数的支持。2.但是如果某一时刻没有实际DB连接空闲,这些超出的连接里的查询会排队等待。3.数据库连接池不都这样的么。4.这个中间件可以水平扩展消除单点,它只是个路由。5.这样可以提供给任何场景(语言、工具等)只要使用了mysql协议的数据库查询使用。6.网络通信开销确实是增加了一倍,但除了大量数据导入导出,网络开销在数据库场景下都不是压力点。

引用来自“悠悠然然”的评论

亲,如果只是网络转发一下,对性能的影响当然是不大的,但是你这里涉及到一个数据打包与解包的问题,打包和解包的性能压力就不能被忽略了。比如同样执行select * from xxx_table order by some_fields,这个时候服务器的计算量就可想而知了。中间件水平扩展,消除单点,第一会增加成本,第二当水平的数量多的时候,战胜的连接数也会增加。如果放大到和应用服务器数量一样的时候,其实就变成和我们方案一样了(只是还要多一层服务器)。当然,没有任何一种方案都是全是优点没有缺点的。

引用来自“乌龟壳”的评论

比如分库分表的策略,用中间件只用维护一个地方,但是每个应用的话就要每个应用独立去设置。其它就是中间件可以控制对实际数据库的并发数量,而每个应用维护就比较难。每个应用维护方便部署没有单点架构简单,如果数量不大对整体性能损耗小。所以其实看场景,没必要凭空争论哪个好。另外提一下中间件水平扩展一般都伴随着每个中间件维持的数据库连接数减少的配置策略。

引用来自“悠悠然然”的评论

亲,我们有配置中心的,配置信息都从中心拿。

引用来自“乌龟壳”的评论

回看了下这个帖子,发现一个问题,这个方案相比中间件方案来说,可以算是为mysql/sqlserver定制的,因为mysql本身可以支持大量连接,mysql会为这些连接排队,每个连接只是一个线程。但是基于每个连接一个进程的数据库(Oracle/PG)你这个方案在水平扩展到一定程度后就不太合适,需要加中间件了,因为对实际DB的连接数太多了。

引用来自“悠悠然然”的评论

亲,你仔细推演一下,就会发现两种方案区别不大。 当然,你可以举一个最极端的场景来说mycat方案是有优势的。 比如:每次只有一个分片参与处理,那么这个时候,是可以最大量的发挥效能的。 但是实际上我也可以在每个Client分配比较少的连接来达到同样的效果,只有参与分片处理的连接参与执行。
假设集群中某个时间有1000个应用要操作DB1,用中间件可以限制到DB1的实际连接只有100个,但用这种方案只能1000个。
数据库水平切分(MyCat分片Join)

Mycat(proxy中间件层) Sharding-jdbc(TDDL为代表的应用层) 分片Join 1.全局表 2.Share Join mysql> /!mycat:catlet=io.mycat.catlets.ShareJoin/select * from employee a, employee_detail ......

这很耳东先生
08/23
0
0
Mycat多租户/分布数据库/集群数据库以及SAAS研究进度报告

1、mycat操作 (1)垂直切分配置 (2)水平切分配置 (3)mycat修改schema.xml之后热重启 (4)mycat注解的实现 (5)mycat高可用(搭配HAproxy等一起做集群,多个mycat节点) 2、mycat可以配...

蓝奔z
08/24
0
0
使用mycat实现mysql读写分离

使用mycat实现mysql读写分离 mycat在数据层的作用和nginx在应用层很像,都是代理后面实际的服务。mycat实现了mysql协议,对外看起来就是一个mysql数据库,可以和使用普通mysql一样进行操作 ...

肥肥小浣熊
05/06
0
0
MySQL以及MyCat的使用

MySQL的安装(rpm格式/需要联网) 安装环境 VMware Linux CentOS-6.5。 上传工具FileZilla Client 第一步:查看mysql是否安装。 第二步:如果mysql的版本不是想要的版本。需要把mysql卸载。 ...

Cehae_Dong
07/01
0
0
Mycat读写分离笔记Windows

Mycat读写分离笔记Windows 自己搭了一个运用Mycat中间件搭建了一个读写分离的demo,昨晚还在奋战当中,因为连接mycat的时候老是报错:No Mycat DataBases selected.尝试了很多的方法,然后还...

推荐码发放
04/29
0
0

没有更多内容

加载失败,请刷新页面

加载更多

Bash重定向详解

Bash重定向详解 Bash的重定向指的是将命令的输入和输出导向不同地方,而不是默认的标准输入、标准输出和标准错误。Bash的重定向实际上是对标准输入、标准输出和标准错误的重置,进而将所需输...

小陶小陶
今天
3
0
EventBus原理深度解析

一、问题描述 在工作中,经常会遇见使用异步的方式来发送事件,或者触发另外一个动作:经常用到的框架是MQ(分布式方式通知)。如果是同一个jvm里面通知的话,就可以使用EventBus。由于Event...

yangjianzhou
今天
6
0
OpenCV图像处理实例:libuv+cvui显示摄像头视频

#include <iostream>#include <opencv2/opencv.hpp>#define CVUI_IMPLEMENTATION#include <cvui.h>extern "C"{#include <uv.h>}using namespace std;#define WINDOW_NAM......

IOTService
今天
3
0
openJDK之JDK9的String

1.openJDK8的String 先来看下openJDK8的String的底层,如下图1.1所示: 图1.1 底层上使用的是char[],即char数组 每个char占16个bit,Character.SIZE的值是16。 2.openJDK9中的String 图2.1...

克虏伯
今天
3
0
UEFI 模式下如何安装 Ubuntu 16.04

作者:知乎用户 链接:https://www.zhihu.com/question/52092661/answer/259583475 来源:知乎 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 针对UEFI模式下安装U...

寻知者
今天
3
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部