绑定完请刷新页面
取消
刷新

分享好友

×
取消 复制
听说你们的数据库并发 2 万就跪了?
2022-11-09 19:24:05


如果各位看官的 SQL 数据库真有 2W+ 高并发,那真是要恭喜你。你已经比很多公司的 MIS 都要前卫得多。2W 和 2K 差别有那么大吗,嗯,真是有的。2K 并发的 MIS 系统也经常有无法访问,timeout 的异常,处理这些异常已经够很多朋友苦恼的了。2W+ 的并发那需要懂的知识框架就更复杂了。


笔者曾服务了 500W+ 用户的电商系统,7*24 小时的噩梦再也不想见


前几年在一家拥有 500 多万直销顾问的团队做电商平台。平时的流量很平稳,基本都在千把,月底拼业绩才会冲一冲,来个 1W+ 的并发。大部分的数据库开发人员在日常中还是没心没肺没压力的。但电商系统有个惯例,都是淘宝带出来的,会搞促销,类似于双 11. 一到这时间段,必须随时警惕流量是不是井喷,一旦跨越红线,系统就跟前期的 12306 一样,频频延迟。随着 DBA 组的介入,才慢慢搞定这难题。本文的初衷也来自于这段经历的总结。



单实例数据库应用


这种应用架构简单,UI + 应用服务器 + 数据库服务器,所有的请求,无论读写都直接抛给数据库。往往项目初期,为了迅速的证明自己的点子靠谱,拿到市场,我们会选择这样的架构来实现产品。此时往往 10 万用户注册了,但每天访问的人数刚过 200, 每张数据库表的总数,大也不会超过 5000 条。这样的应用,开发能力强的,1 个人就可以搞定,业务复杂的需要分前端和后端。但无论如何都属于基础项目,如果你工作 3,4 了还是停留在这种模式下,那该补补课了。


事物总是在发展之中的,只要系统正常运行,总有一天用户量会加大,随之而来的请求会超乎你的想象(前提你是做了 pv, uv 的数据分析),很快这种架构会遇到用户超过 100 万,日访问量超过 20 万,峰值并发 2 万,而数据库的表会趋近于亿级的量。此时应用系统如果还是建立在当初的硬件基础上(比如 16GB,16 核,240GB 硬盘)应该会明显感觉得到拖卡慢的尴尬,增多的是用户的抱怨和投诉。就像 12306 前期的购票一样,往往轮到你的时候,票没了。




多实例数据库


遇到流量起来的应用,如果压力确定是在数据库上了,那么分库是必然的事情了。将一个大库拆成若干小库,保持数据库对象都一致,这样每个小库分摊掉一部分流量,应用终将回归种简单架构上来,将用户服务好。以现在的硬件服务 4000 个并发,对于不复杂的商用没有问题。具体能负责多少看系统上线后的 baseline (基线)监测,这里我们假定 4000 并发。所以分成 5 个相同的库,来做分库。这样同时写入 4000 并发够用。



这里会遇到一个技术细节,就是分库路由。如何将流量均摊到每个库里,是需要研制算法的。比如已知用户分布均衡,即华东、华北、华西、华南和华中,各有 4000 用户。我们依据地理位置分成 5 个库,根据用户身份证哈希成 5 个散列值,分别对应了这 5 台数据库,用户就被分流了。

只要用户不是剧烈增长,老板也满意这种小而美的生意,这样的架构可以一直沿用下去。基本不会有瓶颈。顶多就是时间长了,表数据越来越大了,我们用分库的思想进行分表就可以了。当前年份(月份)数据放在主表里面,而历史数据就归档到聚合表里;或者索性每月,每年分成子表存储,而跨时间段的查询用视图来控制。



但用户的行为始终是不可控的,我么必须做一系列的事情来满足和留住用户。比如促销、打折、团购等等。这个时候,用户的行为不仅仅是下个单买杯咖啡这么简单了。他们会大量查询他们的数据,带来的是读请求远远大于写入请求。众所周知,读请求即使不影响写入请求(比如 MVVC),但也会耗尽服务器的 CPU\IO\Network 资源。那么我们必须更进入一层,读写分离


读写分离


读写分离是另一种分库,但与前面的分库意图不一样。分出来的库和源库一模一样,且只读不接收用户的写入请求。实现细节每个数据库都不一样,也可以使用实时同步工具做,详情可以参考《Designing Data-Intensive Applications》这本书。不仅仅给出了指导思想,更有每种数据库的读写分离组件指南。



分享好友

分享这个小栈给你的朋友们,一起进步吧。

大数据新手初入门
创建时间:2022-03-21 20:33:42
分享初学者学习大数据的过程,接触到的各个知识点和小项目。
展开
订阅须知

• 所有用户可根据关注领域订阅专区或所有专区

• 付费订阅:虚拟交易,一经交易不退款;若特殊情况,可3日内客服咨询

• 专区发布评论属默认订阅所评论专区(除付费小栈外)

栈主、嘉宾

查看更多
  • carr_fu
    栈主

小栈成员

查看更多
  • LCR_
戳我,来吐槽~