Sine安全-网络安全背后的巨人,提供服务器安全_服务器维护_网站安全解决方案

APP数据库并发的处理解决方案有哪些?

很多网站或APP平台随着用户量的增加,对于数据库并发压力的问题就越来越多,2W并发和2K并发的区别那么大吗?嗯,真的有。2K并发的办公系统也常常是不可访问的,timeout异常,处理这些异常已经让很多朋友感到困扰。2W+的并发需要理解的知识框架更加复杂。


作者曾经服务过800W+用户的电子商务系统,7*24小时再也不想看到恶梦。几年前,我在一个拥有500多万直销顾问的团队建立了一个电子商务平台。平时的流量很稳定,几乎有一千人,月底业绩突破,1W+的并发。大部分数据库开发人员在日常生活中没有肺和压力。但是,电气商务系统有淘宝带来的惯例,促销就像双11.到了这个时间段,必须随时警惕流量是否井喷,越过红线,系统就像前期的12306一样频繁延迟。随着DBA组的介入,逐渐解决了这个问题。本文的初衷也来自于这段经历的总结。


单个实例数据库的应用。

这种应用架构最简单,UI+应用服务器+数据库服务器,所有的请求,读写都直接投入数据库。在项目初期,为了迅速证明自己的想法,获得市场,我们会选择这样的结构来实现产品。此时,通常有10万用户注册,但每天访问的人数刚刚超过200人,每张数据库表的总数最多不超过5000人。这样的应用,如果开发能力强,一个人就能搞定,业务复杂需要分前端和后端。但是,无论如何都是基础项目,如果你工作了3、4次还是停留在这个模式下,就应该补课。事物总是在发展中,只要系统正常运行,总有一天用户数量就会增加,随之而来的请求超出想象(以pv、uv的数据分析为前提),这个结构很快就会遇到用户超过100万人,日访问量超过20万人,峰值合并2万人,数据库的表现接近亿级此时,应用系统应该在当初的硬件基础上(例如16GB、16核、240GB硬盘)明显感到卡慢的尴尬,增加的是用户的投诉和投诉。就像12306前期的买票,往往轮到你的时候,票就没了。


多个实例数据库。

遇到流量上升的应用,如果压力确定在数据库上,分库是必然的。将一个大库分成几个小库,使数据库的对象一致,使各个小库分配一部分流量,应用最终回到最初的简单结构,为用户提供服务。以现在的硬件服务4000个并发,对于不复杂的商业没有问题。具体来说,可以看到系统在线的baseline(基线)的监视,在这里假定4000并发。因此,分为5个相同的库,制作库。这样写4000并发就足够了。

在这里,技术细节是分库路由。如何将流量平均分配给各库,需要开发算法。例如,已知全国用户分布均衡,即华东、华北、华西、华南和华中,各有4000用户。我们根据地理位置分为五个库,根据用户身份证哈希成为五个散列值,分别对应这五个数据库,用户被分流。


只要用户没有激增,上司也满足这样小而美丽的生意,这样的结构可以一直使用。几乎没有瓶颈。最多的时间变长了,表的数据变大了,我们用分库的思想分钟就可以了。当前年(月)的数据放在主表中,历史数据存档在聚合表中,或者每月分为子表存储,跨时间段的查询用视图控制。

但是,用户的行为总是无法控制的,我必须做一系列的事情来满足和维持用户。例如促销、折扣、团购等。此时,用户的行为不仅仅是下一个单独买咖啡。他们大量查询他们的数据,带来的阅读要求远远大于写入要求。众所周知,即使读取请求不影响写入请求(例如MVVC),也会消耗服务器的CPU\IO\Network资源。那么,我们必须进一层,读写分离。


读写分离。读写分离是另一个分库,但与以前的分库意图不同。分开的仓库和源仓库一模一样,只读不接受用户的写求。实现细节的每个数据库都不同,也可以使用实时同步工具。


分享: