验证码的校验原理其实很简单：

而我们下面要探讨的是，在不同场景下，处理校验码的一些方案；主要包括验证码存在哪里、由谁来校验、怎么校验这几个方面。

相信大家都有了解session的原理，客户端访问服务器后，服务端给客户端返回一个叫JSessionId的cookie，服务器可以根据这个值来标识本次会话。单台服务器下，session是一个不错的验证码存储的地方，我们不用担心各个会话间的验证码存在冲突。 以 用户登录+图片验证码+session 为例，其流程主要为：

用户登录+图片验证码+session

这里code_key可以理解成JSessionId+session.attribute中的key（这里是"code"）

当单个服务（如用户中心）使用多台服务器部署后，因为需要做负载均衡，一般情况下（暂不考虑IP-hash那样的策略），用户每次发起的请求有可能会去到不同的服务器，这时候session就会失效了，因为JSessionId这个标志去到别的服务器是找不到对应的session的（事实上，传统的session已经慢慢退出江湖）。 这时候，我们需要自己掌控code_key的生成和存储，关系型数据库（如MySQL）或高性能的NoSQL数据库（如Redis）都是不错的选择。以 用户登录+图片验证码+redis 为例：

用户登录+图片验证码+redis

可以看到，与单台服务器主要差距在：

在上面两种方式，我们发现验证码的生成、存储、校验、业务处理等动作均是在业务方完成的，验证码逻辑和业务的耦合可能会导致一些问题：

为了解决上面的这些问题，我们可以建立一个专门搞验证的服务——验证中心：

仍以用户登录为例，我们现在来看看初步的方案：

验证中心初步流程

我们需要明白的是，客户端一共发起三次请求：（1）请求验证中心输出验证码（2）请求验证中心校验验证码（3）请求业务方二次校验并处理业务。 这个初步的方案并不完美，因为在第（3）个请求，也就是二次校验时，只要code_key-ticket相互对应都会通过，这会导致：

为了解决以上问题，针对每个业务方，验证中心需要分配一个的账号（也就是我们常见的app_id和app_secret）； 针对某个业务方下的每个需要验证码的业务接口，需要分配一个的id（姑且叫business_id），它标识了对应的业务和接口，以及使用什么类型的验证码（当然这个类型应该支持动态配置），其关系如下：

app_id和business_id的关系

加入这些元素后，我们的流程基本不变，只不过多了一些参数校验而已，最终的流程：

验证中心完整流程

也有一些方案是没有business_id这个东西的，他们的business_id等同于app_id，一个业务方中也就只有一个。像我司的验证中心就是一个app_id，客户端、业务方均使用这个。这个主要看大家的细粒度需要分成什么程度了