Java高并发解决方案 高并发解决思路与手段

知识点

线程安全，线程封闭，线程调度，同步容器，并发容器，AQS，J.U.C，等等

高并发解决思路与手段

扩容：水平扩容、垂直扩容

缓存：Redis、Memcache、GuavaCache等

队列：Kafka、RabitMQ、RocketMQ等

应用拆分：服务化Dubbo与微服务Spring Cloud

限流：Guava RateLimiter使用、常用限流算法、自己实现分布式限流等

服务降级与服务熔断：服务降级的多重选择、Hystrix

数据库切库，分库分表：切库、分表、多数据源

高可用的一些手段：任务调度分布式elastic-job、主备curator的实现、监控报警机制

基础知识与核心知识准备

并发高并发相关概念

cpu多级缓存：缓存一致，乱序执行优化

java内存模型：JMM规定，抽象结构，同步操作与规则

并发优势与风险

并发模拟：Postman，Jmeter，Apache Bench，代码

并发基本概念

同时拥有两个或多个线程，如果程序在单核处理器上运行，多个线程将交替的换入或者换出内存，这些线程是同时“存在”的，每个线程都处于执行过程中的某个状态，如果运行在多核处理器上，此时，程序中的每个线程都将分配到一个处理器核上，因此可以同时运行。

高并发基本概念

高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。

并发：多个线程操作相同的资源，保证线程安全，合理使用资源

高并发：服务能同时处理很多请求，提高程序性能（更多的考虑技术手段）

知识技能

总体架构：Spring Boot、Maven、JDK8、MySQL

基础组件：Mybatis、Guava、Lombok、Redis、Kafka

高级组件：Joda-Time、Atomic包、J.U.C、AQS、ThreadLocal、RateLimiter、Hystrix、ThreadPool、Shardbatis、curator、elastic-job等

基础知识

cpu多级缓存

主存和cpu通过主线连接，CPU缓存在主存和CPU之间，缓存的出现可以减少CPU读取共享主存的次数

为什么需要CPU cache：CPU的频率太快了，快到主存跟不上，这样在处理器时钟周期内，CPU常常需要等待主存，浪费资源。所以cache的出现，是为了缓解CPU和内存之间速度不匹配问题（结构：cpu -> cache -> memery）.

CPU cache有什么意义：

1）时间局部性：如果某个数据被访问，name在不久的将来它很可能被再次访问。

2）空间局部性：如果某个数据被访问，那么与它相邻的数据很快也可能被访问

CPU多级缓存-缓存一致性（MESI）

MESI分别代表cache数据的四种状态，这四种状态可以相互转换

缓存四种操作：local read、local write、remote read、remote write

CPU多级缓存-乱序执行优化

在多核处理器上回出现问题

java内存模型（java memory model，JMM）

java内存模型-同步八种操作

lock（锁定）：作用于主内存的变量，把一个变量标识为一条线程独占状态

unlock（解锁）：作用于主内存变脸个，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定

read（读取）：作用于主内存变量，把一个变量值从主内存传输到线程的工作内存中，以便随后的load动作使用

load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中

use（使用）：作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎

assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋值给工作内存的变量

store（存储）：作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以遍随后的write的操作

write（写入）：作用于主内存的变量，它把store操作从工作内存中的一个变量的值传送到主内存的变量中

java内存模型-同步规则

1. 如果要把一个变量从主内存中复制到工作内存，就需要按顺序的执行read和load操作，如果把变量从工作内存中同步回主内存，就需要按顺序的执行store和write操作。但java内存模型只要求上述操作必须按顺序执行，而没有保证必须是连续执行
2. 不允许read和load、store和write操作之一单独出现
3. 不允许一个线程丢弃它的最近assign的操作，即变量在工作内存中改变了之后必须同步到主内存中
4. 不允许一个线程无原因的（没发生过任何assign操作）把数据从工作内存同步回主内存中
5. 一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量。即就是对一个变量实施use和store操作之前，必须先执行过了assign和load操作
6. 一个变量在同一时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。lock和unlock必须成对出现
7. 如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量之前需要重新执行load或assign操作初始化变量的值
8. 如果一个变量实现没有被lock操作锁定，怎不允许对它执行unlock操作，也不允许去unlock一个被其他线程锁定的变量
9. 对一个变量执行unlock操作之前，必须先把此变量同步到主内存中（执行store和write操作）

