高并发解决方案

1.原因

由于系统都是连接数据库的，但是一般最多数据库每秒只能支撑几千的并非，如果业务量激增，会导致系统宕机；因此需要从一下几点入手设计

· 系统拆分

· 缓存

· MQ

· 分库分表

· 读写分离

· 搜索

2.系统拆分

将一个系统进行功能拆分，如现在流行的微服务，每个服务连接的数据库分开，分开部署。这样可以将压力进行拆分，缓解因为网络和数据库导致的高并发

3.缓存

大部分场景下，都是查询多余插入更新，也就是读多写少。因此设计时对常用的查询内容必须进行缓存，查询时先查缓存，再查数据库；更新时也要更新缓存；

redis 单机支持几万的并发。项目设计时针对那些承载主要请求的读场景，怎么用缓存来抗高并发。

4.MQ

再考虑高并发写的场景，比如一个业务操作要数据库操作几十次，增删改增删改，在普通环境下不会有问题，但是如果高并发绝对会出现问题；

如通讯分析项目，话单导入时多线程同时导入。如果多个用户都同时导入，会有多个导入任务，几十几百甚至启动上千的线程跑。也会导致系统出现问题；

可以将大量的写请求灌入 MQ 里，进行排队，后边系统慢慢写，控制在数据库承载范围之内。MQ 单机支持几万并发，所以设计系统时，对应承载复杂写业务逻辑的场景里，如何用 MQ 来异步写，提升并发性。

缺点：

· 系统可用性降低-外部依赖越多，越容易出现问题

· 系统复杂度提高-需要处理重复消费和丢失的问题

· 一致性问题-由于是异步需要保证数据的完整

Kafka、ActiveMQ、RabbitMQ、RocketMQ 优缺点

5.分库分表

单个数据库无法支持，可以考虑多个数据库；如果单个表内容太多可以考虑把表分开存储；单表数据量太大也可以表拆分或者类似分区表的形式处理，每个表的数据量保持少一点，提高 sql 跑的性能

6.读写分离

读写分离，就是大部分时候数据库可能是读多写少，没必要所有请求都集中在一个库上，可以搞个主从架构，主库写入，从库读取，读写分离。读流量太多的时候，还可以加更多的从库

7.搜索

如Elasticsearch，简称 es。es 是分布式的，可以随便扩容，分布式天然就可以支撑高并发，因为可以扩容加机器来扛更高的并发。一些比较简单的查询、统计类的操作，可以考虑用 es 来承载，还有一些全文搜索类的操作，也可以用 es 来承载

8、扩容

扩容思路：

u 垂直扩容（纵向扩展）：提高系统部件能力

u 水平扩容（横向扩展）：增加更多系统成员来实现

数据库扩容：

读操作扩展：memcache、redis、CDN等缓存

写操作扩展：Cassandra、Hbase

9、应用限流

计算器法

滑动窗口

漏桶算法

令牌桶算法

10、动态扩容缩容分库分表方案

（1）停机扩容

这个方案就跟停机迁移一样，步骤几乎一致，唯一的一点就是那个导数的工具，是把现有库表的数据抽出来慢慢倒入到新的库和表里去。但是最好别这么玩儿，有点不太靠谱，因为分库分表就说明数据量实在是太大了，可能多达几亿条，甚至几十亿，这么玩可能会出问题。

（2）优化后的方案

一开始上来就是32个库，每个库32个表，1024张表，这个分法，第一，基本上国内的互联网肯定都是够用了，第二，无论是并发支撑还是数据量支撑都没问题。开始的时候一个数据库服务器可以放多个数据库和表，在扩容或者缩容的时候直接迁移数据库到其他数据库服务器就可以了。例如使用如下步骤：

1、设定好几台数据库服务器，每台服务器上几个库，每个库多少个表，推荐是32库 * 32表，对于大部分公司来说，可能几年都够了

2、路由的规则，orderId 模 32 = 库，orderId / 32 模 32 = 表

3、扩容的时候，申请增加更多的数据库服务器，装好mysql，倍数扩容，4台服务器，扩到8台服务器，16台服务器

4、由dba负责将原先数据库服务器的库，迁移到新的数据库服务器上去，很多工具，库迁移，比较便捷

5、我们这边就是修改一下配置，调整迁移的库所在数据库服务器的地址

6、重新发布系统，上线，原先的路由规则变都不用变，直接可以基于2倍的数据库服务器的资源，继续进行线上系统的提供服务。