阅读之支付宝高并发架构

 

高并发常常会发生在有大活跃用户量，用户高汇集的业务场景中，如：秒杀活动，定时领取红包等。

为了让业务能够流畅的运行而且给用户一个好的交互体验，咱们须要根据业务场景预估达到的并发量等因素，来设计适合本身业务场景的高并发处理方案。

服务器架构

 

业务从发展的初期到逐渐成熟，服务器架构也是从相对单一到集群，再到分布式服务。 

一个能够支持高并发的服务少不了好的服务器架构，须要有均衡负载，数据库须要主从集群，nosql缓存须要主从集群，静态文件须要上传cdn，这些都是能让业务程序流畅运行的强大后盾。

 

服务器这块可能是须要运维人员来配合搭建，具体我就很少说了，点到为止。

大体须要用到的服务器架构以下：

 

服务器

均衡负载(如：nginx，阿里云SLB)

资源监控

分布式

数据库

主从分离，集群

DBA 表优化，索引优化，等

分布式

nosql

主从分离，集群

主从分离，集群

主从分离，集群

redis

mongodb

memcache

cdn

html

css

js

image

 

并发测试

 

高并发相关的业务，须要进行并发的测试，经过大量的数据分析评估出整个架构能够支撑的并发量。

测试高并发可使用第三方服务器或者本身测试服务器，利用测试工具进行并发请求测试，分析测试数据获得能够支撑并发数量的评估，这个能够做为一个预警参考，俗话说知己自彼百战不殆。

第三方服务：

阿里云性能测试

并发测试工具：

Apache JMeter

Visual Studio性能负载测试

Microsoft Web Application Stress Tool

实战方案

面向服务

SOA面向服务架构设计

微服务更细粒度服务化，一系列的独立的服务共同组成系统

使用服务化思惟，将核心业务或者通用的业务功能抽离成服务独立部署，对外提供接口的方式提供功能。

最理想化的设计是能够把一个复杂的系统抽离成多个服务，共同组成系统的业务，优势：松耦合，高可用性，高伸缩性，易维护。

经过面向服务化设计，独立服务器部署，均衡负载，数据库集群，可让服务支撑更高的并发

 

服务例子：

用户行为跟踪记录统计

 

说明：

经过上报应用模块，操做事件，事件对象，等数据，记录用户的操做行为

好比：记录用户在某个商品模块，点击了某一件商品，或者浏览了某一件商品

 

背景：

因为服务须要记录用户的各类操做行为，而且能够重复上报，准备接入服务的业务又是核心业务的用户行为跟踪，因此请求量很大，高峰期会产生大量并发请求。

 

架构：

nodejs WEB应用服务器均衡负载

redis主从集群

mysql主

nodejs+express+ejs+redis+mysql

服务端采用nodejs,nodejs是单进程（PM2根据cpu核数开启多个工做进程），采用事件驱动机制，适合I/O密集型业务，处理高并发能力强

 

业务设计：

并发量大，因此不能直接入库，采用：异步同步数据,消息队列

请求接口上报数据，接口将上报数据push到redis的list队列中

nodejs写入库脚本，循环pop redis list数据，将数据存储入库，并进行相关统计Update，无数据时sleep几秒

由于数据量会比较大，上报的数据表按天命名存储

 

接口：

上报数据接口

统计查询接口

上线跟进：

服务业务基本正常

天天的上报表有上千万的数据

冗余，自动化

 

当高并发业务所在的服务器出现宕机的时候，须要有备用服务器进行快速的替代，在应用服务器压力大的时候能够快速添加机器到集群中，因此咱们就须要有备用机器能够随时待命。 最理想的方式是能够经过自动化监控服务器资源消耗来进行报警，自动切换降级方案，自动的进行服务器替换和添加操做等，经过自动化能够减小人工的操做的成本，并且能够快速操做，避免人为操做上面的失误。

 

冗余

数据库备份

备用服务器

自动化

自动化监控

自动化报警

自动化降级

作了备份数据并不表明就万无一失了，咱们须要保证高可用性，首先备份是否正常进行，备份数据是否可用，须要咱们进行按期的检查，或者自动化监控， 还有包括如何避免人为上的操做失误问题。

总结：高并发的架构适用方案有不少，在不一样的业务场景下选择合适的方案是必要的。