mysql 枚举类型查询，高并发服务器的逻辑处理瓶颈？
下面就用我有限的知识和经验，讲一讲高并发下的系统处理方案。
1、大部分的系统应用，在建设初期都是单机应用，也就是一个应用服务器加一个数据库。
2、当访问量增多、并发量增加的时候，很多时候应用服务器会先扛不住，通常我们解决这个问题的方法是：把应用服务器做集群部署，在前面搭建负载均衡，例如硬件负载F5、软件负载Nginx。
3、应用服务器的压力暂时解决，但是数据库毕竟还是单台，这时候我们可以在整体的架构中增加缓存，已减少数据库的压力，最常见的是引入Redis，做集群化的部署。
4、业务继续发展，并发量持续增多，单库已经到了极限；这时候可以考虑分库，常见的做法是对分库字段进行hash()%N，按照结果将数据路由到某一个分库(分表)上。
5、系统继续发展，虽然应用是集群化部署，但是毕竟是单个应用，并且随着项目功能的增加，应用包也会越来越大，代码改动起来非常痛苦；这时候需要把应用拆分成多个应用，库也各自独立出来（说的很简单，过程非常之痛苦，所以很多公司在初期，就是按照这个架构搭建）：
应用拆分成多个应用；
应用之间的服务发现和调用，都需要服务注册中心和网关的帮助；
6、虽然应用和库都拆开了，但是应用和应用质检的耦合度依然非常高，所以通常会引入消息队列，例如各种MQ、Kafka，把一些实时性要求不是那么高的服务解耦，比如交易完成时候给客户发一条短信，那么可以把待发送的短信放到消息队列中，短信平台从消息队列中获得消息发送短信。
7、这时候应用的体量已经比较大了，部署、运维、查错的难度加大，这时候需要引入很多组件，来帮助整个系统的稳定运行：
认证中心：安全性的问题要注意，一个接口不是随随便便都能访问的；
限流：当并发量突增的时候，系统肯定会扛不住，这时候限制一部分流量的进入；
监控中心：包括日志监控、服务链路监控、流量监控等等；
告警平台：系统发生异常时，需要及时通知运维人员；
图画的有些仓促，难免有不严谨的地方，大家可以留言指正（如果留言中有态度不好的，我就自动忽略了）。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
本文链接：https://my.lmcjl.com/post/16849.html
4 评论