并发的优势与风险

优势

速度：同时处理多个请求，响应更快；复杂的操作可以分成多个进程同时进行

设计：程序设计在某些情况下更简单，也可以更多的选择

资源利用：CPU能够在等待IO的时候做一些其他的事情

风险

安全性：多个线程共享数据时可能会产生于期望不相符的结果

活跃性：某个操作无法继续进行下去时，就会发生活跃性问题。比如死锁、饥饿等问题

性能：线程过多时会使得CPU频繁切换，调度时间增多；同步机制；消耗过多内存

 

线程安全性

定义：当多个线程访问某个类时，不管运行时环境采用何种调度方式或者这些线程将如何交替执行，并且在主调代码中不需要任何额外的同步或协同，这个类都能表现出正确的行为，那么就称这个类时线程安全的。

线程安全体现在以下三个方面

原子性：提供了互斥访问，同一时刻只能有一个线程来对他进行操作

可见性：一个线程对主内存的修改可以及时的被其他线程观察到

有序性：一个线程观察其他线程中的指令执行顺序，由于指令重排序的存在，该观察结果一般杂乱无序

原子性——Atomic包

AtomicXxxx：CAS、Unsafe.compareAndSwapInt

AtomicXxxx类中方法incrementAndGet()，incrementAndGet方法中调用unsafe.getAndAddInt()，getAndAddInt方法中主题是do-while语句，while语句中调用compareAndSwapInt(var1, var2, var5, var5 + var4)

compareAndSwapInt方法就是CAS核心：

在死循环内，不断尝试修改目标值，直到修改成功，如果竞争不激烈，修改成功率很高，否则失败概率很高，性能会受到影响

jdk8中新增LongAdder，它和AtomicLong比较

优点：性能好，在处理高并发情况下统计优先使用LongAdder

AtomicReference、AtomicReferenceFieldUpdater原子性更新字段（字段要求volatile修饰，并且是非static）

AtomicStampReference：CAS的ABA问题

ABA问题：变量已经被修改了，但是最终的值和原来的一样，那么如何区分是否被修改过呢，用版本号解决

AtomicBoolean可以让某些代码只执行一次

原子性——锁

synchronized：依赖jvm，作用对象的作用范围内

修饰代码块：同步代码块，大括号括起来的代码，作用于调用的对象

修饰方法：同步方法，整个方法，作用于调用的对象

修饰静态方法：整个静态方法，作用于所有对象

修饰类：括号括起来的部分，作用于所有对象

Lock：依赖特殊CPU指令，代码实现，ReentrantLock

原子性——对比

synchronized：不可中断锁，适合竞争不激烈，可读性好

Lock：可中断锁，多样化同步，竞争激烈时能维持常态

Atomic：竞争激烈时能维持常态，比Lock性能好，只能同步一个值

可见性

导致共享变量在线程间不可见的原因：

1 线程交叉执行

2 重排序结合线程交叉执行

3 共享变量更新后的值没有在工作内存与主内存间及时更新

可见性——synchronized

JMM关于synchronized的两条规定：

线程解锁前，必须把共享变量的最新值刷新到主内存

线程加锁时，将清空工作内存中共享变量的值，从而使用共享变量时需要从主内存中重新读取最新的值（注意，加锁和解锁是同一把锁）

可见性——volatile

通过加入内存屏障和禁止重排序优化来实现

1 对volatile变量写操作时，会在写操作后加入一条store屏障指令，将本地内存中的共享变量值刷新到主内存

2 随volatile变量度操作时，会在读操作前加入一条load屏障指令，从主内存中读取共享变量

使用volatile修饰变量，无法保证线程安全

volatile适合修饰状态标识量

有序性

