2011-07-16 158 views
1

我需要實現一個匿名投票系統(用戶註冊是不行)。我已經決定,最好的選擇是限制單個項目的票數爲每個IP10(考慮到學校等)。PHP + MySQL限制IP投票系統

什麼是最好的方法來解決這個問題。我正在使用PHP + MySQL。在高峯時段,每秒可能會有20張選票。我使用負載平衡的前端與專用的MySQL服務器。

我擔心的是在數據庫中的每一票插入一行,然後查詢這些數據,看看他們是否已經達到極限可能是太多的服務器來處理?

我會更好看的MongoDB什麼?

還有其他想法嗎?

回答

4

我會建議將「投票」狀態保存在cookie中。這將允許全校&辦事處投票。這樣做每個IP 10將允許在一個地址的單個用戶投票10次。

顯然有它周圍的方式,如清除餅乾等,但我認爲這是一個不錯的選擇。

+0

對不起,忘了提及我已經這樣做了。我只需要防止那些願意通過清除他們的Cookie超過10次投票進一步的人。我知道沒有傻瓜證明的方式,但通過知識產權進行限制似乎是一個很好的妥協。 – bradley

+0

在這種情況下,您可以爲每個IP添加一個上限,但我認爲這取決於您的市場。如果您希望很多學校/辦公室用戶投票,那麼這可能不是一個好主意。而且,即使有IP限制,用戶仍然可以通過代理進行投票。如果每個人保持1票是非常重要的話,那麼我會建議用戶註冊。 – adlawson

1

只要確保你指數知識產權領域,並考慮代表它不是一個字符串(例如整數)以外的東西。在這裏看到更多的細節:http://daipratt.co.uk/mysql-store-ip-address/

此外,通過adlawson cookie的想法是好的。你可以同時使用這兩個IP地址,也許可以讓IP地址向你發出警報,在那裏你可以進入某個管理員屏幕,並決定這些IP看起來像是某人試圖欺騙系統而不是學校。

有關ipv6的更新:我對ipv6 w/regards對當前webhosting沒有太大的瞭解,所以不確定ipv6上是否存在專門用戶。如果是的話,你可以考慮一些在這些職位對於如何存儲他們提出的想法:

+0

這聽起來不錯。我應該擔心IPv6嗎?我不能將這些數據存儲爲整數,或者在ISP開始拋棄這些數據之前這種情況不太可能發生?請原諒我的無知。 – bradley

+0

我更新了上面的帖子w /一些ipv6信息(雖然,我在這個問題上的專業知識是相當有限的) –

3

我覺得鍵/值數據庫會更好這裏。
此外,你不用排了每一張選票,則需要每個IP和使用只有1排queryes LIKE如你所描述應該罰款

INSERT INTO .. ON DUPLICATE KEY UPDATE 
1

負載均衡。一個專用的MySQL服務器不應該有任何問題的速度的查詢。我不認爲MongoDB會幫助解決這樣的問題。類似memcached的性能要高得多,但您仍然需要在某些時候將數據發送到更持久的MySQL DB。

我會adlawston上使用cookie,而不是同意。你仍然可以有一個可以從一個單一的IP

2

我需要實現一個匿名投票系統(用戶註冊是 沒有去)

IP的可以投票的上限是不解決這個問題的方法,因爲很多公司/學校有成千上萬的人映射到幾個IP地址。如果您不希望用戶因匿名投票而登錄,我會建議您使用CAPTCHA(recaptcha)來保護羣衆投票,因爲所有其他技術都可以被熟練的程序員繞過。它甚至有可能到spoof IP address。我相信在很多Linux發行版中,您可以輕鬆地欺騙IP。

[email protected]:~/bash$ apt-cache search ^fake$ 
fake - IP address takeover tool 

http://en.wikipedia.org/wiki/IP_address_spoofing#Defense_against_spoofing

此外,還建議設計的網絡協議和服務,以便 它們不依賴於IP源地址進行驗證。

但一個熟練的程序員不能繞過經過測試的驗證碼,如recaptcha。投票有點難,但在我看來,這是對付假投票的唯一方法。另外captcha不能使投票系統無法投票錯誤。製作這種系統的唯一方法是使用認證。保留允許投票的用戶(身份)列表。

什麼是最好的方法來解決這個問題。我正在使用PHP + MySQL。在 高峯期間,可能會有多達每秒20票。

這甚至不會冒汗Redis,因爲它非常快速。

Redis是一個開源的高級鍵值存儲。它通常被稱爲數據結構服務器,因爲密鑰可以包含字符串, 哈希,列表,集合和有序集合。

首先我的系統信息。我喜歡它,但它已經很老了。

