文档章节

MyCat与TinyDBRouter性能PK

悠悠然然
 悠悠然然
发布于 2015/12/07 12:58
字数 1787
阅读 8487
收藏 116
点赞 11
评论 99

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

今天我就简单的拿一些性能测试数据进行简单的展示,看看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表现重建的方式后保证了数据的可验证性,同样的数据量与测试方式,数据非常接近。

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

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

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


© 著作权归作者所有

共有 人打赏支持
悠悠然然

悠悠然然

粉丝 2373
博文 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读写分离笔记Windows

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

推荐码发放
04/29
0
0
mycat实现mysql分库分表

1. mycat介绍 MyCat发展到目前的版本,已经不是一个单纯的MySQL代理了,它的后端可以支持MySQL、SQL Server、Oracle、DB2、PostgreSQL等主流数据库,也支持MongoDB这种新型NoSQL方式的存储,...

红隐
05/06
0
0
使用mycat实现mysql读写分离

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

肥肥小浣熊
05/06
0
0
高性能Mysql中间组件Mycat安装配置

高性能Mysql中间组件Mycat安装配置 由于公司项目需要使用到读写分离,但是官方版本的Mysql-proxy读写分离组件太不稳定且有很多BUG,最终决定使用Mycat作为中间组件,其实读写分离只是Mycat中...

幸运券发放
05/02
0
0
Mycat学习实战-Mycat的zookeeper集群模式

Mycat学习实战-Mycat的zookeeper集群模式 Mycat学习实战-Mycat的zookeeper集群模式 1. ZooKeeper简介 2. ZooKeeper角色和端口 3. ZooKeeper部署简介 4. ZooKeeper部署管理Mycat 1. ZooKeepe...

ygqygq2
06/29
0
0
「mysql优化专题」高可用性、负载均衡的mysql集群解决方案(12)

不可避免的是,使用MySQL时随着时间的增长,用户量以及数据量的逐渐增加,访问量更是剧增,最终将会使MySQL达到某个瓶颈,那么MySQL的性能将会大大降低。怎么办?前面已经讲过十一篇优化方案...

java进阶架构师
01/03
0
0
最新高可用性、负载均衡的mysql集群解决方案(12)

     前文是「mysql优化专题」主从复制面试宝典!面试官都没你懂得多!(11),没看过的可以先看下。不可避免的是,使用MySQL时随着时间的增长,用户量以及数据量的逐渐增加,访问量更是剧增...

java进阶架构师
2017/11/10
0
0
MyCAT全局序列号-数据库方式

1.MyCat中的全局序列号介绍 在实现分库分表的情况下,数据库自增主键已无法保证自增主键的全局唯一。为此,MyCat 提供了全局 sequence,并且提供了包含本地配置和数据库配置等多种实现方式。...

HilaryHe
今天
0
0
Mycat连接数据库之后导致表名全小写的问题分析研究

初步研究:通过部署发现在Mycat中部署逻辑表表名大小写混合时,在Mycat连接后出现全变小。容易造成错误逻辑表(按混合表名创建物理表); 可能拯救的方法: 1、Linux下部署安装MySQL,默认不...

easonjim
2017/08/25
0
0
使用MyCAT实现MySQL的分库分表、读写分离、主从切换

MyCAT及MySQL实例部署情况: MyCAT: IP:10.20.8.57,Port:3310/3311 MySQL : db1-M1,IP:10.20.8.126,Port:3306 db1-M2,IP:10.20.8.126,Port:3307 db2-M1,IP:10.25.80.7,Port:......

橡皮高
05/08
0
0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

Spring基础

Spring是什么? Spring是一个开源框架,最早由Rod Johnson创建,它解决的是业务逻辑层和其他各层的松耦合问题。 经过十几年的发展,Spring正在扩展其他的领域,如:移动开发、社交API集成、N...

这很耳东先生
7分钟前
0
0
面试系列-40个Java多线程问题总结

前言 这篇文章主要是对多线程的问题进行总结的,因此罗列了40个多线程的问题。 这些多线程的问题,有些来源于各大网站、有些来源于自己的思考。可能有些问题网上有、可能有些问题对应的答案也...

Ryan-瑞恩
20分钟前
0
0
微信分享的细节

分享的缩略图要求: 一、图片大小小于32k 二、图片的尺寸为 宽度 :128px 高度:128px 分享title 和 description 出现金额等 以上情况存在会导致触发分享按钮 但是页面没有反应...

Js_Mei
26分钟前
0
0
【2018.07.23学习笔记】【linux高级知识 Shell脚本编程练习】

1、编写shell脚本,计算1-100的和; #!/bin/bashsum=0for i in `seq 1 100`do sum=$[$sum+$i]doneecho $sum 2、编写shell脚本,要求输入一个数字,然后计算出从1到输入数字的和,要求...

lgsxp
29分钟前
0
0
xss攻防浅谈

导读 XSS (Cross-Site Script) 攻击又叫跨站脚本攻击, 本质是一种注入攻击. 其原理, 简单的说就是利用各种手段把恶意代码添加到网页中, 并让受害者执行这段脚本. XSS能做用户使用浏览器能做的...

吴伟祥
29分钟前
0
0
js回调的一次应用

function hideBtn(option) { if (option == 1) { $("#addBtn").hide(); $("#addSonBtn").hide(); }}$("body").on("click", "#selectBtn", function () {......

晨猫
35分钟前
0
0
C++_读写ini配置文件

1.WritePrivateProfileString:写配置文件 WritePrivateProfileString 函数的定义形式为: BOOL WritePrivateProfileString(LPCTSTR lpAppName, LPCTSTR lpKeyName, LPCTSTR lpString, LPCTST......

一个小妞
35分钟前
0
0
通往阿里,BAT的50+经典Java面试题及答案解析(上)

Java是一个支持并发、基于类和面向对象的计算机编程语言。下面列出了面向对象软件开发的优点: 代码开发模块化,更易维护和修改。 代码复用。 增强代码的可靠性和灵活性。 增加代码的可理解性...

Java大蜗牛
35分钟前
1
0
数据库两大神器【索引和锁】

前言 只有光头才能变强 索引和锁在数据库中可以说是非常重要的知识点了,在面试中也会经常会被问到的。 本文力求简单讲清每个知识点,希望大家看完能有所收获 声明:如果没有说明具体的数据库...

Java3y
39分钟前
0
0
Application Express安装

Application Express安装文档 数据库选择和安装 数据库选择 Oracle建议直接12.2.0.1.0及以上的版本,12.1存在20618595bug(具体可参见官方文档) Oracle 12c 中安装oracle application expr...

youfen
51分钟前
0
0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

返回顶部
顶部