java内存模型中，允许编译器和处理器对指令进行重排序，但是重排序过程不会影响到单线程程序的执行，却会影响到多线程并发执行的正确性

有序性——happens-before原则

1 程序次序规则：一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作

注：在单线程中，看起来是这样的，虚拟机可能会对代码进行指令重排序，虽然重排序了，但是运行结果在单线程中和指令书写顺序是一致的，事实上，这条规则是用来保证程序单在单线程中执行结果的正确性，无法保证程序在多线程中的正确性

2 锁定规则：一个unlock操作先行发生于后面对同一个锁的lock操作

3 volatile变量规则：对一个变量的写操作先行发生于后面对这个变量的读操作

4 传递规则：如果操作A先行发生于操作B，而操作B又先行发生于操作C，则可以得出操作A先行发生于操作C

前四条规则比较重要

5 线程启动规则：Thread对象的start()方法先行发生于次线程的每一个动作

6 线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码监测到中断事件的发生

7 线程终结规则：线程中所有的操作都先行发生于线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行

8 对象终结规则：一个对象的初始化完成先行发生于他的finalize()方法的开始

线程安全性——总结

原子性：Atomic包、CAS算法、synchronized、Lock

可见性：synchronized、volatile

有序性：happens-before规则

一个线程观察其他线程指令执行顺序，由于重排序的存在，观察结果一般是无序的，如果两个操作执行顺序无法从happens-before原则推导出来，name他们就不能保证有序性，虚拟机可以随意的对他们重排序

发布对象

发布对象：使一个对象能够被当前范围之外的代码所使用

对象逸出：一种错误的发布。当一个对象还没有构造完成时，就使它被其他线程所见

安全发布对象四种方法

1 在静态初始化函数中初始化一个对象引用

2 将对象的引用保存到volatile类型域或者AtomicReference对象中

3 将对象的引用保存到某个正确构造对象的final类型域中

4 将对象的引用保存到一个由锁保护的域中

私有构造函数，单例对象，静态工厂方法获取对象

以单例模式为例

懒汉模式：单例实例在第一次使用时进行创建（线程不安全）

懒汉模式也可以实现线程安全，给getInstance方法添加synchronized关键字（不推荐，因为性能不好）

双重同步锁单例模式：双重监测机制，在方法内部加synchronized关键字（不是线程安全的）

原因是，创建对象是，分为以下三个步骤：

1） memory = allocate() 分配对象的内存空间

2）ctorInstance() 初始化对象

3）instance = memory() 设置instance指向刚分配的内存

由于JVM和cpu优化，可能会发生指令重排：

1） memory = allocate() 分配对象的内存空间

3） instance = memory() 设置instance指向刚分配的内存

2） ctorInstance() 初始化对象

当以上面这种指令执行时，线程A执行到3 instance = memory() 设置instance指向刚分配的内存 这一步时，线程B执行if(instance == null)这段代码，此时instance ！= null，线程B直接return instance，导致对象没有初始化完毕就返回

解决办法就是限制对象创建时进行指令重排，volatile+双重监测机制->禁止指令重排引起非线程安全

饿汉模式：单例实例在类装载时进行创建（线程安全）

枚举模式：线程安全

不可变对象

不可变对象需要满足的条件：

对象创建以后其状态就不能修改

对象所有域都是final类型

对象是正确创建的（在对象创建期间，this引用没有逸出）

参考String类型

final关键字定义不可变对象

修饰类、方法、变量

修饰类：不能被继承

修饰方法：1.锁定方法不被继承类修改 2.效率

修饰变量：基本数据类型，数值不可变；引用类型变量，不能再指向另外一个对象，因此容易引起线程安全问题

其他实现不可变对象

Collections.unmodifiableXXX：Collection、List、Set、Map（线程安全）

Guava：ImmutableXXX：Collection、List、Set、Map

线程封闭性

线程封闭概念：把对象封装到一个线程里，只有这个线程可以看到该对象，那么就算该对象不是线程安全的，也不会出现任何线程安全方面的问题。实现线程封闭的方法：

