高并发是互联网应用的一大特点，也是互联网应用不可避免的一个问题;比如淘宝双11购物狂欢节，京东618购物促销节，12306春节火车票，促销，秒杀等。
解决高并发问题是一个系统工程，需要站在全局高度统筹谋划，从多个角度进行架构设计；
解决高并发问题，不是一个或两个方案就能解决的，需要从各个维度综合施策才能完成；
在实践中，我们总结和提炼出来了很多应对高并发的方案或者说手段，分别如下：
系统访问用户增多，流量增大，导致服务器压力增大，出现性能瓶颈，我们可以采用一个简单粗暴的策略：提升服务器硬件配置，提升服务器硬件配置的策略，也称为：单体应用垂直扩容。
比如：产品或者网站初期，通常功能较少，用户量也不多，一般就采用一个项目工程来完成，这就是单体应用，也叫集中式应用。
按照经典的MVC三层架构设计，部署单台服务器，使用单台数据库，应用系统和数据库部署在同一台服务器上，随着应用系统功能的增加，访问用户的增多，单台服务器已无法承受那么多的访问流量。
此时，我们可以直接采用简单粗暴的办法：提升硬件配置来解决。
?CPU从32位提升为64位
?内存从64GB提升为256GB(比如缓存服务器);
?磁盘从HDD(HardDiskDrive)提升为SSD(固态硬盘(SolidStateDrives))，有大量读写的应用
?磁盘扩容，1TB扩展到2TB，比如文件系统
?千兆网卡提升为万兆网卡
但是不管怎么提升硬件性能，硬件性能的提升不可能永无止尽，所以最终还是要靠分布式解决。
缓存可以说是解决大流量高并发，优化系统性能非常重要的一个策略；
它是解决性能问题的利器，就像一把瑞士军刀，锋利强大；
缓存在高并发系统中无处不在(到处都是)。
①浏览器缓存
浏览器缓存是指当我们使用浏览器访问一些网站页面或者HTTP服务时，根据服务器端返回的缓存设置响应头将响应内容缓存到浏览器，下次可以直接使用缓存内容或者仅需要去服务器端验证内容是否过期即可，这样可以减少浏览器和服务器之间来回传输的数据量，节省带宽，提升性能;
第一次访问返回200，第二次刷新访问，返回响应码为304，表示页面内容没有修改过，浏览器缓存的内容还是最新的，不需要从服务器获取，直接读取浏览器缓存即可
我们也可以在Java代码中通过设置响应头，告诉前端浏览器进行缓存：
Nginx提供了expires指令来实现缓存控制，比如：
location/static{ root/opt/static/; expires1d;//全天}当用户访问时，Nginx拦截到请求后先从Nginx本地缓存查询数据，如果有并且没有过期，则直接返回缓存内容。
③CDN缓存
CDN的全称是ContentDeliveryNetwork，即内容分发网络。CDN是构建在网络之上的内容分发网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术。
CDN它本身也是一个缓存，它把后端应用的数据缓存起来，用户要访问的时候，直接从CDN上获取，不需要走后端的Nginx，以及具体应用服务器Tomcat，它的作用主要是加速数据的传输，也提高稳定性，如果从CDN上没有获取到数据，再走后端的Nginx缓存，Nginx上也没有，则走后端的应用服务器，CDN主要缓存静态资源。
①内存缓存
在内存中缓存数据，效率高，速度快，应用重启缓存丢失。
②磁盘缓存
在磁盘缓存数据，读取效率较之内存缓存稍低，应用重启缓存不会丢失。
代码组件：Guava、Ehcache
服务器：Redis、MemCache
在整个应用系统的不同层级进行数据的缓存，多层次缓存，来提升访问效率;
比如：浏览器->CDN->Nginx->Redis->DB(磁盘、文件系统)
?经常需要读取的数据
?频繁访问的数据
?热点数据缓存
?IO瓶颈数据
?计算昂贵的数据
?无需实时更新的数据
?缓存的目的是减少对后端服务的访问，降低后端服务的压力
有一个单体应用，当访问流量很大无法支撑，那么可以集群部署，也叫单体应用水平扩容，原来通过部署一台服务器提供服务，现在就多部署几台，那么服务的能力就会提升。
部署了多台服务器，但是用户访问入口只能是一个，比如www.web.com，所以就需要负载均衡，负载均衡是应用集群扩容后的必须步骤，集群部署后，用户的会话session状态要保持的话，就需要实现session共享。
应用的拆分：分布式(微服务)
单体应用，随着业务的发展，应用功能的增加，单体应用就逐步变得非常庞大，很多人维护这么一个系统，开发、测试、上线都会造成很大问题，比如代码冲突，代码重复，逻辑错综混乱，代码逻辑复杂度增加，响应新需求的速度降低，隐藏的风险增大，所以需要按照业务维度进行应用拆分，采用分布式开发;
随着业务复杂度增加，我们需要采用一些开源方案进行开发，提升开发和维护效率，比如Dubbo、SpringCloud;
通过应用拆分之后，扩容就变得容易，如果此时系统处理能力跟不上，只需要增加服务器即可(把拆分后的每一个服务再多做几个集群)。
数据库拆分分为：垂直拆分和水平拆分(分库分表)；
按照业务维度把相同类型的表放在一个数据库，另一些表放在另一个数据库，这种方式的拆分叫垂直拆分，也就是在不同库建不同表，把表分散到各个数据库；
比如产品、订单、用户三类数据以前在一个数据库中，现在可以用三个数据库，分别为产品数据库、订单数据库、用户数据库；
这样可以将不同的数据库部署在不同的服务器上，提升单机容量和性能问题，也解决多个表之间的IO竞争问题；
根据数据行的特点和规则，将表中的某些行切分到一个数据库，而另外的某些行又切分到另一个数据库，这种方式的拆分叫水平拆分；
单库单表在数据量和流量增大的过程中，大表往往会成为性能瓶颈，所以数据库要进行水平拆分；
数据库拆分，采用一些开源方案，降低开发难度，比如：MyCat、Sharding-Sphere。
对于一些访问量大，更新频率较低的数据，可直接定时生成静态html页面，供前端访问，而不是访问jsp；
常用静态化的技术：freemaker、velocity；
定时任务，每隔2分钟生成一次首页的静态化页面；
页面静态化首先可以大大提升访问速度，不需要去访问数据库或者缓存来获取数据，浏览器直接加载html页即可；
页面静态化可以提升网站稳定性，如果程序或数据库出了问题，静态页面依然可以正常访问。
采用比如Nginx实现动静分离，Nginx负责代理静态资源，Tomcat负责处理动态资源；
Nginx的效率极高，利用它处理静态资源，可以为后端服务器分担压力；
动静分离架构示意图
redis和nginx并发量5w左右,tomcat和mysql700左右,当然可以通过一些方式调整。
?采用队列是解决高并发大流量的利器
?队列的作用就是：异步处理/流量削峰/系统解耦
?异步处理是使用队列的一个主要原因，比如注册成功了，发优惠券/送积分/送红包/发短信/发邮件等操作都可以异步处理
?使用队列流量削峰，比如并发下单、秒杀等，可以考虑使用队列将请求暂时入队，通过队列的方式将流量削平，变成平缓请求进行处理，避免应用系统因瞬间的巨大压力而压垮
?使用队列实现系统解耦，比如支付成功了，发消息通知物流系统，发票系统，库存系统等，而无需直接调用这些系统;
?队列应用场景
不是所有的处理都必须要实时处理；
不是所有的请求都必须要实时告诉用户结果；
不是所有的请求都必须100%一次性处理成功；
不知道哪个系统需要我的协助来实现它的业务处理，保证最终一致性，不需要强一致性。
常见的消息队列产品：ActiveMQ/RabbitMQ/RocketMQ/kafka
?ActiveMQ是jms规范下的一个老牌的成熟的消息中间件/消息服务器
?RabbitMQ/RocketMQ数据可靠性极好，性能也非常优秀，在一些金融领域、电商领域使用很广泛;RocketMQ是阿里巴巴的;
?kafka主要运用在大数据领域，用于对数据的分析，日志的分析等处理，它有可能产生消息的丢失问题，它追求性能，性能极好，不追求数据的可靠性
在实际开发中，我们经常会采用一些池化技术，减少资源消耗，提升系统性能。
通过复用对象，减少对象创建和垃圾收集器回收对象的资源开销；
可以采用commons-pool2实现；
实际项目采用对象池并不常见，主要在开发框架或组件的时候会采用。
Druid/DBCP/C3P0/BoneCP
JedisPool(内部基于commons-pool2实现)
核心实现类：PoolingClientConnectionManager
Java提供java.util.concurrent包可以实现线程池
Executors.newFixedThreadPool(8);线程数量固定
Executors.newSingleThreadExecutor();只有一个线程，避免关闭情况
Executors.newCachedThreadPool();可以自动扩容
Executors.newScheduledThreadPool(10);每隔多久执行
设置JVM参数
-server-Xmx4g-Xms4g-Xmn256m
-XX:PermSize=128m
-Xss256k
-XX:+DisableExplicitGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:+UseCMSCompactAtFullCollection
-XX:LargePageSizeInBytes=128m
?设置JVM参数，可以参考JVM优化参数
在tomcat的bin目录下的catalina.sh中设置jvm参数：
JAVA_OPTS="-server-XX:+PrintGCDetails-Xmx4g-Xms4g-Xmn256m
-XX:+UseFastAccessorMethods
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=70"
?设置tomcat的线程池大小
?设置IO模式
?配置APR
?养成良好的编程习惯
?不要重复创建太多对象
?流/文件/连接一定要记得在finally块中关闭
?少用重量级同步锁synchronized，采用Lock
?不要在循环体中使用try/catch
?多定义局部变量，少定义成员变量
修改数据库服务器的配置文件的参数，偏DBA(数据库管理员)
?将数据库服务器和应用服务器分离
?读写分离：通过数据库主从架构解决，写数据时操作主库，读数据时操作从库，分摊读写压力
?分库分表：扩容数据库，解决数据量容量问题
?建立合适的索引
?建立索引的字段尽量的小，最好是数值
?尽量在唯一性高的字段上创建索引，主键、序号等
?不要在性别这种唯一性很低的字段上创建索引
SQL优化很多，可以总结出很多经验;
solr/elasticsearch
调整配置文件参数
worker_processes16;gzipon;#开启gzip压缩输出events{worker_connections65535;#极限值65535 multi_accepton;#开启多路连接 useepoll;#使用epoll模型}13.Linux优化
优化Linux内核参数
修改/etc/sysctl.conf
机房、带宽、路由器等方面优化
网络架构更合理
运维的职责
?压缩变小
?压缩工具
?多个js合并成一个js文件，直接手动拷贝到一个文件中去，页面只加载这一个文件或者利用程序,比如controller，/aa/jspath=xxx.js,xxx.js
?多个css文件合并成一个css文件
?不要加载太多js和css
?js和css加载放在页面的尾部，从用户体验角度考虑的
?页面上减少到服务的请求数
?压测就是压力测试
?在系统上线前，需要对系统各个环节进行压力测试，发现系统的瓶颈点，然后对系统的瓶颈点，进行调优。调优完成后，还需要考虑另外一些风险因素，比如网络不稳定，机房故障等。所以我们需要提前有故障预备方案，比如多机房部署容灾、路由切换等。故障预备方案做好后，还需要提前进行演练，以确保预案的有效性
?压力测试工具：ApacheJMeter/LoadRunner等，偏测试的工作
?CTO、架构师，技术团队、测试团队、运维团队、DBA等共同完成
总结
完成以上的工作，我们才能实现一个高并发、高性能、高可用的“三高”分布式系统。