阅读支付宝架构师眼中的高并发架构

      没有阅读文章在之前，自己对高并发的看法：就是很多用户同时操作，业务场景为类似：天猫618活动，淘宝双十一活动。有可能造成服务器瘫痪，为了解决这一问题，采用分布式服务器以及分布式数据库的高并发架构。

     通过阅读支付宝架构师眼中的高并发架构发现了还有很多东西需要学习，高并发架构目的是为了让业务可以流畅的运行并且给用户一个好的交互体验，我们需要根据业务场景预估达到的并发量等因素，来设计适合自己业务场景的高并发处理方案。从而了解服务器架构：

• 服务器

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

• 资源监控

• 分布式

数据库架构：

      

• 主从分离，集群

• DBA 表优化，索引优化，等

• 分布式

• nosql

• 主从分离，集群

• 主从分离，集群

• 主从分离，集群

• redis

• mongodb

• memcache

• cdn

• html

• css

• js

• image

并发测试:高并发相关的业务，需要进行并发的测试，通过大量的数据分析评估出整个架构可以支撑的并发量。采用第三方服务

 

以下为服务器架构图：

分层，分割，分布式

• 分层

• 将系统在横向维度上切分成几个部分，每个部门负责一部分相对简单并比较单一的职责，然后通过上层对下层的依赖和调度组成一个完整的系统

• 比如把电商系统分成：应用层，服务层，数据层。(具体分多少个层次根据自己的业务场景)

• 应用层：网站首页，用户中心，商品中心，购物车，红包业务，活动中心等，负责具体业务和视图展示

• 服务层：订单服务，用户管理服务，红包服务，商品服务等，为应用层提供服务支持

• 数据层：关系数据库，nosql数据库 等，提供数据存储查询服务

• 分层架构是逻辑上的，在物理部署上可以部署在同一台物理机器上，但是随着网站业务的发展，必然需要对已经分层的模块分离部署，分别部署在不同的服务器上，使网站可以支撑更多用户访问

• 分割

• 在纵向方面对业务进行切分，将一块相对复杂的业务分割成不同的模块单元

• 包装成高内聚低耦合的模块不仅有助于软件的开发维护，也便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展

• 比如用户中心可以分割成：账户信息模块，订单模块，充值模块，提现模块，优惠券模块等

 

• 分布式

• 分布式应用和服务,将分层或者分割后的业务分布式部署，独立的应用服务器，数据库，缓存服务器

• 当业务达到一定用户量的时候，再进行服务器均衡负载，数据库，缓存主从集群

• 分布式静态资源，比如：静态资源上传cdn

• 分布式计算，比如：使用hadoop进行大数据的分布式计算

• 分布式数据和存储,比如：各分布节点根据哈希算法或其他算法分散存储数据

异步

 

在高并发业务中如果涉及到数据库操作，主要压力都是在数据库服务器上面，虽然使用主从分离，但是数据库操作都是在主库上操作，单台数据库服务器连接池允许的最大连接数量是有限的 

 当连接数量达到最大值的时候，其他需要连接数据操作的请求就需要等待有空闲的连接，这样高并发的时候很多请求就会出现connection time out 的情况 

 

 

缓存

 

高并发业务接口多数都是进行业务数据的查询，如：商品列表，商品信息，用户信息，红包信息等，这些数据都是不会经常变化，并且持久化在数据库中

 高并发的情况下直接连接从库做查询操作，多台从库服务器也抗不住这么大量的连接请求数（单台数据库服务器允许的最大连接数量是有限的）

总结：通过今天的学习了解了高并发架构是一个不断衍化的过程，需要很多东西相互辅助，基本上采用分布式架构。从服务器架构图上可以详细了解整个服务器的结构。今后应多多学习关于高并发方面的知识。