1 Ad-hoc线程封闭：程序控制实现，最糟糕，忽略

2 堆栈封闭：局部变量，无并发问题

3 threadLocal是线程安全的，做到了线程封闭

ThreadLocal内部维护了一个map，map的key是每个线程的名称，map的值是要封闭的对象，每一个线程中的对象都对应者一个map中的值

线程封闭的应用场景：

数据库连接jdbc的Connection对象

线程不安全类与写法

字符串

StringBuilder：线程不安全

StringBuffer：线程安全

时间转换

SimpleDateFormat：线程不安全

JodaTime：线程安全

集合

ArrayList：线程不安全

HashSet：线程不安全

HashMap：线程不安全

编程注意：

if(condition(a)){handle(a)}; 不是线程安全的，因为这条判断语句不是原子性的，如果有线程共享这条代码，则会出现并发问题，解决方案是想办法这这段代码是原子性的（加锁）

线程安全——同步容器（在多线程环境下不推荐使用）

ArrayList -> Vector, Stack

Vector中的方法使用synchronized修饰过

Stack继承Vector

HashMap -> HashTable(key、value不能为null)

HashTable使用synchronized修饰方法

Collections.synchronizedXXX（List、Set、Map）

同步容器不完全是线程安全的

编程注意：如果使用foreach或者iterator遍历集合时，尽量不要对集合进行修改操作

线程安全——并发容器J.U.C（java.util.concurrent）（在多线程环境下推荐使用）

ArrayList -> CopyOnWriteArrayList：相比ArrayList，CopyOnWriteArrayList是线程安全的，写操作时复制，即当有新元素添加到CopyOnWriteArrayList时，先从原有的数组里拷贝一份出来，然后在新的数组上写操作，写完之后再将原来的数组指向新的数组，CopyOnWriteArrayList整个操作都是在锁（ReentrantLock锁）的保护下进行的，这么做主要是避免在多线程并发做add操作时复制出多个副本出来，把数据搞乱了。第一个缺点是做写操作时，需要拷贝数组，就会消耗内存，如果元素内容比较多会导致youngGC或者是fullGc；第二个缺点是不能用于实时读的场景，比如拷贝数组、新增元素都需要时间，所以调用一个set操作后，读取到的数据可能还是旧的，虽然CopyOnWriteArrayList能够做到最终的一致性，但是没法满足实时性要求，因此CopyOnWriteArrayList更适合读多写少的场景

CopyOnWriteArrayList设计思想：1读写分离 2最终一致性 3使用时另外开辟空间解决并发冲突

HashSet -> CopyOnWriteArraySet

TreeSet -> ConcurrentSkipListSet

CopyOnWriteArraySet：底层实现是CopyOnWriteArrayList

ConcurrentSkipListSet：和TreeSet 一样支持自然排序，基于map集合，但是批量操作不是线程安全的

HashMap -> ConcurrentHashMap ：不允许空值，针对读操作做了大量的优化，具有特别高的并发性

TreeMap  -> ConcurrentSkipListMap ：内部使用SkipList跳表结构实现的，key是有序的，支持更高的并发

安全共享对象策略——总结

1 线程限制：一个呗线程限制的对象，由线程独占，并且只能被占有它的线程修改

2 共享只读：一个共享只读的对象，在没有额外的同步情况下，可以被多个线程并发访问，但是任何线程都不能修改它

3 线程安全对象：一个线程安全的对象或容器，在内部通过同步机制来保证线程安全，所以其他线程无序额外的同步就可以通过公共接口随意访问它

4 被守护对象：被守护对象只能通过获取特定的锁来访问

不可变对象、线程封闭、同步容器、并发容器

J.U.C之AQS

AQS：AbstractQueuedSynchronizer

1 使用Node实现FIFO队列，可以用于构建锁或者其他同步装置的基础框架

2 利用了int类型表示状态

3 使用方法是继承

4 子类通过继承并通过实现它的方法管理器状态{acquire和release}的方法操纵状态

5 可以同时实现排它锁和共享锁模式（独占、共享）