-Computer- 
Processor  : 2x Intel(R) Core(TM)2 Duo CPU  T7100 @ 1.80GHz 
Memory  : 2051MB (1403MB used) 
Operating System  : Ubuntu 10.10 
User Name  : alfred (alfred) 
Date/Time  : Sat 16 Jul 2011 07:53:20 PM CEST 
-Display- 
Resolution  : 1280x800 pixels 
OpenGL Renderer  : Unknown 
X11 Vendor  : The X.Org Foundation 
-Multimedia- 
Audio Adapter  : HDA-Intel - HDA Intel 
-Input Devices- 
Power Button 
Lid Switch 
Sleep Button 
Power Button 
AT Translated Set 2 keyboard 
Dell Dell USB Keyboard 
Logitech Trackball 
PS/2 Logitech Wheel Mouse 
Video Bus 
-Printers (CUPS)- 
Canon-MP150  : <i>Default</i> 
HP-Photosmart-b110 
-SCSI Disks- 
HL-DT-ST DVDRAM GSA-T20N 
ATA WDC WD1600BEVS-2 

接下來我將基準我的Redis服務器:

[email protected]:~/database/redis-2.2.0-rc4/src$ ./redis-server --version 
Redis server version 2.1.12 (00000000:0) 

[email protected]:~/database/redis-2.2.0-rc4/src$ ./redis-benchmark 
====== PING (inline) ====== 
    10000 requests completed in 0.23 seconds 
    50 parallel clients 
    3 bytes payload 
    keep alive: 1 

94.11% <= 1 milliseconds 
97.77% <= 2 milliseconds 
98.97% <= 3 milliseconds 
99.02% <= 4 milliseconds 
99.51% <= 6 milliseconds 
99.88% <= 7 milliseconds 
100.00% <= 7 milliseconds 
44052.86 requests per second 

====== PING ====== 
    10000 requests completed in 0.23 seconds 
    50 parallel clients 
    3 bytes payload 
    keep alive: 1 

87.97% <= 1 milliseconds 
97.44% <= 2 milliseconds 
98.83% <= 3 milliseconds 
99.41% <= 4 milliseconds 
99.51% <= 5 milliseconds 
99.70% <= 6 milliseconds 
100.00% <= 6 milliseconds 
43478.26 requests per second 

====== MSET (10 keys) ====== 
    10000 requests completed in 0.37 seconds 
    50 parallel clients 
    3 bytes payload 
    keep alive: 1 

11.02% <= 1 milliseconds 
82.00% <= 2 milliseconds 
93.94% <= 3 milliseconds 
97.18% <= 4 milliseconds 
98.17% <= 5 milliseconds 
98.89% <= 6 milliseconds 
99.44% <= 7 milliseconds 
99.51% <= 9 milliseconds 
99.52% <= 10 milliseconds 
100.00% <= 10 milliseconds 
26881.72 requests per second 

====== SET ====== 
    10000 requests completed in 0.24 seconds 
    50 parallel clients 
    3 bytes payload 
    keep alive: 1 

86.50% <= 1 milliseconds 
96.08% <= 2 milliseconds 
97.45% <= 3 milliseconds 
97.87% <= 4 milliseconds 
99.02% <= 5 milliseconds 
99.51% <= 6 milliseconds 
99.52% <= 7 milliseconds 
100.00% <= 7 milliseconds 
40983.61 requests per second 

====== GET ====== 
    10000 requests completed in 0.23 seconds 
    50 parallel clients 
    3 bytes payload 
    keep alive: 1 

86.06% <= 1 milliseconds 
97.51% <= 2 milliseconds 
98.89% <= 3 milliseconds 
99.65% <= 4 milliseconds 
100.00% <= 4 milliseconds 
42553.19 requests per second 

====== INCR ====== 
    10000 requests completed in 0.23 seconds 
    50 parallel clients 
    3 bytes payload 
    keep alive: 1 

90.72% <= 1 milliseconds 
96.92% <= 2 milliseconds 
98.12% <= 3 milliseconds 
98.33% <= 4 milliseconds 
99.27% <= 5 milliseconds 
99.51% <= 7 milliseconds 
100.00% <= 7 milliseconds 
43103.45 requests per second 

====== LPUSH ====== 
    10000 requests completed in 0.23 seconds 
    50 parallel clients 
    3 bytes payload 
    keep alive: 1 

87.92% <= 1 milliseconds 
96.35% <= 2 milliseconds 
98.26% <= 3 milliseconds 
99.51% <= 7 milliseconds 
100.00% <= 7 milliseconds 
42735.04 requests per second 

====== LPOP ====== 
    10000 requests completed in 0.24 seconds 
    50 parallel clients 
    3 bytes payload 
    keep alive: 1 

87.75% <= 1 milliseconds 
96.67% <= 2 milliseconds 
97.77% <= 3 milliseconds 
98.64% <= 4 milliseconds 
98.65% <= 5 milliseconds 
99.80% <= 6 milliseconds 
100.00% <= 6 milliseconds 
41841.00 requests per second 

