大话高并发架构

标签: 大话 并发 架构 | 发表时间:2017-02-06 09:37 | 作者:z724130632
出处:http://www.iteye.com

服务器架构

业务从发展的初期到逐渐成熟,服务器架构也是从相对单一到集群,再到分布式服务。 
一个可以支持高并发的服务少不了好的服务器架构,需要有均衡负载,数据库需要主从集群,nosql缓存需要主从集群,静态文件需要上传cdn,这些都是能让业务程序流畅运行的强大后盾。

大致需要用到的服务器架构如下:

  • 服务器
    • 均衡负载(如:nginx,阿里云SLB)
    • 资源监控
    • 分布式
  • 数据库
    • 主从分离,集群
    • DBA 表优化,索引优化,等
    • 分布式
  • NOSQL
    • redis
      • 主从分离,集群
    • mongodb
      • 主从分离,集群
    • memcache
      • 主从分离,集群
  • CDN
    • html
    • css
    • js
    • imag

并发测试

第三方服务:

  • 阿里云性能测试
并发测试工作:
  • Apache JMeter
  • Visual Studio性能负载测试
  • Microsoft Web Application Stress Tool

实战方案

通用方案

日用户流量大,但是比较分散,偶尔会有用户高聚的情况;

场景: 用户签到,用户中心,用户订单,等
服务器架构图:

通用

说明:

场景中的这些业务基本是用户进入APP后会操作到的,除了活动日(618,双11,等),这些业务的用户量都不会高聚集,同时这些业务相关的表都是大数据表,业务多是查询操作,所以我们需要减少用户直接命中DB的查询;优先查询缓存,如果缓存不存在,再进行DB查询,将查询结果缓存起来。

更新用户相关缓存需要分布式存储,比如使用用户ID进行hash分组,把用户分布到不同的缓存中,这样一个缓存集合的总量不会很大,不会影响查询效率。

 

方案如:

  • 用户签到获取积分
    • 计算出用户分布的key,redis hash中查找用户今日签到信息
    • 如果查询到签到信息,返回签到信息
    • 如果没有查询到,DB查询今日是否签到过,如果有签到过,就把签到信息同步redis缓存。
    • 如果DB中也没有查询到今日的签到记录,就进行签到逻辑,操作DB添加今日签到记录,添加签到积分(这整个DB操作是一个事务)
    • 缓存签到信息到redis,返回签到信息
    • 注意这里会有并发情况下的逻辑问题,如:一天签到多次,发放多次积分给用户。
  • 用户订单
    • 这里我们只缓存用户第一页的订单信息,一页40条数据,用户一般也只会看第一页的订单数据
    • 用户访问订单列表,如果是第一页读缓存,如果不是读DB
    • 计算出用户分布的key,redis hash中查找用户订单信息
    • 如果查询到用户订单信息,返回订单信息
    • 如果不存在就进行DB查询第一页的订单数据,然后缓存redis,返回订单信息
  • 用户中心
    • 计算出用户分布的key,redis hash中查找用户订单信息
    • 如果查询到用户信息,返回用户信息
    • 如果不存在进行用户DB查询,然后缓存redis,返回用户信息
  • 其他业务
    • 上面例子多是针对用户存储缓存,如果是公用的缓存数据需要注意一些问题,如下
    • 注意公用的缓存数据需要考虑并发下的可能会导致大量命中DB查询,可以使用管理后台更新缓存,或者DB查询的锁住操作。

以上例子是一个相对简单的高并发架构,并发量不是很高的情况可以很好的支撑,但是随着业务的壮大,用户并发量增加,我们的架构也会进行不断的优化和演变,比如对业务进行服务化,每个服务有自己的并发架构,自己的均衡服务器,分布式数据库,nosql主从集群,如:用户服务、订单服务;

 

消息队列

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

场景:定时领取红包,等
服务器架构图:

消息队列

说明:

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

像这种不是只有查询的操作并且会有高并发的插入或者更新数据的业务,前面提到的通用方案就无法支撑,并发的时候都是直接命中DB;

设计这块业务的时候就会使用消息队列的,可以将参与用户的信息添加到消息队列中,然后再写个多线程程序去消耗队列,给队列中的用户发放红包;

 

方案如:定时领取红包

  • 一般习惯使用 redis的 list
  • 当用户参与活动,将用户参与信息push到队列中
  • 然后写个多线程程序去pop数据,进行发放红包的业务
  • 这样可以支持高并发下的用户可以正常的参与活动,并且避免数据库服务器宕机的危险

附加:
通过消息队列可以做很多的服务。 
如:定时短信发送服务,使用sset(sorted set),发送时间戳作为排序依据,短信数据队列根据时间升序,然后写个程序定时循环去读取sset队列中的第一条,当前时间是否超过发送时间,如果超过就进行短信发送。

 

一级缓存

高并发请求连接缓存服务器超出服务器能够接收的请求连接量,部分用户出现建立连接超时无法读取到数据的问题;

因此需要有个方案当高并发时候时候可以减少命中缓存服务器;

这时候就出现了一级缓存的方案,一级缓存就是使用站点服务器缓存去存储数据,注意只存储部分请求量大的数据,并且缓存的数据量要控制,不能过分的使用站点服务器的内存而影响了站点应用程序的正常运行,一级缓存需要设置秒单位的过期时间,具体时间根据业务场景设定,目的是当有高并发请求的时候可以让数据的获取命中到一级缓存,而不用连接缓存NOSQL数据服务器,减少NOSQL数据服务器的压力

比如APP首屏商品数据接口,这些数据是公共的不会针对用户自定义,而且这些数据不会频繁的更新,像这种接口的请求量比较大就可以加入一级缓存;