AQS同步组件

1 CountDownLatch：闭锁，通过计数来保证线程是否需要一直阻塞

2 Semaphore：控制同一时间并发线程的数目

3 CyclicBarrier：和CountDownLatch相似，都能阻阻塞线程

4 ReentrantLock

5 Condition

6 FutureTask

CountDownLatch

CountDownLatch是一个同步辅助类，应用场景：并行运算，所有线程执行完毕才可执行

 

 

电商的秒杀和抢购，对我们来说，都不是一个陌生的东西。然而，从技术的角度来说，这对于Web系统是一个巨大的考验。当一个Web系统，在一秒钟内收到数以万计甚至更多请求时，系统的优化和稳定至关重要。这次我们会关注秒杀和抢购的技术实现和优化，同时，从技术层面揭开，为什么我们总是不容易抢到火车票的原因？

一、大规模并发带来的挑战

在过去的工作中，我曾经面对过5w每秒的高并发秒杀功能，在这个过程中，整个Web系统遇到了很多的问题和挑战。如果Web系统不做针对性的优化，会轻而易举地陷入到异常状态。我们现在一起来讨论下，优化的思路和方法哈。

1.请求接口的合理设计

一个秒杀或者抢购页面，通常分为2个部分，一个是静态的HTML等内容，另一个就是参与秒杀的Web后台请求接口。

通常静态HTML等内容，是通过CDN的部署，一般压力不大，核心瓶颈实际上在后台请求接口上。这个后端接口，必须能够支持高并发请求，同时，非常重要的一点，必须尽可能“快”，在最短的时间里返回用户的请求结果。为了实现尽可能快这一点，接口的后端存储使用内存级别的操作会更好一点。仍然直接面向MySQL之类的存储是不合适的，如果有这种复杂业务的需求，都建议采用异步写入。

当然，也有一些秒杀和抢购采用“滞后反馈”，就是说秒杀当下不知道结果，一段时间后才可以从页面中看到用户是否秒杀成功。但是，这种属于“偷懒”行为，同时给用户的体验也不好，容易被用户认为是“暗箱操作”。

2.高并发的挑战：一定要“快”

我们通常衡量一个Web系统的吞吐率的指标是QPS（Query Per Second，每秒处理请求数），解决每秒数万次的高并发场景，这个指标非常关键。举个例子，我们假设处理一个业务请求平均响应时间为100ms，同时，系统内有20台Apache的Web服务器，配置MaxClients为500个（表示Apache的最大连接数目）。

那么，我们的Web系统的理论峰值QPS为（理想化的计算方式）：

20*500/0.1 = 100000 （10万QPS）

咦？我们的系统似乎很强大，1秒钟可以处理完10万的请求，5w/s的秒杀似乎是“纸老虎”哈。实际情况，当然没有这么理想。在高并发的实际场景下，机器都处于高负载的状态，在这个时候平均响应时间会被大大增加。

就Web服务器而言，Apache打开了越多的连接进程，CPU需要处理的上下文切换也越多，额外增加了CPU的消耗，然后就直接导致平均响应时间增加。因此上述的MaxClient数目，要根据CPU、内存等硬件因素综合考虑，绝对不是越多越好。可以通过Apache自带的abench来测试一下，取一个合适的值。然后，我们选择内存操作级别的存储的Redis，在高并发的状态下，存储的响应时间至关重要。网络带宽虽然也是一个因素，不过，这种请求数据包一般比较小，一般很少成为请求的瓶颈。负载均衡成为系统瓶颈的情况比较少，在这里不做讨论哈。

那么问题来了，假设我们的系统，在5w/s的高并发状态下，平均响应时间从100ms变为250ms（实际情况，甚至更多）：

20*500/0.25 = 40000 （4万QPS）

于是，我们的系统剩下了4w的QPS，面对5w每秒的请求，中间相差了1w。

然后，这才是真正的恶梦开始。举个例子，高速路口，1秒钟来5部车，每秒通过5部车，高速路口运作正常。突然，这个路口1秒钟只能通过4部车，车流量仍然依旧，结果必定出现大塞车。（5条车道忽然变成4条车道的感觉）

