服务器高并发，高QPS之拙见

一般的互联网产品都会有并发或者高频查询（QPS）问题，今天分享一下我个人的拙见，欢迎讨论！
我个人遇到的问题主要有以下几点：

1、某些拳头活动（业务）拉新为保证超预期效果，遇到高并发问题
2、某些业务，C端用户对于B端的数据及时性需求很高，会遇到高QPS问题

假定程序环境为：Linux + java + nginx

针对第一点目前已知的较为友好、简单的解决方案有：
1、服务器做负载均衡
2、nginx和java设置每秒接纳请求数限定范围
3、服务器请求时间延长
(2、3没有太大必要，在保证服务器稳定提供服务的同时会损失一定的用户体验)
4、调整业务，尽量剥离出来一部分业务数据缓存（也就是加Redis等缓存技术）
5、添加行为验证，比如滑块验证等
（不建议添加此功能，因为硬手段可以一定程度上缓解服务器压力，但是会用户体验会有较大折损）

针对第二点目前已知的较为友好、简单的解决方案有：
1、拆分业务，使用较为稳定的缓存服务，但是频繁查改缓存在保证服务的同时会加大服务器负荷
2、nginx和java设置每秒接纳请求数限定范围
3、服务器请求时间延长

上面是一些较为简单，对开发相对友好的解决方案，从现在非同一跑道内的一二线产品来看，缓存技术应用足矣解决很大部分的并发问题，在产品前期足够用，但是中后期上限很明显，最明显的就是在产品长期存在高QPS的情况下，此种方式会引引起缓存崩溃，进而引发磁盘I/O拉满，以下介绍几种架构级别的解决方案，大家可以探讨以下，有不足之处欢迎指正。

因为发展到一定程度之后，程序的性能瓶颈主要在数据库的 I/O 上，所以对于一些代码、设计上的优化（数据库主键，循环，死锁，事务，算法，单业务打开数据库次数、等）这里就不再赘述。

以下B端可以理解为高频写入业务，C端为高频读取业务，不一定要按照传统意义上的B、C端来界定业务作用

a）、数据库读写分离，如下图：

即把业务拆分为读、写两块，具体工作原理为：

1、拆分之后的业务采用微服务的方式分别部署（也可以不分服务器，只分库）
2、B端写入数据时写入业务1（写入）服务器，通过数据同步 把从数据库数据同步至主数据库，C端主要操作业务2（读取）服务器
3、可以按需把写入服务器或者读取服务器做一个服务器集群，用负载均衡进行管理（如果资源允许，用分布式部署能更好的均匀平摊请求，很大程度上缓解服务器压力）

此种方法好处是很大程度上缓解了并发带来的压力，能硬抗一定程度的并发。从现在非同一跑道内的一二线产品来看，足矣，但是也会有一些局限性，最典型的一个问题就是 write after Read 在C端读取数据及时性要求较高的业务上，会存在写晚于读的情况，而且对于分库之后缓存的使用就会有一定的限制，比如跨服务器、数据同步、不易维护等问题。

b）、垂直分库，如下图：

即把数据库根据业务进行拆分，数据存入不同的业务库中，大致工作原理为：

1、根据不同的业务，拆分数据库，程序拆分为微服务采用分布式部署（也可以只用单台服务器，也可分别独立部署）
（切记，拆分业务务必明确且有规划性，否则会导致后面业务扩展时增加大量的跨库查询）
2、此种架构工作原理简单，分业务存储，需要时进行跨库查询数据（尽量减少此种操作），高并发业务、高QPS业务可以使用负载均衡或者缓存技术，也可以针对性提升硬件环境或者集群大小避免造成服务器资源分配不均

此种方法好处很明显，就是避免了服务器资源分配不均问题，可以从硬件上补足某些特定业务的不足，且能有效的降低高QPS带来的高I/O压力。坏处也很明显，就是对业务扩展有很大的限制性，因为跨业务就代表着跨库，跨库耗费的资源在非高频业务来说影响不大，但是对于高频业务打击是致死性的。比较考验架构师对业务的理解程度和整体开发团队经验。如果采用此种方式，基本可以满足企业所需。

c）、水平分库，如下图：

水平分库与垂直分库从架构设计上来说是一样的，不同的是分库规则。大致工作原理为：

1、重构业务逻辑，把某些有关联的数据确定一个主体，按照一定的规则，（比如主体的主键生成规则）存入到某个库，即这种分库操是单纯的把数据分开存储

此种方法原理也很简单，他跟垂直分库原理相悖，可以减少跨业务导致的跨库操作，但是在多主体数据联合展示时需要打开多个数据库连接，也会损失一定的效率。可以根据公司业务选择两种方式的其中一种

d）、nosql
此种方法适合产品前期研发，完全重构代码代价过大（我个人不推荐完全重构）

工作原理，使用非传统的关系型数据库做数据存储用。重构的话，如果业务复杂，损伤过大。

此技术还未完全成熟，在此写上仅做参考，可行性待研究。

大家可以探讨以下，一起进步