服务器架构图:

通用

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

 

静态化数据

高并发请求数据不变化的情况下如果可以不请求自己的服务器获取数据那就可以减少服务器的资源压力。

对于更新频繁度不高,并且数据允许短时间内的延迟,可以通过数据静态化成JSON,XML,HTML等数据文件上传CDN,在拉取数据的时候优先到CDN拉取,如果没有获取到数据再从缓存,数据库中获取,当管理人员操作后台编辑数据再重新生成静态文件上传同步到CDN,这样在高并发的时候可以使数据的获取命中在CDN服务器上。

CDN节点同步有一定的延迟性,所以找一个靠谱的CDN服务器商也很重要.

 

其他方案

  • 对于更新频繁度不高的数据,APP,PC浏览器,可以缓存数据到本地,然后每次请求接口的时候上传当前缓存数据的版本号,服务端接收到版本号判断版本号与最新数据版本号是否一致,如果不一样就进行最新数据的查询并返回最新数据和最新版本号,如果一样就返回状态码告知数据已经是最新。 减少服务器压力:资源、带宽

转:https://blog.thankbabe.com/2016/09/14/high-concurrency-scheme/

 



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [大话 并发 架构] 推荐:

大话高并发架构

- - 企业架构 - ITeye博客
业务从发展的初期到逐渐成熟,服务器架构也是从相对单一到集群,再到分布式服务. 一个可以支持高并发的服务少不了好的服务器架构,需要有均衡负载,数据库需要主从集群,nosql缓存需要主从集群,静态文件需要上传cdn,这些都是能让业务程序流畅运行的强大后盾. 大致需要用到的服务器架构如下:. 均衡负载(如:nginx,阿里云SLB).

大流量、高并发的网站的底层系统架构

- - 企业架构 - ITeye博客
大流量、高并发的网站的底层系统架构. [转载自] http://www.webjx.com/webmanage/experience-25319.html. 动态应用,是相对于网站静态内容而言, 是指以c/c++、php、Java、perl、.net等 服务器端语言开发的网络应用软件,比如论坛、网络相册、交友、BLOG等常见应用.

一例千万级pv高性能高并发网站架构[原创]

- - 运维进行时
      受CU管理员的邀请参考“ 千万级pv高性能高并发网站架构与设计交流探讨帖”主题的交流,发表了一案例与大家分享.       一个支撑千万级PV的网站是非常考验一个架构是否成熟、健壮(本文不涉及软件架构的层面,有兴趣也可以讨论). 现抛出一个系统层面的架构,不保证是最优的方案,但也许适合你.

千万级pv高性能高并发网站架构与设计(转)

- - BlogJava-
高并发访问的核心原则其实就一句话“把所有的用户访问请求都尽量往前推”. 如果把来访用户比作来犯的"敌人",我们一定要把他们挡在800里地以外,即不能让他们的请求一下打到我们的指挥部(指挥部就是数据库及分布式存储). 如:能缓存在用户电脑本地的,就不要让他去访问CDN. 能缓存CDN服务器上的,就不要让CDN去访问源(静态服务器)了.

高性能、高并发网络通信系统的架构设计

- - CSDN博客推荐文章
    随着互联网和物联网的高速发展,使用网络的人数和电子设备的数量急剧增长,其也对互联网后台服务程序提出了更高的性能和并发要求. 本文的主要目的是阐述如何进行高并发、高性能通信系统的架构设计,以及这样的系统需要用到的常用技术,但不对其中的技术细节进行讨论和实现. 本篇只起抛砖引玉的之效,如有更好的设计方案和思路,望您不舍赐教.

千万级规模高性能、高并发的网络架构经验分享

- - 编程语言 - ITeye博客
在开始谈我对架构本质的理解之前,先谈谈对今天技术沙龙主题的个人见解,千万级规模的网站感觉数量级是非常大的,对这个数量级我们 战略上 要重 视 它 , 战术上又 要 藐 视 它. 先举个例子感受一下千万级到底是什么数量级. 现在很流行的优步(Uber),从媒体公布的信息看,它每天接单量平均在百万左右, 假如每天有10个小时的服务时间,平均QPS只有30左右.

聊聊高并发长连接架构:百万在线的美拍直播弹幕系统如何实现

- -
导读:直播弹幕是直播系统的核心功能之一. 如何迅速作出一个有很好扩展性的弹幕系统. 相信很多工程师/架构师都有自己的想法. 本文作者是美拍的架构师,经历了直播弹幕从无到有,从小到大的过程. 本文是作者对构建弹幕系统的经验总结. 王静波,毕业于西安交通大学,曾任职于网易和新浪微博,微博工作期间负责开放平台业务和技术体系建设.

信息架构

- Michael - Tony-懒得设计
写几篇关于信息架构的文章,系统地输出我理解的信息架构. 发了一篇关于招信息架构实习生的博客,收到不少简历. 但谈起信息架构,多数不了解,稍微了解的扯了很多很偏的东西. 随手搜索了一下,我发现了原因:. 1 《web信息架构》这本书太概念,太学术. 2 有人绑架了“信息架构”这个词,拿出去唬人,内容都是皮毛或者是根本和信息架构不沾边的东西.

CSS架构

- - 博客 - 伯乐在线
英文原文: CSS Architecture,编译: CSDN-张红月. Philip Walton 在AppFolio担任前端工程师,他在Santa Barbara on Rails的聚会上提出了CSS架构和一些最佳实践,并且在工作中一直沿用. 擅长CSS的Web开发人员不仅可以从视觉上复制实物原型,还可以用代码进行完美的呈现.