同理，某一个秒内，20*500个可用连接进程都在满负荷工作中，却仍然有1万个新来请求，没有连接进程可用，系统陷入到异常状态也是预期之内。

其实在正常的非高并发的业务场景中，也有类似的情况出现，某个业务请求接口出现问题，响应时间极慢，将整个Web请求响应时间拉得很长，逐渐将Web服务器的可用连接数占满，其他正常的业务请求，无连接进程可用。

更可怕的问题是，是用户的行为特点，系统越是不可用，用户的点击越频繁，恶性循环最终导致“雪崩”（其中一台Web机器挂了，导致流量分散到其他正常工作的机器上，再导致正常的机器也挂，然后恶性循环），将整个Web系统拖垮。

3.重启与过载保护

如果系统发生“雪崩”，贸然重启服务，是无法解决问题的。最常见的现象是，启动起来后，立刻挂掉。这个时候，最好在入口层将流量拒绝，然后再将重启。如果是redis/memcache这种服务也挂了，重启的时候需要注意“预热”，并且很可能需要比较长的时间。

秒杀和抢购的场景，流量往往是超乎我们系统的准备和想象的。这个时候，过载保护是必要的。如果检测到系统满负载状态，拒绝请求也是一种保护措施。在前端设置过滤是最简单的方式，但是，这种做法是被用户“千夫所指”的行为。更合适一点的是，将过载保护设置在CGI入口层，快速将客户的直接请求返回。

二、作弊的手段：进攻与防守

秒杀和抢购收到了“海量”的请求，实际上里面的水分是很大的。不少用户，为了“抢“到商品，会使用“刷票工具”等类型的辅助工具，帮助他们发送尽可能多的请求到服务器。还有一部分高级用户，制作强大的自动请求脚本。这种做法的理由也很简单，就是在参与秒杀和抢购的请求中，自己的请求数目占比越多，成功的概率越高。

这些都是属于“作弊的手段”，不过，有“进攻”就有“防守”，这是一场没有硝烟的战斗哈。

1.同一个账号，一次性发出多个请求

部分用户通过浏览器的插件或者其他工具，在秒杀开始的时间里，以自己的账号，一次发送上百甚至更多的请求。实际上，这样的用户破坏了秒杀和抢购的公平性。

这种请求在某些没有做数据安全处理的系统里，也可能造成另外一种破坏，导致某些判断条件被绕过。例如一个简单的领取逻辑，先判断用户是否有参与记录，如果没有则领取成功，最后写入到参与记录中。这是个非常简单的逻辑，但是，在高并发的场景下，存在深深的漏洞。多个并发请求通过负载均衡服务器，分配到内网的多台Web服务器，它们首先向存储发送查询请求，然后，在某个请求成功写入参与记录的时间差内，其他的请求获查询到的结果都是“没有参与记录”。这里，就存在逻辑判断被绕过的风险。

应对方案：

在程序入口处，一个账号只允许接受1个请求，其他请求过滤。不仅解决了同一个账号，发送N个请求的问题，还保证了后续的逻辑流程的安全。实现方案，可以通过Redis这种内存缓存服务，写入一个标志位（只允许1个请求写成功，结合watch的乐观锁的特性），成功写入的则可以继续参加。

或者，自己实现一个服务，将同一个账号的请求放入一个队列中，处理完一个，再处理下一个。

2.多个账号，一次性发送多个请求

很多公司的账号注册功能，在发展早期几乎是没有限制的，很容易就可以注册很多个账号。因此，也导致了出现了一些特殊的工作室，通过编写自动注册脚本，积累了一大批“僵尸账号”，数量庞大，几万甚至几十万的账号不等，专门做各种刷的行为（这就是微博中的“僵尸粉“的来源）。举个例子，例如微博中有转发抽奖的活动，如果我们使用几万个“僵尸号”去混进去转发，这样就可以大大提升我们中奖的概率。

