1.什么是高并发及高并发概念
高并发（High Concurrency）是互联网分布式系统常出现的一种问题机制，通常是客户端发起过多请求至服务端导致服务端接收过多的请求而形成的线程拥堵、阻塞出现的线程并发现象。高并发常用的一些有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），并发用户数等。
响应时间：系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200ms，这个200ms就是系统的响应时间。
吞吐量：单位时间内处理的请求数量。
QPS：每秒响应请求数。在互联网领域，这个指标和吞吐量区分的没有这么明显。
并发用户数：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。
压力测试：测试能承受的最大并发，测试最大承受的QPS值，(我常用的压力测试工具为jmeter进行模拟压测)
2.高并发解决方案
服务端优化：页面静态化，并发处理，队列处理
系统拆分:将一个系统拆分为多个子系统，然后每个系统连一个数据库，这样本来就一个库，现在多个数据库，这样就可以抗高并发。
redis缓存:大部分的高并发场景，都是读多写少，完全可以在数据库和缓存里都写一份，然后读取的时候大量走缓存。redis底层是以队列单线程的方式进行处理的可以解决几万的并发请求。所以如果项目中存在大量的请求读场景，可以使用缓存来抗高并发。
MQ(消息队列):可能你还是会出现高并发写的场景，比如说一个业务操作里要频繁搞数据库几十次，增删改增删改。那高并发绝对可能爆掉你的系统，人家是缓存你要是用redis来承载写那肯定不行，数据随时就被LRU(淘汰掉最不经常使用的)了，数据格式还无比简单，没有事务支持。所以该用mysql还得用mysql啊。那你咋办？用MQ吧，大量的写请求灌入MQ里，排队慢慢玩儿，后边系统消费后慢慢写，控制在mysql承载范围之内。所以你得考虑考虑你的项目里，那些承载复杂写业务逻辑的场景里，如何用MQ来异步写，提升并发性。MQ单机抗几万并发也是ok的。
数据库优化：数据库缓存，分库分表，分区操作，读写分离，负载均衡
分库分表:可能到了最后数据库层面还是免不了抗高并发的要求，好吧，那么就将一个数据库拆分为多个库，多个库来抗更高的并发；然后将一个表拆分为多个表，每个表的数据量保持少一点，提高sql跑的性能。
读写分离:这个就是说大部分时候数据库可能也是读多写少，没必要所有请求都集中在一个库上吧，可以搞个主从架构，主库写入，从库读取，搞一个读写分离。读流量太多的时候，还可以加更多的从库。
流量优化：防盗链处理
防盗链处理：防止别人通过一些技术手段绕过本站的资源展示页面，盗用本站的资源，让绕开本站资源展示页面的资源链接失效，可以大大减轻服务器及带宽的压力
前端优化：减少HTTP请求，合并css或js，添加异步请求，启用浏览器缓存和文件压缩，CDN加速，建立独立图片服务器，
减少HTTP请求:改善响应时间的最简单途径就是减少组件的数量，并由此减少HTTP请求的数量
图片使用base64编码减少页面请求数：采用base64的编码方式将图片直接嵌入到网页中，而不是从外部载入
web服务器优化：负载均衡，nginx反向代理，7,4层LVS软件
nginx负载均衡：内置策略：IP Hash，加权轮询；扩展策略：fair策略，通用hash，一致性hash
加权轮询：首先将请求都分给高权重的机器，直到该机器的权值降到了比其他机器低，才开始将请求分给下一个高权重的机器，当所有后端机器都down掉时，nginx会立即将所有机器的标志位清成初始状态，以避免造成所有的机器都处在timeout的状态；IP Hash：流程和轮询很类似，只是其中的算法和具体的策略有些变化，算法是一种变相的轮询算法；fair：根据后端服务器的响应时间判断负载情况，从中选出负载最轻的机器进行分流；通用hash，一致性hash：通用hash比较简单，可以以nginx内置的变量为key进行hash，一致性hash采用了nginx内置的一致性hash环，支持memcache