数据库扩容方案简单总结

[云计算] 季雨林 2018/9/29 10:39:56

        随着现代科技发展,越来越多的网站都在面临着“xx万并发”的问题。解决问题的第一步不在于配置多高,而在于“弹性云架构”。“分布式”、“负载均衡”、“动静分离”、“CDN加速”等等多种产品的配合结果。本文重点不再云架构,因此请需要的朋友自行搜索这些关键字,也或者等我后续先关博文的完善。

        

        从最早的超低访问量使用虚拟主机(空间)发布网站。

        到后来的访问量大了一点使用VPS虚拟机发布网站。

        遭到接下来使用物理服务器发布网站。

        再到现在使用云发布网站。

        

        庆幸我之前的工作经历中,一个项目从无到有的体会到一遍。也因此获得了今天发文说高并发业务数据库的资格。

        随着业务量增长,系统会遇到很多瓶颈,因此也会有很多地方需要扩容,扩容方式多种,前文说的都属于载体升级,未提到代码改造,也为提到部署结构改造,同样也没有将颗粒度细化到web资源,web文件,数据库等等细节技术领域。

        今天在论坛里回复了一个哥们的帖子《十万并发硬件要求,ECS,RDS,REDIS》,让我需要在进入正题之前,重新说道说道这个关于“XX万并发”问题。

        首先,并发一词太广义,现在人们的理解还有很大偏差,有这么几个问题都被大家理解为“并发”:

        1,网站每天总访问量(pv)10万

        2,网站每天总访问量(ip数)10万

        3,网站同时在线人数(online)10万

        4,网站每秒钟发帖量10万

        看懂了的请会心一笑(^_^) !  在我谈过的阿里云客户里,往往需要我重复解释这个“并发”一词。然后我的侧重点往往是去寻找客户业务的“峰值”压力。选购服务器时候,只看各种“峰值”,不需要考虑总量。然后,决定是不是能够达到访问量要求的,就回归到数据库io环节。否则得到的需求会特别超出实际用量

        

        数据库扩容,也是我一直以来的困惑,并发量上来之后必然有一个瓶颈点,目前能想到的有:iops,并发连接数,文件大小,网络带宽等等。看准确瓶颈点在哪,就足够交付。


瓶颈点不需要现在就去突破或者消除,但一定是短期时间内不能遇到的! 这里我举得例子就是早期不需要消除瓶颈点,而是瓶颈点一时半会到不了,足够为下一步升级留够时间。


对于真的需要扩容数据库的客户,请考虑以下几个方向:


方向一:分布式的数据库。

这种数据库重点解决的是io瓶颈。例如阿里云的 DRDS,由于时间成本和价格成本问题我一直没去实际测试DRDS,等后面时间宽裕了我会去试试 


方向二:软件架构改造,路由写入多个库。适合[写多读少] 的场景

直接在软件架构上设计扩容方案,这个方向在传统架构里经常看到,例如我那种 [写多读少] 可以程序哈希分库或者做个中间路由库调度写入不同数据库。这种方案是将瓶颈点尽量往远期推迟。直到将来的路由数据库压力饱满才需要再次改造 


方向三:一主多从架构。

这个方法得根据业务特征选取,例如CSDN博客这种 [读多写少] 的业务特征可以只是用一主多从解决。“新建博文”数量一时半会不会达到每秒几千(数据库每秒写入几千)




原文地址: https://www.opengps.cn/Blog/View.aspx?id=183 文章的更新编辑依此链接为准。欢迎关注源站原创文章!

鲁ICP备14008001号-2