大话 | 大话程序猿眼里最全的高并发,快收藏!
source link: https://www.iming.info/2020/10/31/大话-大话程序猿眼里最全的高并发,快收藏!/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Hi ! 我是小小,今天是本周的第六篇,本月的最后一篇,你还好吗?我是小小,我们本周的内容是大话高并发架构
前言
高并发经常会发生在有大量用户量,用户高聚集的业务场景,例如秒杀活动,定时领取红包。
为了让业务可以在高并发的时候能够相当好的运行,并给用户一个良好的交互体验,所以,考虑各种高并发的场景,设计高并发架构。
服务器架构
业务从初期到成熟,从单一到集群,最后到分布式,需要有服务器的负载均衡,数据的主从复制,nosql的各种集群,静态文件上传cdn等等。
需要用到的服务器架构如下
服务器
负载均衡,如阿里云的slb 或者是nginx
资源监控
分布式
数据库
主从分离,集群
DBA表优化,索引优化
分布式
nosql
redis:主从分离,集群
mongodb: 主从分离,集群
memcache:主从分离,集群
cdn
html
css
js
image
并发测试
对于高并发业务,需要进行高并发的业务测试,通过大量的数据分析评估整个架构支撑的并发量。
测试并发使用的工具如下
阿里云性能测试
jmetter
visual studio 性能负载测试
Microsoft Web Application Stress Tool
实现方案
通用方案
日用户流量大,但是比较分散,偶尔会有用户聚合的情况
场景
用户签到,用户中心,用户订单
服务器架构
说明
这些场景,基本都是用户进入app后会操作,这些用户不会高聚集,同时这些表又是大的数据表,业务很多,所以需要减少DB的查询,优先查询缓存,如果缓存不存在,再命中DB。
所以需要使用缓存,为了降低缓存,所以使用分布式的缓存,对DB实现hash分组,把用户分布到不同的缓存中,不会影响查询效率。
方案
用户签到
- 计算用户分布的key,redis hash中查找用户今日签到的消息
- 能查询到,返回查询的信息
- 如果没有查询到,DB查询今日是否抢到过,如果抢到过,信息同步redis
- 如果db也没有查询到,进行签到逻辑,db添加今日签到记录。这是一个事物
- 缓存签到信息到redis,返回签到信息
用户订单
- 这里只缓存第一页订单信息
- 用户访问订单列表,如果是第一页读缓存,如果不是读DB
- 计算出用户分布的key,redis hash中查找用户订单信息
- 如果能查询到用户订单信息,返回订单信息
- 如果不存在用户信息,就直接db查询第一页 订单数据,然后缓存redis,返回订单信息
用户中心
- 计算用户key,redis hash 中查找出用户订单信息
- 能查找到,返回用户信息
- 如果未找到,缓存redis,返回用户信息
以上的仅仅是一个相对于比较简单的并发架构
消息队列
用于缓存秒杀,活动,用户在一瞬间涌入产生的高并发的请求
场景:
定时领取红包。
架构
说明
场景中的定时领取是一个高并发的业务,秒杀活动会在一瞬间涌入。
这种业务会直接命中DB,会导致数据的崩溃。
设计这种业务的时候,需要使用消息队列,可以把参与的用户信息添加到消息队列中,然后缓慢的消耗。
方案
-
定时领取红包:
使用redis的list
当用户参与活动,用户信息push到队列中
书写多个线程去pop数据,进行发放红包的业务。
一级缓存
一级缓存就是使用站点服务器去缓存数据,只缓存部分请求量大的数据,并且数据量还需要控制,一级缓存需要设置秒为单位的过期时间,具体业务场景看业务场景而定,目的是有高并发的时候可以让数据获取命中到一级缓存,减少nosql的压力。
架构图
场景
APP首屏的数据接口
静态化数据
对于更新不频繁,并且数据允许短时间内的延迟,可以通过数据静态化成json,xml,html等数据文件上传cdn,然后拉取数据的时候优先拉取cdn,然后再缓存,最后数据库,用于减轻db的压力。
分层,分割,分布式
大型网站需要很好的支撑高并发,这需要很长的规划设计,主要需要如下
1. 分层:
系统在横向维度切分成几个部分,每个部门负责一部分相对简单并且单一的职责,然后通过上层,对下层的完整依赖形成一个完整的系统。
例如把一个电商分为,应用层,服务层,数据层。
应用层:网站首页,用户中心
服务层:订单服务,用户管理服务
数据层:关系型数据库,nosql数据库。
2. 分割
在纵向对业务进行切分
例如,用户中心可以分割成为账户信息模块,订单模块,充值模块,提现模块,优惠券模块
3. 分布式
分布式应用和服务,把应用进行分布式部署。
当业务达到一定用户量的时候,需要对服务器进行负载均衡,数据库,缓存主从集群
分布式静态资源,静态资源上传cdn
分布式计算,使用hadoop进行大数据分布式计算
集群
对于用户访问集中的服务器,搭建集群,通过负载均衡共同对外提供服务,当有更多的用户访问的时候,只需要加机器即可。
ngixn反向代理
slb
数据库的主从分离
异步
在高并发业务场景中,如果涉及到数据库操作,主要压力是在数据库服务器上,当连接数量达到最大值的时候,有其他连接数据库的请求操作的时候,就需要有空闲的连接。
场景
自动弹窗签到
双十一抢红包
双十一订单入库
设计
使用消息队列,把入库的内容放入到消息队列中,业务接口直接返回提示,高峰期延迟到账。
然后再写独立程序从消息队列中,读取进行入库操作,入库成功以后刷新缓存,如果入库失败,记录日志,方便查询反馈和重新持久化。
补充
其他场景,例如短信发送
面向服务
soa 面向服务架构设计
微服务更加细腻度的服务化。
例子
用户行为跟踪记录统计
说明
通过上报应用模块,操作事件,事件对象,等数据,记录用户操作行为。
例如用户在某个商品模块点击了某一件商品,或者看了某一件商品。
架构
node.js web 应用负载均衡
redis主从集群
mysql主从复制
nodejs + express + ejs + redis + mysql
冗余自动化
当高并发业务出现单击的时候,需要快速的有备用的替代,所以需要自动化执行这些操作
冗余
数据库备份
备份服务器
自动化
自动化监控
自动化报警
自动化降级
关于作者
我是小小,一枚生于二线,活在一线城市的程序猿,我是小小,我们下期再见。
Recommend
-
52
在张一鸣的眼里,人性或许就是由算法而渐次深入的丑恶,利益就是衡量价值的标准。而技术战胜一切。好的内容是激发人性中的善,而不是挖掘人性之恶。2017年12月29日,眼看就要辞旧迎新了,国家互联网信息办公室的一纸约谈让今日头条“干干净净”...
-
67
无论你在自己的行业里做得多么风生水起,忙得多么焦头烂额,在你的家人眼里,你就是个玩手机的。
-
81
前言 高并发经常会发生在有大活跃用户量,用户高聚集的业务场景中,如:秒杀活动,定时领取红包等。 为了让业务可以流畅的运行并且给用户一个好的交互体验,我们需要根据业务场景预估达到的并发量等因素,来设计适合自己业务场景的高并发处理方案。 在电商相关产品...
-
91
程序员需要对问题进行透彻的分析,理清其涉及的所有细节,预测可能发生的所有意外与非意外的情况,列出解决方案的所有步骤,以及对解决方案进行尽量全面的测试。
-
40
希望更多的人可以参与到区块链发展的大潮中来,毕竟时代的每一次红利都是给普通人跃升的机会,毕竟不是每个人都能在年富力强的时期迎来技术革新的窗口期。
-
31
-
8
大话 程序猿 眼里的 高并发 – Android开发中文站简单理解下高并发: 高并发是指在同一个时间点,有很多用户同时的访问URL地址,比如:淘宝的双11,双12,就会产生高并发,如贴吧的爆吧,就是恶意的高并发请求,也就是DDOS攻...
-
6
摘要:Fork/Join框架位于J.U.C(java.util.concurrent)中,是Java7中提供的用于执行并行任务的框架,其可以将大任务分割成若干个小任务,最终汇总每个小任务的结果后得到最终结果。本文分享自华为云社区《
-
2
一个好的互联网公司都离不开好的产品经理,对产品有着充分理解、有强大的分析判断和执行的能力、有良好的沟通和表达能力,对未来自市场、用户等各方面的需求进行收...
-
7
真的有这么多大数据高并发分布式的程序要搞吗? ...
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK