架构师眼中的高并发架构

高并发业务接口多数都是进行业务数据的查询，如：商品列表，商品信息，用户信息，红包信息等，这些数据都是不会经常变化，并且持久化在数据库中高并发的情况下直接连接从库做查询操作，多台从库服务器也抗不住这么大量的连接请求数（前面说过，单台数据库服务器允许的最大连接数量是有限的）那么我们在这种高并发的业务接口要如何设计呢？

• 设计考虑：
  • 还是逆向思维，压力在数据库，那么我们就不进行数据库查询
  • 数据不经常变化，我们为啥要一直查询DB？
  • 数据不变化客户端为啥要向服务器请求返回一样的数据？
• 方案设计：
  • 数据不经常变化，我们可以把数据进行缓存，缓存的方式有很多种，一般的：应用服务器直接Cache内存，主流的：存储在memcache、redis内存数据库
  • Cache是直接存储在应用服务器中，读取速度快，内存数据库服务器允许连接数可以支撑到很大，而且数据存储在内存，读取速度快，再加上主从集群，可以支撑很大的并发查询
  • 根据业务情景，使用配合客户端本地存，如果我们数据内容不经常变化，为啥要一直请求服务器获取相同数据，可以通过匹配数据版本号，如果版本号不一样接口重新查询缓存返回数据和版本号，如果一样则不查询数据直接响应
  • 这样不仅可以提高接口响应速度，也可以节约服务器带宽，虽然有些服务器带宽是按流量计费，但是也不是绝对无限的，在高并发的时候服务器带宽也可能导致请求响应慢的问题
• 补充：
  • 缓存同时也指静态资源客户端缓存
  • cdn缓存，静态资源通过上传cdn，cdn节点缓存我们的静态资源，减少服务器压力

• 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几秒
  • 因为数据量会比较大，上报的数据表按天命名存储
• 接口：
  • 上报数据接口
  • 统计查询接口
• 上线跟进：
  • 服务业务基本正常
  • 每天的上报表有上千万的数据

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

• 冗余
  • 数据库备份
  • 备用服务器
• 自动化
  • 自动化监控
  • 自动化报警
  • 自动化降级

（编辑：PHP编程网 - 湛江站长网）

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