浅谈如何设计一个高并发系统
概述
为什么要设计高并发的系统呢？随着日益增长的用户量，一般来说，一个系统起步都是直接是连接数据库的，而数据库支撑到每秒并发两三千的时候，基本就快完了，不断的堆配置，加集群始终不是解决之道。
一个高并发的系统，应该从以下几个方面逐步优化：
- 系统拆分
- 缓存中间件
- MQ 消息队列
- 分库分表
- 数据库读写分离
- ElasticSearch
系统拆分
将一个系统，按照业务拆分成多个服务，可以用 dubbo、springcloud 来做，每个模块连接一个单独的数据库，服务之间通过 RPC 来进行通信，这就是微服务的雏形，还有很多需要考虑的东西，如网关、鉴权、链路追踪、服务降级、熔断等等
缓存中间件
大部分的高并发场景，都是读多写少，完全可以先从缓存查询，这一步可以用 Redis 来做，由于直接操作内存的特性，可以轻松抗住单机几万的并发量，当然有些关键的问题也是需要考虑的，如缓存与数据库不一致、缓存雪崩、缓存击穿、缓存并发竞争等问题。
MQ 消息队列
MQ 的存在，也是为了对抗高并发的业务请求，大量的查询请求被打到了缓存，但是写操作呢？直接打到数据库一样死翘翘，这时我们可以利用 MQ 消息队列来做削峰处理，管你多少请求，我一并写到消息队列，然后以一个合理的速度慢慢的往数据库写，控制在 MySQL 的承受范围内。当然这个写操作是异步的，所以得考虑哪些数据实时性要求不高且数据相对比较复杂，适合用异步来做。
分库分表
虽然已经按照业务，拆分了数据库，但是单个数据库也是有瓶颈的，这时又不得不考虑分库分表了，那么就将一个数据库拆分为多个库，多个库来扛更高的并发；然后将一个表拆分为多个表，每个表的数据量保持少一点，提高 SQL 跑的性能。
数据库读写分离
对于大部分系统来说，都是读多写少，写的操作对数据库来说压力更大，这时我们可以搞个读写分离，因为没必要所有的请求都在一个库上，可以搞个主从架构，主库写入，从库读取。读流量太多的时候，还可以加更多的从库。
ElasticSearch
从海量数据中检索数据，就不要傻傻的写 SQL 查询了，稍不注意就玩死了，花点时间，搭建一个搜索引擎，es 是分布式的，可以随便扩容，分布式天然就可以支撑高并发。
评论