高并发经常会发生在有大活跃用户量，用户高聚集的业务场景中，如：秒杀活动，定时领取红包等。
为了让业务可以流畅的运行并且给用户一个好的交互体验，我们需要根据业务场景预估达到的并发量等因素，来设计适合自己业务场景的高并发处理方案。
服务器架构
业务从发展的初期到逐渐成熟，服务器架构也是从相对单一到集群，再到分布式服务。
一个可以支持高并发的服务少不了好的服务器架构，需要有均衡负载，数据库需要主从集群，nosql缓存需要主从集群，静态文件需要上传cdn，这些都是能让业务程序流畅运行的强大后盾。
服务器这块多是需要运维人员来配合搭建，具体我就不多说了，点到为止。
大致需要用到的服务器架构如下：
服务器
均衡负载(如：nginx，阿里云SLB)
资源监控
分布式
数据库
主从分离，集群
DBA 表优化，索引优化，等
分布式
nosql
主从分离，集群
主从分离，集群
主从分离，集群
redis
mongodb
memcache
cdn
html
css
js
image
并发测试
高并发相关的业务，需要进行并发的测试，通过大量的数据分析评估出整个架构可以支撑的并发量。
测试高并发可以使用第三方服务器或者自己测试服务器，利用测试工具进行并发请求测试，分析测试数据得到可以支撑并发数量的评估，这个可以作为一个预警参考，俗话说知己自彼百战不殆。
第三方服务：
阿里云性能测试
并发测试工具：
Apache JMeter
Visual Studio性能负载测试
Microsoft Web Application Stress Tool
实战方案
面向服务
SOA面向服务架构设计
微服务更细粒度服务化，一系列的独立的服务共同组成系统
使用服务化思维，将核心业务或者通用的业务功能抽离成服务独立部署，对外提供接口的方式提供功能。
最理想化的设计是可以把一个复杂的系统抽离成多个服务，共同组成系统的业务，优点：松耦合，高可用性，高伸缩性，易维护。
通过面向服务化设计，独立服务器部署，均衡负载，数据库集群，可以让服务支撑更高的并发
服务例子：
用户行为跟踪记录统计
说明：
通过上报应用模块，操作事件，事件对象，等数据，记录用户的操作行为
比如：记录用户在某个商品模块，点击了某一件商品，或者浏览了某一件商品
背景：
由于服务需要记录用户的各种操作行为，并且可以重复上报，准备接入服务的业务又是核心业务的用户行为跟踪，所以请求量很大，高峰期会产生大量并发请求。
架构：
nodejs WEB应用服务器均衡负载
redis主从集群
mysql主
nodejs+express+ejs+redis+mysql
服务端采用nodejs,nodejs是单进程（PM2根据cpu核数开启多个工作进程），采用事件驱动机制，适合I/O密集型业务，处理高并发能力强
业务设计：
并发量大，所以不能直接入库，采用：异步同步数据,消息队列
请求接口上报数据，接口将上报数据push到redis的list队列中
nodejs写入库脚本，循环pop redis list数据，将数据存储入库，并进行相关统计Update，无数据时sleep几秒
因为数据量会比较大，上报的数据表按天命名存储
接口：
上报数据接口
统计查询接口
上线跟进：
服务业务基本正常
每天的上报表有上千万的数据
冗余，自动化
当高并发业务所在的服务器出现宕机的时候，需要有备用服务器进行快速的替代，在应用服务器压力大的时候可以快速添加机器到集群中，所以我们就需要有备用机器可以随时待命。 最理想的方式是可以通过自动化监控服务器资源消耗来进行报警，自动切换降级方案，自动的进行服务器替换和添加操作等，通过自动化可以减少人工的操作的成本，而且可以快速操作，避免人为操作上面的失误。
冗余
数据库备份
备用服务器
自动化
自动化监控
自动化报警
自动化降级
做了备份数据并不代表就万无一失了，我们需要保证高可用性，首先备份是否正常进行，备份数据是否可用，需要我们进行定期的检查，或者自动化监控， 还有包括如何避免人为上的操作失误问题。
总结：高并发的架构适用方案有很多，在不同的业务场景下选择合适的方案是必要的。