架构师眼中的高并发架构

<div class="blog-abstract">择要: 以架构师的目光来报告高并发架构
<div id="blogBody" class="blog-body">
<div class="BlogContent clearfix">
<h3 id="h3_0">媒介

高并发常常会产生在有大活泼用户量，用户高聚积的营业场景中，如：秒杀勾当，按时领取红包等。为了让营业可以流通的运行而且给用户一个好的交互体验，我们必要按照营业场景预估到达的并发量等身分，来计划得当本身营业场景的高并发处理赏罚方案。

在电商相干产物开拓的这些年，我有幸的碰着了并发下的各类坑，这一起摸爬滚打过来有着不少的血泪史，这里举办的总结，作为本身的归档记录，同时分享给各人。

营业从成长的初期到逐渐成熟，处事器架构一ㄇ从相对单一到集群，再到漫衍式处事。?一个可以支持高并发的处事少不了好的处事器架构，必要有平衡负载，数据库必要主从集群，nosql缓存必要主从集群，静态文件必要上传cdn，这些都是能让营业措施流通运行的强盛后援。

处事器这块多是必要运维职员来共同搭建，详细我就不多说了，点到为止。大抵必要用到的处事器架构如下：

• 处事器
  • 平衡负载(如：nginx，阿里云SLB)
  • 资源监控
  • 漫衍式
• 数据库
  • 主从疏散，集群
  • DBA 表优化，索引优化，等
  • 漫衍式
• nosql
  • redis
    • 主从疏散，集群
  • mongodb
    • 主从疏散，集群
  • memcache
    • 主从疏散，集群
• cdn
  • html
  • css
  • js
  • image

高并发相干的营业，必要举办并发的测试，通过大量的数据说明评估出整个架构可以支撑的并发量。

测试高并发可以行使第三方处事器可能本身测试处事器，操作测试器材举办并发哀求测试，说明测试数据获得可以支撑并发数目的评估，这个可以作为一个预警参考，俗话说良知自彼百战不殆。

第三方处事:

• 阿里云机能测试

并发测试器材：

• 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；

计划这块营业的时辰就会行使动静行列的，可以将参加用户的信息添加到动静行列中，然后再写个多线程措施去耗损行列，给行列中的用户发放红包；

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!