最近看了很多高并发的解决方案，高并发并没有通用的解决方案，也不会有现成的demo或者源码可以参考，我在这方面也没有什么经验
但是从我看到很多深度不高的文章来说，可以总结出一些可以真正落地的解决办法
1.入口流量分发，软件硬件分发
常见的nginx代理负载均衡，lvs虚拟ip流量分发，以及F5硬件负载均衡
nginx负载均衡实际上是使用http代理来实现的，流量是先进入nginx服务器，然后请求后方应用服务器，应用服务器返回数据给nginx，nginx再输出给用户
nginx负载均衡效果大部分取决于nginx服务器的性能，一般能应付一万左右并发量
lvs 除了DR模式性能比较好之外，其他模式性能并没很大提高，其主要实现原理是修改请求报文（网络4层）中的mac地址，将请求发送到真实服务器
lvs 与RS服务器必须在同一个网段内才能实现最好的效果，并且无法感知RS服务器是否正常访问
通常使用lvs负载到nginx服务器，nginx服务器能获取应用的可用状态，从而实现高可用
2.页面静态化，前端CDN缓存
对于一些更新不是很频繁的页面，可用通过运维人员设置的定期计划任务，生成静态页面，然后提交到nginx服务器上，让nginx去处理静态请求
前端js，css，images等资源打包，实现前后端分离，并按照hash定义为版本号，放置到cdn缓存服务器上，加快处理与响应速度，减少应用服务器负担
3.服务切分，应用集群
将业务拆分成多个服务，并按照服务的负载量来伸缩部署应用，负载高的就部署多一些，在特殊情况下，可用关闭一些不重要的服务来维持主要业务的处理
4.消息队列，任务队列
应对突发高并发情况，任务不能立即处理完成，此时建立消息队列，有专门的服务处理这些队列，完成后再通知应用服务器，应用服务器再返回结果给用户
5.流量限制与服务降级
在队列超过一定数量，请求量超过服务器处理能力的情况下，给用户返回 失败/预设内容/缓存信息/引导到上级页面，从而保证业务的正常运行
6.应用自身缓存，分布式缓存
对于频繁操作的数据，或者计算量大的数据，可用将数据存放到缓存中
有些场景可以牺牲数据一致性，数据优先读写缓存，然后再由定期计划任务去更新到数据库，新浪微博的点赞就是这种解决方案
7.数据库分表分库，读写分离
根据业务或者数据量，将数据库拆分成多个表和多个库，按照 数据量/数据id/用户id 来将数据存储到具体的库与表中
读取的时候从多个表和数据库里面获取数据，然后合并到一起返回
数据库按照读写分离为主库和从库，主库主要负责数据更新写入，从库负责同步数据和读取数据，对读多写少的场景效果比较好
从库同步是需要时间的，并不能写入后马上读取从库，解决方法目前我也想了一些，不过并不成熟