网站高并发及高并发架构详解

  • 时间:
  • 浏览:1
  • 来源:UU直播快三官方_大发UU直播快3

以下我所知道的:

这完后 就冒出了一级缓存的方案,一级缓存所以 使用站点服务器缓存去存储数据,注意只存储累积请求量大的数据,而且缓存的数据量要控制,非要过分的使用站点服务器的内存而影响了站点应用系统守护进程的正常运行,一级缓存也能 设置秒单位的过期时间,具体时间根据业务场景设定,目的是当有高并发请求的完后 还都能能 让数据的获取命中到一级缓存,而无需连接缓存nosql数据服务器,减少nosql数据服务器的压力

这接口是给前端ajax使用,访问量会很大,一页面展示的完后 就会有几十件商品的展示,滚动条滚到到页面显示商品的完后 就会请求接口进行展示数据的统计,每次翻页又会加载几十件

比如APP首屏商品数据接口,哪些地方地方数据是公共的无需针对用户自定义,而且哪些地方地方数据无需频繁的更新,像你这些接口的请求量比较大就还都能能 加入一级缓存;

在高并发的情况汇报下,会原困用户参与抽奖的完后 积分被扣除,而奖品实际上而且被抽完了

第三方服务:

说明:

测试高并发还都能能 使用第三方服务器而且买车人测试服务器,利用测试工具进行并发请求测试,分析测试数据得到还都能能 支撑并发数量的评估,你这些还都能能 作为另五个 预警参考,俗话说知己自彼百战不殆。

这里主要讲述的是在并发请求下的数据逻辑正确处理的接口,咋样保证数据的一致性和全部性,这里的并发而且是几瓶用户发起的,也而且攻击者通过并发工具发起的并发请求

尼玛,那么卡,老子来参加活动的,刷新了还是另五个 ,垃圾网站,再所以 来了。

如例子2(事务+通过更新锁 正确处理并发原困数据错乱 而且事物+Update的锁表机制)

在做公司产品网站的过程中,经常会另五个 的需求,比如哪些地方搞个活动专题,抽奖,签到,搞个积分竞拍等等,而且那么考虑到高并发下的数据正确处理,那就Game Over了,很容易原困抽奖被多抽走,签到会发现另五个 用户有多条记录,签到一次获得了获得了多积分,等等,各种超出正常逻辑的难题,这所以 做产品网站也能 考虑的难题,而且哪些地方地方都有面向几瓶用户的,而都有像做ERP管理系统,OA系统那样,所以 面向员工。

另五个 还都能能 支持高并发的服务少不了好的服务器架构,也能 有均衡负载,数据库也能 主从集群,nosql缓存也能 主从集群,静态文件也能 上传cdn,哪些地方地方都有能让业务系统守护进程流畅运行的强大后盾。

日用户流量大,而且比较分散,偶尔会有用户高聚的情况汇报;

更新用户相关缓存也能 分布式存储,比如使用用户ID进行hash分组,把用户分布到不同的缓存中,另五个 另五个 缓存集合的总量无需很大,无需影响查询波特率。

而且也能 有个方案当高并发完后 完后 还都能能 减少命中缓存服务器;

