PHP+jQuery实现的大转盘抽奖程序

local secretkey='1234567890abcdefghi'
if ngx.var.cookie_uid == nil or ngx.var.cookie_username == nil or ngx.var.cookie_token ==nil then
ngx.req.set_header("Check-Login", "NULL")
return
end

» 阅读全文

关键词: lua , openresty

发表在: nginx运维 , 服务器运维 0 条评论阅读 4063 次

nginx+lua 实现简单的防机器程序访问

jincon 发表于 2016-04-17, 3:19 PM

这个比较简单，我只是觉得这个思路不错，借鉴了别人思路而已，可以学习。

    location /cookie {
   	    default_type 'text/html';
        rewrite_by_lua '
            local random = ngx.var.cookie_random

            if(random == nil) then
                random = ngx.md5(math.random(999999) .. os.time() .. math.random(999999))
            end

            local token = ngx.md5("opencdn" .. ngx.var.remote_addr .. random)
            if (ngx.var.cookie_token ~= token) then
                ngx.header["Set-Cookie"] = {"token=" .. token, "random=" .. random}
                return ngx.redirect(ngx.var.scheme .. "://" .. ngx.var.host .. ngx.var.uri)
            end
        ';
        content_by_lua_block {
            ngx.say("ok2")
    	}
    }

但是要注意了，这个不是万能神药，不能解决所有的问题。同时也要注意了，如果是蜘蛛的之类的也设置下白名单，因为他们可能获取不到 cookie 导致循环中。。。

发表在: nginx运维 , 服务器运维 0 条评论阅读 2222 次

利用openresty+lua+redis 实现封杀频繁恶意访问IP地址

jincon 发表于 2016-04-16, 4:06 PM

Nginx来限制访问控制的方法有多种，nginx主要有2个模块控制，但是那些不支持自定义，非常死，在大多数场景下并不实用。今天分享一个：利用openresty+lua+redis 实现封杀频繁恶意访问IP地址，当然这个方式也是有弊端的，那就是不断试用代理 IP之类的，但是用户还是有的，起码提高了恶意的成本。

本人最近已经完全抛弃了淘宝的Tengine，原生态的nginx，已经换为春哥的 openresty，特别想说的一点就是淘宝的 low 逼货，感觉一堆问题，尼玛，可能和他缘分不够吧，哈哈，于是，换到春哥的 openresty。喜欢春哥的 openresty 的最重要的原因，不外乎openresty打包了 nginx 的时候，集成了很多的有用的扩展，特别是 lua，一个小巧的编程语言，各种爽歪歪。本文就是：openresty最新稳定版本+lua Lua 5.1.4+redis最新稳定版本

如果你是原生态的 nginx，那你就自己安装 lua 和 nginx 的扩展吧，或者直接安装 openresty so easy。

先在 http 中加载lua 包和 lua 的 c 包

lua_package_path "/usr/local/openresty/lualib/?.lua;;";

lua_package_cpath "/usr/local/openresty/lualib/?.so;;";

1.png - 大小: 85.62 KB - 尺寸: 934 x 482 - 点击打开新窗口浏览全图

» 阅读全文

关键词: lua , openresty , redis

发表在: nginx运维 , 服务器运维 0 条评论阅读 5703 次

swift 多线程GCD和延时调用

jincon 发表于 2016-04-06, 5:03 PM

GCD 是一种非常方便的使用多线程的方式。通过使用 GCD，我们可以在确保尽量简单的语法的前提下进行灵活的多线程编程。在 “复杂必死” 的多线程编程中，保持简单就是避免错误的金科玉律。好消息是在 Swift 中是可以无缝使用 GCD 的 API 的，而且得益于闭包特性的加入，使用起来比之前在 Objective-C 中更加简单方便。在这里我不打算花费很多时间介绍 GCD 的语法和要素，如果这么做的话就可以专门为 GCD 写上一节了。在下面我给出了一个日常里最通常会使用到的例子 (说这个例子能覆盖到日常的 GCD 使用的 50% 以上也不为过)，来展示一下 Swift 里的 GCD 调用会是什么样子：

// 创建目标队列
let workingQueue = dispatch_queue_create("my_queue", nil)

// 派发到刚创建的队列中，GCD 会负责进行线程调度
dispatch_async(workingQueue) {
    // 在 workingQueue 中异步进行
    print("努力工作")
    NSThread.sleepForTimeInterval(2)  // 模拟两秒的执行时间

    dispatch_async(dispatch_get_main_queue()) {
        // 返回到主线程更新 UI
        print("结束工作，更新 UI")
    }
}

» 阅读全文

发表在: Swift/IOS编程 0 条评论阅读 2493 次

Web系统大规模高并发下数据安全，避免超发问题

jincon 发表于 2016-04-01, 1:59 PM

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

1. 超发的原因

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

» 阅读全文

发表在: 技术开发 0 条评论阅读 2936 次