这里我借鉴了网上其他大佬的观点：

一：
高并发带来的挑战
　　原因：秒杀抢购会经常会带来每秒几万的高并发场景，为了更快的返回结果给用户。
　　吞吐量指标QPS(每秒处理请求数)，假设一个业务请求响应耗时为100ms，我们有10台Web服务器，每台给它最大连接数500。
　　理想化计算方式:
　　10 * 500/0.1 = 50000
　　难道我们真的有处理5万并发？
　　不然。高并发场景下，Web服务器打开了越多的连接进程，CPU切换上下文的也越多。会增加CPU的压力，导致CPU业务请求响应耗时 会超出预期很多。可能你的系统只能承受2万的并发了。
　　这个时候我们需要怎么做？

　　答：1、请求的接口需要设计合理，怎么做？
　　　　动静分离，静态HTML可以通过Ng部署。
　　　　核心瓶颈在后台接口上，高并发情况下存储压力大，MySQL不合适，用Redis内存读写快。
　　　　2、重启与过载保护
　　　　如果你2万的并发硬抗3万流量，导致服务器没有连接进程可用，系统就要陷入异常状态了，响应时间极慢。当系统响应时间很久 ，有些用户越喜欢频繁点击。恶性循环导致“雪崩”，导致整个系统垮掉，就算重启服务也无济于事。
　　　　怎么做？
　　　　过载保护，如果检测到系统满载状态，拒绝请求自我保护。
　　　　(1)前端过滤简单方式
　　　　(2)过载保护设置在CGI入口层，将客户端的请求直接返回

二：
高并发下的数据安全
　　多线程写入同一个文件的时候，会出现“线程安全问题”。高并发的数据安全就是这个道理。比如有可能会出现超发。
　　方案：
　　悲观锁思路：修改数据时，锁定状态，排斥外部请求的修改。
　　缺点：
　　高并发下某些线程可能永远都抢不到这个“锁”，请求就会死在那里。堆积到一定程度，连接数被耗尽，系统异常。
　　FIFO队列思路：请求都排好队，不会导致某些请求永远拿不到锁。
　　缺点：
　　高并发可能导致队列内存“撑爆”，如果设置一个极大的内存队列，系统处理请求的速度根本跟不上不断快速涌入的请求。越积 越多，还是会导致响应变慢，系统陷入异常。
　　乐观锁思路：
　　跟悲观锁相比，乐观锁都有资格去执行请求，但会获得一个版本号，符合版本号的才算更新成功。
　　缺点：
　　加大计算机CPU计算的开销，但是这是一个比较好的解决方案。
　　缓存服务器思路：
　　Redis分布式要保证数据都能能够平均的缓存到每一台机器，首先想到的做法是对数据进行分片，因为Redis是key-value存储的， 首先想到的是Hash分片，可能的做法是对key进行哈希运算，得到一 个             long值对分布式的数量取模会得到一个一个对应数据库的一 个映射，没有读取就可以定位到这台数据库

三：
高并发下的水分与查杀。
　　原因：秒杀或是抢购等海量请求有时候并不是真正的用户在发送请求，有些为了“抢”到商品会使用一些“刷票”等类似的工具。这种做 法是帮助他们发送更多的请求到服务器。更高级的还制作一些自动请求            脚本。这些做法都是使自己的请求数占比多，成功率高。
        这些很显然都是属于作弊行为，不过，我们也有一些解决方案。
　　答：分为以下几种情况
　　1、同一个账号，一次性发送多个请求。
　　高并发有可能会导致跳过某些逻辑判断。
　　方案：程序入口处，一个用户只允许一次请求，其他过滤。可以通过Redis内存缓存服务，写入一个标志位(只允许一个请求成功 ，结合watch乐观锁的特性)
　　2、多个账号，一次性发送多个请求
　　很多早期注册功能没有限制，导致一些特殊的工作室通过编写自动注册脚本注册一大批“僵尸账号”。专门做各种刷的行为，以 及一些转发抽奖活动，大大提升自己中奖的概率。
　　方案：检测指定机器IP请求频率，如果一个IP的请求频率异常的高。给它弹出一个验证码或者禁止它的请求。
　　3、多个账号，不同IP发送不同请求
　　有一些机构自己独占一批IP，然后做成一个随机代理IP的服务，有偿提供给这些“工作室”使用。还有一些直接黑掉用户电脑， 转发IP包，使普通用户的电脑变成IP代理出口。
　　方案：难以分辨了，容易“误伤”。可以通过高门槛的业务，或者通过“数据挖掘”来提前清理。

个人整理并发解决方案。

a.应用层面：读写分离、缓存、队列、集群、令牌、系统拆分、隔离、系统升级（可水平扩容方向）。

b.时间换空间：降低单次请求时间，这样在单位时间内系统并发就会提升。

c.空间换时间：拉长整体处理业务时间，换取后台系统容量空间。