老和山小和尚

为了应对网络中的恶意注册或者DDOS攻击，区分是人类还是非人类是非常重要的，验证码也应运而生。我在前面提出过用验证码来对付DDOS攻击的方法。但DDOS攻击由于来势凶猛，对于验证码服务本身的效率要求比较高。

本文就提出一种快速回复和验证的验证码服务器。主要使用了nginx+ngx_lua+memcached的的技术。所有使用的代码在这里可以看到：

https://github.com/yaoweibin/captcha_server

服务器的使用方法如下：

1. 首先我使用Jcaptcha来产生1万张验证图片，文件名就是其匹配字符串。据我的同事说，Jcaptcha由于字母的粘连效果较好，破解难度比较大。

2. 然后安装一个memcache服务器，将1万张图片按字符串和图片的对应关系存入memcached。同时，存入一个1到1万的序号与匹配字符串的映射表。

3. 安装

去年我就开发了nginx_limit_access_module， 该模块提供一个POST接口，通过该接口，系统管理员可以发送指令进去，手工封禁某些host，ip，uri等资源。这些封禁都需要手工配置，基本上想封什么就封什么，但它只是一个被动技能，需要你发送封禁指令。如果你想让Nginx自动封禁，可以看看limit_req和limit_conn模块。

DDOS攻击每逢年关就攻击得紧些，这个模块是去年年底开发的，当时也测试了挺久，都没什么大问题，过了年，就没有攻击了，后来也就没上线。结果今年年底又来了，攻击的目标都是些私服博客，看起来DDOS攻击还是挺赚钱的，真是个人傻钱多的行业。

基本上我们碰到的攻击都是固定的host或者uri，攻击IP主机可能有几千个，高峰期每秒钟有近万个并发请求，攻击会持续1个小时左右，结果导致后端应用服务器先撑不住挂掉，然后是nginx，由于后端服务器没有反应，积累过多链接，内存耗尽，也挂了。

最终结果是，我们屈服了，直接将私服博客封掉了事。

但每次这样搞我们也不是办法，狗急了也会跳墙，谁愿意大半夜的起来重启机器？所以，我们现在设计了一套应急方案：在应用服务器那边，对单个博客访问次数进行统计，超过一定阈值，向limit_access模块发送指令，自动封禁某些host一段时间。逻辑很简单，响应速度也足够快。我们的想法也是尽量单点清除，不影响其他用户的体验。

最近需要用到多台cache服务器来作图片缓存，我在设计的时候考虑，一方面我想增加cache服务器的命中率，通过对URL进行hash是比较好的方法，各台服务器可以尽可能集中缓存一部分的页面。另一方面，我想尽可能的降低在增减cache服务器时候的出现所有cache重新分配的局面。所以，自然而然我想到了用一致性hash的方法。

原理

一致性hash的方法的原理[1][2]相当简单，它建立了一定范围hash值的环，每个cache服务器节点经过hash计算都映射到环上相应某个点。

当某个HTTP请求过来时，可以对其URL进行hash计算，获得的hash值在上面这个环沿顺时针方向进行查找，找到第一个点就是它需要的目标节点。

当服务器节点增加时，假设cache B与cache C之间加了一个cache D的节点，其影响也就是Key B与Key C之间的部分cache会重新分配，其他区间则不会改变。传统的hash分配的方法一般是hash值和服务器数进行求余，当服务器数据变化时，所有的hash值都会变化，这样会引起后端cache记录的剧烈抖动，大部分的cache数据可能需要重新向源服务器请求并刷新。

我参考的一种实现方式

上述一致性hash原理很简单，但具体实现还有很多地方需要优化，比如：key A, B, C如何分布，才能让到服务器ABC的负载均衡？增减服务器的时候也能实现负载均衡，并把抖动的cache数据量控制在一定的范围内？

这就引出了虚拟节点的概念：

虚拟节点的概念就是在环上出现的多个点对应的是同一个真实节点，也可以说是让真实的服务分布到环上的多个位置。