高并发是系统架构中必须考虑的的因素，是指通过设计使系统尽可能多的同时处理大量的用户请求。例如12306抢票。
处理高并发的方式有3种途径，可以共同使用。
1.主要处理硬件层面的。
2.对数据库下手的。
3.对软件代码下手。
我们的系统架构一般都不是一蹴而就的，系统刚刚上线的时候，用户很少，一般就是最简单的架构。如下图。
随着用户量的增多，并发数量呈指数级增长，这个架构明显就不够用了。第一种途径就登场了。
第一种：硬件层面
初期：增加服务器的硬件性能，如增加CPU,换更好的网卡，升级硬盘，扩充内存等。
优点：简单，快速。
原因：在业务发展的早期，推荐这种办法。因为在早期，时间就是金钱这个观念被发扬的极致，错过这个时间，
后面再想弯道超车的可能性，就非常小了。
后期：当增加服务器性能也不足以支撑并发量的时候，就需要增加服务器的数量。方法有一下几种：
1.增加反向代理服务器：在dns服务器为域名配置ip的时候，可以为一个域名配置多个ip，域名和ip1对多的关系。
2.增加web应用服务器。在反向代理服务器配置时，通过负载均衡，设置多个web应用服务器，1对多关系。
优点：快速，买几台服务器，经过简单的配置就能实现。
第二种：对数据库下手。
当增加了多台服务器之后，你会发现并发的瓶颈发生在了数据库。缓解数据库压力的办法有。
1.缓存。
其实缓存不应该放在这里来说。因为一般的稍微做过优化的系统，都会运用缓存的，算是化蛇添足了。
2.读写分离。
两台一样的数据库服务器。第一台作为主数据库，负责增删改。第二台数据库，负责查。
这个也算是化蛇添足吧，因为正式上线的系统，为了系统的稳定性考虑，都是要进行数据备份的，保证当第一台数据库服务器挂掉之后，能够立刻启动第二台数据库服务器进行备用。但是这样就浪费了第二台服务器的资源。于是把查询的操作都丢给第二台服务器做。
后果，稳定性降低，处理并发能力提高。算是折中方案吧。
3.分表分库。
顾名思义，分表就是把一张表拆成几张，比如订单表，可以分成多张（按用户，按日期等）。分库，就是把
一个数据库分成多个。存放在多 个数据库服务器上。
如果只是某些数据表的压力比较大的话，就只需要分表。整台数据库服务器压力都很大，就需要分库了。
分库又分为水平拆分和垂直拆分。
垂直拆分，就是按照业务把数据库分开。比如一个数据库可以分为用户模块，产品模块，订单模块。
水平拆分，就是把一张表分开到不同数据库。切分方式很多，一般有范围、时间、取模、枚举。
范围：比如用户表，用户id是1-10000.的在数据库1，id在10001-20000在数据库2.
问题：一般新用户比较活跃，造成某个服务器压力特别突出。
时间：如订单表。按月分，去年的，前年的。
问题：最近日期的服务器压力特别突出。
取模：比如用户表id%2==0的，在数据库1，id%2==1的时候在，数据库2。
扩容很困难。比如这两个数据库压力又很大，需要第三台的时候，数据需要重新整理。
枚举：比如用户表：北京的一个库，南京的一个库。
PS:分表分库会影响事务的处理，也会影响分页排序的问题，谨慎使用。
第三种：对软件代码下手。
总有那么一些业务是冲着某个数据去的，不能加服务器，也不能分表分库。比如秒杀。库存就在那，所有人都会在同一 时间，集中读写。
这种需求的核心就是数据库，不能分库，分表，要想提升性能，就只能把无效的请求挡在数据库之外。还需要层层拦截。
第一层拦截，浏览器或者App端。在用户点击查询，或者秒杀之后，按钮置灰，不能重复提交。限定5s最多请求一次。
能拦截普通用户，不能拦截像我等的IT从业人员。
第二层拦截，后台直接在内存里面判断同一用户id是否在5s内已经请求过了。
查询情况：如果已经请求，直接返回缓存数据。如果没有，则请求。
秒杀情况：如果已经请求，拦截该次请求。如果没有，则请求。
针对的是我等直接调用http接口的IT从业人员。
第三层拦截，第三层过去的请求还是很多，同一时间处理肯定还是问题。
那么运用队列进行判断处理。如果秒杀数量是100个，那么第110个之后的，直接返回"秒杀完"， 不经过数据 库。