高并发是发生同另五个 时间点,有所以用户同时的访问URL地址,比如:淘宝的双11,双12,就会产生高并发,如贴吧的爆吧,所以 恶意的高并发请求,也所以 DDOS攻击,再屌丝点的说法就像玩撸啊撸被ADC暴击了一样,那伤害你懂得(而且你看懂了,你这些说法说明是正在奔向人生巅峰的屌丝。

如例子:通过表设计正确处理并发原困数据错乱

设计这块业务的完后 就会使用消息队列的,还都能能 将参与用户的信息加进到消息队列中,而且再写个多系统守护进程系统守护进程去消耗队列,给队列中的用户发放红包;

通过消息队列还都能能 做所以的服务。

合理的规范和使用nosql缓存数据库,根据业务拆分缓存数据库的集群,另五个 基本还都能能 很好支持业务,一级缓存毕竟是使用站点服务器缓存所以还是要善用。

高并发请求数据不变化的情况汇报下而且还都能能 不请求买车人的服务器获取数据那就还都能能 减少服务器的资源压力。

像你这些都有非要查询的操作而且会有高并发的插入而且更新数据的业务,前面提到的通用方案就无法支撑,并发的完后 都有直接命中DB;

并发测试工具:

场景中的定时领取是另五个 高并发的业务,像秒杀活动用户会在到点的时间涌入,DB瞬间就接受到一记暴击,hold不住就会宕机,而且影响整个业务;

秒杀、秒抢等活动业务,用户在瞬间涌入产生高并发请求

场景:定时领取红包,等

服务器架构图:

这里有个逻辑用户触发缓存的更新,用户刷新页面,当缓存发生的完后 ,会取到最后一次缓存更新时间,而且当前时间大于十点,而且最后缓存时间是10点前,则会从数据库中重新获取数据保存到cache中。 还有客户端页面会在10点完后 用js发起页面的刷新,所以 而且另五个 的逻辑,原困10点的完后 有所以并发请求同时过来,而且就会原困所以的sql查询操作,理想的逻辑是,只另五个 请求会去数据库获取,而且 都有从缓存中获取数据。(而且你这些sql查询很耗服务器性能,所以原困在10点的完后 ,经常间数据库服务器压力暴增)

用户表,包含积分字段

高并发意淫分析(属于开发前的猜测):

在高并发的情况汇报下,会原困,另五个 用户签到记录会有多条,而且用户签到后不止加一积分。

业务从发展的初期到逐渐心智心智心智心智成熟 期图片 图片 是什么期期图片 期,服务器架构也是从相对单一到集群,再到分布式服务。

场景: 用户签到,用户中心,用户订单,等

服务器架构图:

方案如:

首先根据需求我会加进一张签到记录表,重点来了,这张表也能 把用户唯一标识字段(ID,Token)和签到日期字段加进为唯一约束,而且唯一索引,另五个 就还都能能 正确处理并发的完后 插入重复用户的签到记录。而且再系统守护进程代码逻辑里,先执行签到数据的加进(这里还都能能 正确处理并发,加进成功后再进行积分的加进,另五个 就还都能能 正确处理重复的加进积分了。最后我还是建议所有的数据操作都写在另五个 sql事务上边, 另五个 在加进失败,而且编辑用户积分失败的完后 还都能能 回滚数据。

以上例子是另五个 相对简单的高并发架构,并发量都有很高的情况汇报还都能能 很好的支撑,而且随着业务的壮大,用户并发量增加,朋友的架构也会进行不断的优化和演变,比如对业务进行服务化,每个服务有买车人的并发架构,买车人的均衡服务器,分布式数据库,nosql主从集群,如:用户服务、订单服务;

服务器架构图:

高并发相关的业务,也能 进行并发的测试,通过几瓶的数据分析评估出整个架构还都能能 支撑的并发量。

附加:

通过服务端锁系统守护进程正确处理包并发下的数据错乱难题

高并发请求连接缓存服务器超出服务器也能接收的请求连接量,累积用户冒出建立连接超时无法读取到数据的难题;

对于更新频繁度不高,而且数据允许短时间内的延迟,还都能能 通过数据静态化成JSON,XML,HTML等数据文件上传CDN,在拉取数据的完后 优先到CDN拉取,而且那么获取到数据再从缓存,数据库中获取,当管理人员操作后台编辑数据再重新生成静态文件上传同步到CDN,另五个 在高并发的完后 还都能能 使数据的获取命中在CDN服务器上。

在事物里,通过WITH (UPDLOCK) 锁住商品表,而且Update 表的奖品剩余数量和最后编辑时间字段,来把数据行锁住,而且进行用户积分的消耗,都完成后提交事物,失败就回滚。 另五个 就还都能能 保证,非要而且发生另五个 操作在操作这件商品的数量,非要等到你这些操作事物提交后,而且 的操作你这些商品行的事物才会继续执行。

C#通过 (锁)lock,在从数据读取到缓存的那段代码前面加进锁,另五个 在并发的情况汇报下只会另五个 请求是从数据库里获取数据,而且 都有从缓存中获取。

原困站点服务器/DB服务器资源被占满崩溃,数据的存储和更新结果和理想的设计是不一样的,比如:冒出重复的数据记录,多次加进了用户积分等。

服务器这块多是也能 运维人员来配合搭建,具体让他不要 说了,点到为止。

大致也能 用到的服务器架构如下:

【缓存数据到cache里】, 当缓存不发生的完后 ,从数据库中获取并保发生cache里,而且发生从cache里获取,每天10点也能 更新一次,而且 时间点缓存另五个 小时更新一次 到10点的完后 ,凡是打开页面的用户会自动刷新页面

如:定时短信发送服务,使用sset(sorted set),发送时间戳作为排序方法,短信数据队列根据时间升序,而且写个系统守护进程定时循环去读取sset队列中的第两根,当前时间算是超过发送时间,而且超过就进行短信发送。

说明:

【签到功能】 一天另五个 用户非要签到一次,

签到成功后用户获取到另五个 积分

如例子3(通过系统守护进程代码正确处理包并发下的数据错乱难题)

【抽奖功能】 抽奖一次消耗另五个 积分 抽奖中奖后编辑剩余奖品总数 剩余奖品总数为0,而且用户积分为0的完后 无法进行抽奖

用户表,包含积分字段 奖品表,包含奖品剩余数量字段

朋友通过nodejs写了另五个 数据正确处理接口,把统计数据先存到redis的list里。(使用nodejs写接口的好处是,nodejs使用单系统守护进程异步事件机制,高并发正确处理能力强,无需而且数据逻辑正确处理难题原困服务器资源被占用而原困服务器宕机) 而且再使用nodejs写了另五个 脚本,脚本功能所以 从redis里出列数据保存到mysql数据库中。你这些脚本会经常运行,当redis那么数据也能 同步到数据库中的完后 ,sleep,让在进行数据同步操作

场景中的哪些地方地方业务基本是用户进入APP都有操作到的,除了活动日(618,双11,等),哪些地方地方业务的用户量都有会高聚集,同时哪些地方地方业务相关的表都有大数据表,业务多是查询操作,所以朋友也能 减少用户直接命中DB的查询;优先查询缓存,而且缓存不发生,再进行DB查询,将查询结果缓存起来。

CDN节点同步有一定的延迟性,所以找另五个 靠谱的CDN服务器商都有点硬要

通过表设计,如:记录表加进唯一约束,数据正确处理逻辑使用事物正确处理并发下的数据错乱难题

下面我进行实例分析,简单粗暴,动态分析,纯属买车人买车人经验分享,如有说错,而且有更好的建议而且意见的请留言,朋友同时成长。

方案如:

设想而且同时有1W个用户同时在线访问页面,另五个 次拉动滚动条屏幕页面展示10件商品,另五个 就会有10W个请求过来,服务端也能 把请求数据入库。在实际线上环境而且都有超过你这些请求量,而且不经过进行高并发设计正确处理,服务器分分钟给跪了。