这种账号，使用在秒杀和抢购里，也是同一个道理。例如，iPhone官网的抢购，火车票黄牛党。

应对方案：

这种场景，可以通过检测指定机器IP请求频率就可以解决，如果发现某个IP请求频率很高，可以给它弹出一个验证码或者直接禁止它的请求：

弹出验证码，最核心的追求，就是分辨出真实用户。因此，大家可能经常发现，网站弹出的验证码，有些是“鬼神乱舞”的样子，有时让我们根本无法看清。他们这样做的原因，其实也是为了让验证码的图片不被轻易识别，因为强大的“自动脚本”可以通过图片识别里面的字符，然后让脚本自动填写验证码。实际上，有一些非常创新的验证码，效果会比较好，例如给你一个简单问题让你回答，或者让你完成某些简单操作（例如百度贴吧的验证码）。
直接禁止IP，实际上是有些粗暴的，因为有些真实用户的网络场景恰好是同一出口IP的，可能会有“误伤“。但是这一个做法简单高效，根据实际场景使用可以获得很好的效果。

3.多个账号，不同IP发送不同请求

所谓道高一尺，魔高一丈。有进攻，就会有防守，永不休止。这些“工作室”，发现你对单机IP请求频率有控制之后，他们也针对这种场景，想出了他们的“新进攻方案”，就是不断改变IP。

有同学会好奇，这些随机IP服务怎么来的。有一些是某些机构自己占据一批独立IP，然后做成一个随机代理IP的服务，有偿提供给这些“工作室”使用。还有一些更为黑暗一点的，就是通过木马黑掉普通用户的电脑，这个木马也不破坏用户电脑的正常运作，只做一件事情，就是转发IP包，普通用户的电脑被变成了IP代理出口。通过这种做法，黑客就拿到了大量的独立IP，然后搭建为随机IP服务，就是为了挣钱。

应对方案：

说实话，这种场景下的请求，和真实用户的行为，已经基本相同了，想做分辨很困难。再做进一步的限制很容易“误伤“真实用户，这个时候，通常只能通过设置业务门槛高来限制这种请求了，或者通过账号行为的”数据挖掘“来提前清理掉它们。

僵尸账号也还是有一些共同特征的，例如账号很可能属于同一个号码段甚至是连号的，活跃度不高，等级低，资料不全等等。根据这些特点，适当设置参与门槛，例如限制参与秒杀的账号等级。通过这些业务手段，也是可以过滤掉一些僵尸号。

4.火车票的抢购

看到这里，同学们是否明白你为什么抢不到火车票？如果你只是老老实实地去抢票，真的很难。通过多账号的方式，火车票的黄牛将很多车票的名额占据，部分强大的黄牛，在处理验证码方面，更是“技高一筹“。

高级的黄牛刷票时，在识别验证码的时候使用真实的人，中间搭建一个展示验证码图片的中转软件服务，真人浏览图片并填写下真实验证码，返回给中转软件。对于这种方式，验证码的保护限制作用被废除了，目前也没有很好的解决方案。

因为火车票是根据身份证实名制的，这里还有一个火车票的转让操作方式。大致的操作方式，是先用买家的身份证开启一个抢票工具，持续发送请求，黄牛账号选择退票，然后黄牛买家成功通过自己的身份证购票成功。当一列车厢没有票了的时候，是没有很多人盯着看的，况且黄牛们的抢票工具也很强大，即使让我们看见有退票，我们也不一定能抢得过他们哈。

最终，黄牛顺利将火车票转移到买家的身份证下。

解决方案：

并没有很好的解决方案，唯一可以动心思的也许是对账号数据进行“数据挖掘”，这些黄牛账号也是有一些共同特征的，例如经常抢票和退票，节假日异常活跃等等。将它们分析出来，再做进一步处理和甄别。

三、高并发下的数据安全

