2013年11月25日

Capy 架構設計誌

我們知道 google reCAPTCHA 使用三次 connection 來顯示,但是我們想要減少到兩次,一次抓Javascript,一次抓圖片,但是如何驗證呢


2013/07之前,團隊的K夥伴利用IP位置來分辨不同使用者和captcha challenge,並在使用者回答或TTL之後去除掉這個challenge,但是這有兩個問題,一個是多人使用同個IP的情況,一個是同時開啟多個captcha可以讓任意答對的機率線性提高。

2013/07我加入Capy,我發現了第二個問題之後修改了設計,我們在client產生一個random token (challenge key),利用此token產生和取得captcha image並記錄資料在資料庫等待被驗證,site owner使用我們的服務並且用同樣的token驗證,在極端的情況有個問題是,如果有人在取得captcha之前就先送出答案,server上會找不到這個key,我們選擇不理會此情況,到此為止我們都只需要兩次connection。

以上兩種設計都有共同的問題就是database heavy write,我們很早就需要做 database sharding ,感覺不會很難又很有趣,但是所有的文章都說 sharding 越晚做越好,不要讓初期的結構變複雜。

2014/01 一個實習生告訴我們可以使用 stateless 的作法,不需要放進database,這樣有一個大的好處,不需要做database sharding,但是也有一些壞處..