使用 Redis 解决接口被刷问题
2011-7-19 12:21:17 阅读998 评论1 192011/07 July19
问题背景
Web 上，凡是有价值的接口页面、接口，在利益的驱动下，总有被犯罪分子刷的可能；
对方少数几个 IP 还好说，直接封 IP 了事，要是人家有肉鸡，有几千几万的 PC 资源，源源不断，封 IP 即便是自动检测自动封 IP 仍然是显的乏力，被欺负心里很不爽。
解决办法
其实很简单，在处理每个请求前，先检测下这个 IP 是否是恶意攻击的 IP，如果是直接返回个不知所云的页面给对方就好了。
要判断是否是恶意攻击的 IP，我们需要记录每个 IP 每一次请求的时间，如果在 xx 秒内，访问量超过 yy 值，则判定为恶意攻击的 IP。
这里要几个问题：
Web 上，凡是有价值的接口页面、接口，在利益的驱动下，总有被犯罪分子刷的可能；
对方少数几个 IP 还好说，直接封 IP 了事，要是人家有肉鸡，有几千几万的 PC 资源，源源不断，封 IP 即便是自动检测自动封 IP 仍然是显的乏力，被欺负心里很不爽。
解决办法
其实很简单，在处理每个请求前，先检测下这个 IP 是否是恶意攻击的 IP，如果是直接返回个不知所云的页面给对方就好了。
要判断是否是恶意攻击的 IP，我们需要记录每个 IP 每一次请求的时间，如果在 xx 秒内，访问量超过 yy 值，则判定为恶意攻击的 IP。
这里要几个问题：
- 由于每个接口请求，都要记录下 IP 和 请求时间，这个记录动作必须非常快，不能卡住，否则会影响整个服务。
linux glibc2.3 以后，已经在用 dlmalloc 了
2011-3-3 16:25:05 阅读292 评论0 32011/03 Mar3
摘自 wiki 上 malloc 页: http://en.wikipedia.org/wiki/Malloc#Implementations
Since the v2.3 release, the GNU C library (glibc) uses a modified ptmalloc2, which itself is based on dlmalloc v2.7.0.
本来还担心内存碎片问题，要选择一个好的内存分配器，现在不用了。
Since the v2.3 release, the GNU C library (glibc) uses a modified ptmalloc2, which itself is based on dlmalloc v2.7.0.
本来还担心内存碎片问题，要选择一个好的内存分配器，现在不用了。
Redis Dict 分析
2011-2-21 17:08:30 阅读402 评论0 212011/02 Feb21
非常普通的 Hash 算法，无特别之处。
如何解决 Hash 冲突
Hash Table 的每一个 Entry 是一个链表，Hash 值相同的 Entry 放在这个链表内；查询时，先用 Hash Key 定位到链表头，然后遍历这个链表执行查找或者插入操作。
Hash 表扩容方案
1) 新 Hash Table Size 的计算
每次执行 add Entry 操作时，先进行 Hash 表的扩容检测，算法如下：
如何解决 Hash 冲突
Hash Table 的每一个 Entry 是一个链表，Hash 值相同的 Entry 放在这个链表内；查询时，先用 Hash Key 定位到链表头，然后遍历这个链表执行查找或者插入操作。
Hash 表扩容方案
1) 新 Hash Table Size 的计算
每次执行 add Entry 操作时，先进行 Hash 表的扩容检测，算法如下：
[Nginx 源码分析]locations 设计和实现
2011-2-18 11:36:14 阅读971 评论0 182011/02 Feb18
Locations 数据结构及初始化
1) 先看看 ngx_http_core_loc_conf_t 这个结构体
struct ngx_http_core_loc_conf_s {
// location 名称
ngx_str_t name;
// 如果是 re location，这里存储 re 信息
// location 名称
ngx_str_t name;
// 如果是 re location，这里存储 re 信息
[Nginx 源码分析] Nginx 配置文件解析
2011-2-14 17:58:41 阅读692 评论0 142011/02 Feb14
内部数据结构
-------------------
先看下下面这个数据结构:
typedef struct {
void **main_conf;
void **main_conf;