高并发服务器的逻辑处理瓶颈_数据库

当前位置：网站建设 > 技术支持

资料来源：网络整理时间：2023/3/5 22:03:20 共计：3561 浏览

高并发服务器的逻辑处理瓶颈？

下面就用我有限的知识和经验，讲一讲高并发下的系统处理方案。

1、大部分的系统应用，在建设初期都是单机应用，也就是一个应用服务器加一个数据库。

2、当访问量增多、并发量增加的时候，很多时候应用服务器会先扛不住，通常我们解决这个问题的方法是：把应用服务器做集群部署，在前面搭建负载均衡，例如硬件负载F5、软件负载Nginx。

3、应用服务器的压力暂时解决，但是数据库毕竟还是单台，这时候我们可以在整体的架构中增加缓存，已减少数据库的压力，最常见的是引入Redis，做集群化的部署。

4、业务继续发展，并发量持续增多，单库已经到了极限；这时候可以考虑分库，常见的做法是对分库字段进行hash()%N，按照结果将数据路由到某一个分库(分表)上。

5、系统继续发展，虽然应用是集群化部署，但是毕竟是单个应用，并且随着项目功能的增加，应用包也会越来越大，代码改动起来非常痛苦；这时候需要把应用拆分成多个应用，库也各自独立出来（说的很简单，过程非常之痛苦，所以很多公司在初期，就是按照这个架构搭建）：

应用拆分成多个应用；

应用之间的服务发现和调用，都需要服务注册中心和网关的帮助；

6、虽然应用和库都拆开了，但是应用和应用质检的耦合度依然非常高，所以通常会引入消息队列，例如各种MQ、Kafka，把一些实时性要求不是那么高的服务解耦，比如交易完成时候给客户发一条短信，那么可以把待发送的短信放到消息队列中，短信平台从消息队列中获得消息发送短信。

7、这时候应用的体量已经比较大了，部署、运维、查错的难度加大，这时候需要引入很多组件，来帮助整个系统的稳定运行：

认证中心：安全性的问题要注意，一个接口不是随随便便都能访问的；

限流：当并发量突增的时候，系统肯定会扛不住，这时候限制一部分流量的进入；

监控中心：包括日志监控、服务链路监控、流量监控等等；

告警平台：系统发生异常时，需要及时通知运维人员；

图画的有些仓促，难免有不严谨的地方，大家可以留言指正（如果留言中有态度不好的，我就自动忽略了）。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

版权说明：
本网站凡注明“广州京杭原创”的皆为本站原创文章，如需转载请注明出处！
本网转载皆注明出处，遵循行业规范，如发现作品内容版权或其它问题的，请与我们联系处理！
欢迎扫描右侧微信二维码与我们联系。