我们知道在多线程写入同一个文件的时候，会存现“线程安全”的问题（多个线程同时运行同一段代码，如果每次运行结果和单线程运行的结果是一样的，结果和预期相同，就是线程安全的）。如果是MySQL数据库，可以使用它自带的锁机制很好的解决问题，但是，在大规模并发的场景中，是不推荐使用MySQL的。秒杀和抢购的场景中，还有另外一个问题，就是“超发”，如果在这方面控制不慎，会产生发送过多的情况。我们也曾经听说过，某些电商搞抢购活动，买家成功拍下后，商家却不承认订单有效，拒绝发货。这里的问题，也许并不一定是商家奸诈，而是系统技术层面存在超发风险导致的。

1.超发的原因

假设某个抢购场景中，我们一共只有100个商品，在最后一刻，我们已经消耗了99个商品，仅剩最后一个。这个时候，系统发来多个并发请求，这批请求读取到的商品余量都是99个，然后都通过了这一个余量判断，最终导致超发。（同文章前面说的场景）

在上面的这个图中，就导致了并发用户B也“抢购成功”，多让一个人获得了商品。这种场景，在高并发的情况下非常容易出现。

2.悲观锁思路

解决线程安全的思路很多，可以从“悲观锁”的方向开始讨论。

悲观锁，也就是在修改数据的时候，采用锁定状态，排斥外部请求的修改。遇到加锁的状态，就必须等待。

虽然上述的方案的确解决了线程安全的问题，但是，别忘记，我们的场景是“高并发”。也就是说，会很多这样的修改请求，每个请求都需要等待“锁”，某些线程可能永远都没有机会抢到这个“锁”，这种请求就会死在那里。同时，这种请求会很多，瞬间增大系统的平均响应时间，结果是可用连接数被耗尽，系统陷入异常。

3.FIFO队列思路

那好，那么我们稍微修改一下上面的场景，我们直接将请求放入队列中的，采用FIFO（First Input First Output，先进先出），这样的话，我们就不会导致某些请求永远获取不到锁。看到这里，是不是有点强行将多线程变成单线程的感觉哈。

然后，我们现在解决了锁的问题，全部请求采用“先进先出”的队列方式来处理。那么新的问题来了，高并发的场景下，因为请求很多，很可能一瞬间将队列内存“撑爆”，然后系统又陷入到了异常状态。或者设计一个极大的内存队列，也是一种方案，但是，系统处理完一个队列内请求的速度根本无法和疯狂涌入队列中的数目相比。也就是说，队列内的请求会越积累越多，最终Web系统平均响应时候还是会大幅下降，系统还是陷入异常。

4.乐观锁思路

这个时候，我们就可以讨论一下“乐观锁”的思路了。乐观锁，是相对于“悲观锁”采用更为宽松的加锁机制，大都是采用带版本号（Version）更新。实现就是，这个数据所有请求都有资格去修改，但会获得一个该数据的版本号，只有版本号符合的才能更新成功，其他的返回抢购失败。这样的话，我们就不需要考虑队列的问题，不过，它会增大CPU的计算开销。但是，综合来说，这是一个比较好的解决方案。

5.缓存服务器

Redis分布式要保证数据都能能够平均的缓存到每一台机器，首先想到的做法是对数据进行分片，因为Redis是key-value存储的，首先想到的是Hash分片，可能的做法是对key进行哈希运算，得到一个long值对分布式的数量取模会得到一个一个对应数据库的一个映射，没有读取就可以定位到这台数据库

有很多软件和服务都“乐观锁”功能的支持，例如Redis中的watch就是其中之一。通过这个实现，我们保证了数据的安全。

四、小结

互联网正在高速发展，使用互联网服务的用户越多，高并发的场景也变得越来越多。电商秒杀和抢购，是两个比较典型的互联网高并发场景。虽然我们解决问题的具体技术方案可能千差万别，但是遇到的挑战却是相似的，因此解决问题的思路也异曲同工。

个人整理并发解决方案。

a.应用层面：读写分离、缓存、队列、集群、令牌、系统拆分、隔离、系统升级（可水平扩容方向）。
b.时间换空间：降低单次请求时间，这样在单位时间内系统并发就会提升。
c.空间换时间：拉长整体处理业务时间，换取后台系统容量空间。