====== SADD ====== 
    10000 requests completed in 0.23 seconds 
    50 parallel clients 
    3 bytes payload 
    keep alive: 1 

89.55% <= 1 milliseconds 
96.56% <= 2 milliseconds 
97.80% <= 3 milliseconds 
98.76% <= 4 milliseconds 
99.50% <= 5 milliseconds 
99.63% <= 6 milliseconds 
100.00% <= 6 milliseconds 
42553.19 requests per second 

====== SPOP ====== 
    10000 requests completed in 0.25 seconds 
    50 parallel clients 
    3 bytes payload 
    keep alive: 1 

88.12% <= 1 milliseconds 
96.21% <= 2 milliseconds 
97.45% <= 3 milliseconds 
97.99% <= 4 milliseconds 
98.53% <= 5 milliseconds 
99.51% <= 6 milliseconds 
100.00% <= 6 milliseconds 
40322.58 requests per second 

====== LPUSH (again, in order to bench LRANGE) ====== 
    10000 requests completed in 0.24 seconds 
    50 parallel clients 
    3 bytes payload 
    keep alive: 1 

89.41% <= 1 milliseconds 
96.05% <= 2 milliseconds 
97.76% <= 3 milliseconds 
98.76% <= 4 milliseconds 
99.01% <= 5 milliseconds 
99.51% <= 7 milliseconds 
99.96% <= 8 milliseconds 
100.00% <= 8 milliseconds 
42016.81 requests per second 

====== LRANGE (first 100 elements) ====== 
    10000 requests completed in 0.40 seconds 
    50 parallel clients 
    3 bytes payload 
    keep alive: 1 

11.56% <= 1 milliseconds 
76.23% <= 2 milliseconds 
91.93% <= 3 milliseconds 
94.47% <= 4 milliseconds 
97.80% <= 5 milliseconds 
99.23% <= 6 milliseconds 
99.87% <= 9 milliseconds 
100.00% <= 9 milliseconds 
24937.66 requests per second 

====== LRANGE (first 300 elements) ====== 
    10000 requests completed in 0.86 seconds 
    50 parallel clients 
    3 bytes payload 
    keep alive: 1 

2.28% <= 1 milliseconds 
10.90% <= 2 milliseconds 
35.68% <= 3 milliseconds 
63.74% <= 4 milliseconds 
86.00% <= 5 milliseconds 
92.65% <= 6 milliseconds 
94.96% <= 7 milliseconds 
97.50% <= 8 milliseconds 
98.04% <= 9 milliseconds 
98.75% <= 10 milliseconds 
99.56% <= 11 milliseconds 
99.96% <= 12 milliseconds 
100.00% <= 12 milliseconds 
11682.24 requests per second 

====== LRANGE (first 450 elements) ====== 
    10000 requests completed in 1.15 seconds 
    50 parallel clients 
    3 bytes payload 
    keep alive: 1 

1.13% <= 1 milliseconds 
6.20% <= 2 milliseconds 
10.38% <= 3 milliseconds 
27.37% <= 4 milliseconds 
53.45% <= 5 milliseconds 
74.60% <= 6 milliseconds 
89.41% <= 7 milliseconds 
95.40% <= 8 milliseconds 
98.04% <= 9 milliseconds 
98.98% <= 10 milliseconds 
99.46% <= 11 milliseconds 
99.58% <= 12 milliseconds 
99.73% <= 13 milliseconds 
99.87% <= 14 milliseconds 
100.00% <= 14 milliseconds 
8695.65 requests per second 

====== LRANGE (first 600 elements) ====== 
    10000 requests completed in 1.45 seconds 
    50 parallel clients 
    3 bytes payload 
    keep alive: 1 

0.52% <= 1 milliseconds 
6.23% <= 2 milliseconds 
10.67% <= 3 milliseconds 
16.37% <= 4 milliseconds 
27.51% <= 5 milliseconds 
46.06% <= 6 milliseconds 
60.82% <= 7 milliseconds 
79.70% <= 8 milliseconds 
90.96% <= 9 milliseconds 
96.01% <= 10 milliseconds 
97.99% <= 11 milliseconds 
99.43% <= 12 milliseconds 
99.90% <= 13 milliseconds 
100.00% <= 13 milliseconds 
6896.55 requests per second 

incr操作是您需要什麼,是你可以看到我的系統可以處理43103.45 requests per second

對於MongoDB什麼的我會更好嗎?

我建議redis如上所述。

1

10完全是一個任意值,並不會佔到辦公室那裏有可能是數百甚至數千背後一個面向公衆的IPv4地址的人。更不用說你可能允許個人投票十次。

顯然,這不是一個強大或適合用途的解決方案。

找到另一種唯一標識人的方法。