pick王菊？作為“菊外人”的程序員能做點(diǎn)什么？
最近，想必大家的朋友圈都被“王菊”占領(lǐng)了，打開朋友圈到處可以見到“pick王菊”、“陶淵明”、“菊外人”等字眼，可謂是火的一塌糊涂。
作為一個(gè)“菊外人”的我“跟風(fēng)”的去了解了一下到底是怎么回事兒。原來是最近很火的一個(gè)選秀節(jié)目，大家都在呼吁給一個(gè)叫“王菊”的人投票。然后就有各種媒體發(fā)文分析“到底王菊是誰(shuí)？”、“王菊為什么火了？”、“pick王菊給這個(gè)社會(huì)帶來了什么？”等等文章。
但是，作為一個(gè)程序員，我們看這個(gè)世界的角度永遠(yuǎn)是那么的獨(dú)特：
我們是那個(gè)瀏覽網(wǎng)頁(yè)的時(shí)候經(jīng)常會(huì)按ctrl + s的人。
我們是那個(gè)按下電梯的之后就會(huì)忍不住想電梯調(diào)度算法的人。
我們是那個(gè)每次支付寶付款的時(shí)候都會(huì)考慮二維碼的生成邏輯的人。
不管是作為“菊外人”還是“陶淵明”，對(duì)于這個(gè)“pick王菊”事件，我們的角度是：如何實(shí)現(xiàn)一個(gè)高并發(fā)的投票系統(tǒng)？
我們需要一個(gè)怎樣的投票系統(tǒng)？筆者分別瀏覽了目前創(chuàng)造101的各個(gè)投票通道，基本的要求有以下幾個(gè)：
1、只有登錄用戶能投票
2、每個(gè)用戶投票數(shù)有限
3、不同用戶可投票數(shù)不同，如Vip會(huì)比普通用戶的票數(shù)多
4、投票是限時(shí)的，只有在有效時(shí)段內(nèi)才能投票
除了以上幾個(gè)功能性要求外，作為一個(gè)開發(fā)人員，還需要考慮以下幾個(gè)非功能性需求：
1、計(jì)數(shù)要準(zhǔn)確
2、可以處理高并發(fā)投票
3、可以處理大量的投票數(shù)據(jù)
4、要有很好的可用性
5、要把每個(gè)人的投票記錄下來
登錄驗(yàn)證
投票網(wǎng)站都是需要登錄驗(yàn)證的，用戶想要進(jìn)行投票，需要先登錄。目前很多大型網(wǎng)站的登錄都采用單點(diǎn)登錄（SSO，Single Sign On）技術(shù)，SSO是在多個(gè)應(yīng)用系統(tǒng)中，用戶只需要登錄一次就可以訪問所有相互信任的應(yīng)用系統(tǒng)。它是目前比較流行的企業(yè)業(yè)務(wù)整合的解決方案之一。
實(shí)現(xiàn)SSO的技術(shù)主要有以下幾種：
(1）基于cookies實(shí)現(xiàn)。 最簡(jiǎn)單的單點(diǎn)登錄實(shí)現(xiàn)方式，是使用cookie作為媒介，存放用戶憑證。但是存在幾個(gè)問題；1、cookies并不安全，2、cookies本身不跨域。3、瀏覽器對(duì)cookies個(gè)數(shù)和大小有限制。但是，如果想要解決的話，以上三個(gè)問題還是可以找到方案的。只不過會(huì)讓整個(gè)方案變得復(fù)雜而已。
(2) Broker-based（基于經(jīng)紀(jì)人），例如Kerberos等；這種技術(shù)的特點(diǎn)就是，有一個(gè)集中的認(rèn)證和用戶帳號(hào)管理的服務(wù)器。經(jīng)紀(jì)人給被用于進(jìn)一步請(qǐng)求的電子的身份存取。中央數(shù)據(jù)庫(kù)的使用減少了管理的代價(jià)，并為認(rèn)證提供一個(gè)公共和獨(dú)立的"第三方"。例如Kerberos,Sesame,IBM KryptoKnight（憑證庫(kù)思想)等。Kerberos是由麻省理工大學(xué)發(fā)明的安全認(rèn)證服務(wù)，當(dāng)前版本V5，已經(jīng)被UNIX和Windows作為默認(rèn)的安全認(rèn)證服務(wù)集成進(jìn)操作系統(tǒng)。
(3) Agent-based（基于代理人）在這種解決方案中，有一個(gè)自動(dòng)地為不同的應(yīng)用程序認(rèn)證用戶身份的代理程序。這個(gè)代理程序需要設(shè)計(jì)有不同的功能。比如，它可以使用口令表或加密密鑰來自動(dòng)地將認(rèn)證的負(fù)擔(dān)從用戶移開。代理人被放在服務(wù)器上面，在服務(wù)器的認(rèn)證系統(tǒng)和客戶端認(rèn)證方法之間充當(dāng)一個(gè)"翻譯"。例如SSH等。
(4) Token-based，例如SecurID,WebID，現(xiàn)在被廣泛使用的口令認(rèn)證，比如FTP,郵件服務(wù)器的登錄認(rèn)證，這是一種簡(jiǎn)單易用的方式，實(shí)現(xiàn)一個(gè)口令在多種應(yīng)用當(dāng)中使用。
(5) 基于安全斷言標(biāo)記語(yǔ)言（SAML）實(shí)現(xiàn)，SAML(Security Assertion Markup Language，安全斷言標(biāo)記語(yǔ)言）的出現(xiàn)大大簡(jiǎn)化了SSO，并被OASIS批準(zhǔn)為SSO的執(zhí)行標(biāo)準(zhǔn)。開源組織OpenSAML 實(shí)現(xiàn)了 SAML 規(guī)范。可參考http://www.opensaml.org。
目前，很多大型網(wǎng)站都采用一個(gè)開源的SSO解決方案——CAS，CAS由耶魯大學(xué)開發(fā)的單點(diǎn)登錄系統(tǒng)（SSO,single sign-on），應(yīng)用廣泛，具有獨(dú)立于平臺(tái)的，易于理解，支持代理功能。
權(quán)限控制
在投票網(wǎng)站驗(yàn)證完用戶的登錄信息之后，緊接著會(huì)判斷用戶的權(quán)限，然后根據(jù)不同的權(quán)限來給用戶分配不同的可投票次數(shù)。
關(guān)于權(quán)限的設(shè)計(jì)，一直是很多網(wǎng)站都要關(guān)心的問題。幾乎所有的網(wǎng)站都會(huì)有一定的權(quán)限要求。
目前，關(guān)于權(quán)限設(shè)計(jì)大部分均采用RBAC理論（Role-Based Access Control），即基于角色的權(quán)限訪問控制。
RBAC認(rèn)為權(quán)限授權(quán)實(shí)際上是Who、What、How的問題。在RBAC模型中，Who、What、How構(gòu)成了訪問權(quán)限三元組,也就是“Who對(duì)What進(jìn)行How的操作”。
一個(gè)簡(jiǎn)單的權(quán)限系統(tǒng)應(yīng)該包含以下幾個(gè)基本元素：
用戶、角色、權(quán)限、資源、操作。
【用戶】可以屬于多個(gè)【角色】。【角色】可以認(rèn)為是【權(quán)限】的合集。【權(quán)限】描述的是對(duì)【資源】的可【操作】能力。
比如在“pick王菊”這件事上，雖然大家都是“陶淵明”（王菊的粉絲自稱陶淵明，因?yàn)樘諟Y明愛菊花），但是有些用戶的角色是VIP用戶，有些用戶的角色是普通用戶。VIP角色的用戶在投票權(quán)限上就比普通用戶更高。
限時(shí)開啟
幾乎所有的投票活動(dòng)都是有一個(gè)起止時(shí)間的，只有在有效時(shí)間段內(nèi)用戶才可以參與投票。也就是說，當(dāng)活動(dòng)未開始的時(shí)候，用戶來到投票頁(yè)面，投票按鈕應(yīng)該是置灰無法點(diǎn)擊的，有些網(wǎng)站還會(huì)給出倒計(jì)時(shí)的提示。
這其中就涉及到很多問題了。如何在時(shí)間到達(dá)時(shí)將按鈕點(diǎn)亮呢？用戶通過非法手段在有效時(shí)間外點(diǎn)擊按鈕如何處理？到時(shí)間后按鈕又如何置灰？
一般情況下，用戶訪問的投票頁(yè)面被設(shè)計(jì)為靜態(tài)頁(yè)面，被緩存在 CDN 與反向代理服務(wù)器中，甚至在用戶的瀏覽器上。所以在投票活動(dòng)未開始時(shí)，用戶的刷新頁(yè)面請(qǐng)求是不會(huì)到達(dá)應(yīng)用服務(wù)器。同樣，在后端的投票接口中，在接受到用戶的投票請(qǐng)求時(shí)，也要做時(shí)間有效性的校驗(yàn)。
我們?cè)诿霘⑸唐返撵o態(tài)頁(yè)面中加入一個(gè) JavaScript 文件引用，它包含投票是否已開始的標(biāo)志。秒殺開始時(shí)，系統(tǒng)會(huì)生成一個(gè)新的 JavaScript 文件，它會(huì)被瀏覽器加載（刷新頁(yè)面或定時(shí)腳本），這樣就能點(diǎn)亮頁(yè)面中的購(gòu)買按鈕。這個(gè) JavaScript 文件使用隨機(jī)版本號(hào)，確保它不被瀏覽器、CDN 和反向代理服務(wù)器緩存。
同理，到達(dá)活動(dòng)截止時(shí)間的按鈕置灰也通過js引用的方式可以解決。
準(zhǔn)確計(jì)數(shù)
對(duì)于一個(gè)投票系統(tǒng)來說，最重要的就是計(jì)數(shù)了。要保證在高并發(fā)的情況下用戶的投票既不能多也不能少這是一個(gè)很大的挑戰(zhàn)。
在“pick王菊”的投票中，計(jì)數(shù)場(chǎng)景有多處需要。比如對(duì)于王菊的票數(shù)需要準(zhǔn)確的記錄下來。還有，會(huì)員的已投票次數(shù)也要準(zhǔn)確的記錄下來。這里我們就拿被投票者的票數(shù)來舉例。
基于MySql計(jì)數(shù)
我們能想到的最簡(jiǎn)單的方法就是在MySql數(shù)據(jù)庫(kù)表中創(chuàng)建一條記錄，記錄當(dāng)前被投票者的票數(shù)即可。如：
- CREATE TABLE IF NOT EXISTS `table_user_polls`(
- `id` INT UNSIGNED AUTO_INCREMENT,
- `user_id` bigint NOT NULL,
- `polls` bigint NOT NULL
- PRIMARY KEY ( `runoob_id` )
- ENGINE=InnoDB DEFAULT CHARSET=utf8;
當(dāng)然，這只是一張記錄總票數(shù)的表。當(dāng)有用戶投票的時(shí)候，我們通過修改表中的polls的值來進(jìn)行：
- update table_user_polls set polls = polls +1 where user_id = "1000";
當(dāng)采用以上的update語(yǔ)句時(shí)，基本可以滿足簡(jiǎn)單的票數(shù)的遞增。但是，一旦有高并發(fā)場(chǎng)景的話，就無法滿足了。因?yàn)槎嗳送瑫r(shí)執(zhí)行這個(gè)語(yǔ)句的時(shí)候，就會(huì)有的人的更新結(jié)果丟失。
這時(shí)候，就需要引入鎖機(jī)制來處理。比如我們?cè)黾訕酚^鎖，改進(jìn)后的update語(yǔ)句如下：
- update table_user_polls set polls = polls +1 where user_id = "1000" and polls = 1000000;
在更新table_user_polls表的polls字段的時(shí)候，我們先把表中當(dāng)前的polls值取出，然后作為樂觀鎖來控制更新，如果發(fā)生并發(fā)，只會(huì)有一個(gè)請(qǐng)求可以更新成功。其他請(qǐng)求就會(huì)更新失敗。
但是，緊接著又有兩個(gè)問題來了。
數(shù)據(jù)量太大 ?
如果數(shù)據(jù)量太大怎么辦？比如這場(chǎng)“全民Pick王菊”的行動(dòng)，參與的用戶可能有很多很多，而我們要對(duì)每個(gè)用戶的投票數(shù)據(jù)都持久化下來。這就涉及到一旦數(shù)據(jù)量過大，就會(huì)導(dǎo)致數(shù)據(jù)庫(kù)的讀寫性能急劇下降。
傳統(tǒng)的做法是進(jìn)行分庫(kù)分表，把投票表按照一定的維度進(jìn)行拆分。比如這種投票的場(chǎng)景，我們可以按照投票的用戶的userId拆分，對(duì)userId取模，根據(jù)結(jié)果存儲(chǔ)到不同的表中。如把所有投票數(shù)據(jù)拆分到8個(gè)庫(kù)128張表中，路由規(guī)則就是userId%128。
其實(shí)，這種單純的分庫(kù)分表還有一個(gè)另外的問題，雖然投票場(chǎng)景中可能涉及不到。1、熱點(diǎn)數(shù)據(jù)問題。如多個(gè)熱點(diǎn)用戶的數(shù)據(jù)都分到了同一個(gè)庫(kù)甚至同一張表中，就會(huì)又給數(shù)據(jù)庫(kù)帶來巨大壓力。2、數(shù)據(jù)的二次分表問題。一旦分表數(shù)量不夠了，就要再次分表。比如把128張表擴(kuò)展到256張表，這就麻煩了，需要對(duì)原來的1287張表中的數(shù)據(jù)重新進(jìn)行拆分，數(shù)據(jù)遷移到新的256張表中。
訪問量太大 ?
通過分庫(kù)分表之后，我們暫時(shí)解決了數(shù)據(jù)量大的問題，那么如果遇到訪問量大的問題怎么辦。無論是我們的應(yīng)用、服務(wù)器還是數(shù)據(jù)庫(kù)等，能承受的QPS(TPS)都是有限的。如果峰值的qps超過了限制，就有可能導(dǎo)致整個(gè)系統(tǒng)癱瘓。
那么如何提高一個(gè)服務(wù)或者接口的QPS呢，其實(shí)一個(gè)最簡(jiǎn)單的方法就是降低響應(yīng)時(shí)間（RT）。當(dāng)然RT和QPS的關(guān)系還會(huì)受最佳線程數(shù)等影響，但是降低RT也是一個(gè)比較有效的辦法。如果一個(gè)請(qǐng)求，在執(zhí)行過程中，什么都不需要需要等待，每個(gè)操作都可以快速執(zhí)行（如單純的在內(nèi)存中取數(shù)、計(jì)算等），那么RT就會(huì)低很多。
在程序中，導(dǎo)致請(qǐng)求阻塞的愿意可能有很多，數(shù)據(jù)庫(kù)操作可能是其中比較重要的一部分。雖然我們通過分庫(kù)的方式增加了數(shù)據(jù)庫(kù)的連接數(shù)，但是直接操作數(shù)據(jù)庫(kù)還是有很大的性能損耗的。
這時(shí)候，就要考慮在持久化存儲(chǔ)前面增加緩存了。在訪問數(shù)據(jù)庫(kù)之前先訪問緩存，如果緩存中沒有的話再訪問數(shù)據(jù)庫(kù)。這樣可以減少請(qǐng)求的響應(yīng)時(shí)間，從而提高QPS，進(jìn)而承載更大的訪問量。
這樣做有很大的好處，但是也不是完美的方案。比如這種投票系統(tǒng)，計(jì)數(shù)更新是非常頻繁的，所以要經(jīng)常失效緩存在重新緩存，緩存和數(shù)據(jù)庫(kù)之間的數(shù)據(jù)一致性問題就體現(xiàn)出來了。
以上，是通過MySql來進(jìn)行計(jì)數(shù)的方案，總結(jié)一下：
優(yōu)點(diǎn)：便于理解、學(xué)習(xí)成本低、開發(fā)成本也低。 缺點(diǎn)：對(duì)大數(shù)據(jù)量和高并發(fā)量支持不友好。
基于Redis計(jì)數(shù)
Redis 是目前 NoSQL 領(lǐng)域的當(dāng)紅炸子雞，它象一把瑞士軍刀，小巧、鋒利、實(shí)用，特別適合解決一些使用傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)難以解決的問題。
如果我們使用Redis來實(shí)現(xiàn)計(jì)數(shù)器的話，就相對(duì)來說簡(jiǎn)單一些了。因?yàn)镽edid提供了一個(gè)INCR命令，其使用方法如下：
- redis> SET wangju_polls 20
- OK
- redis> INCR wangju_polls
- (integer) 21
- redis> GET wangju_polls
- "21"
INCR key語(yǔ)法，可以將 key 中儲(chǔ)存的數(shù)字值增一。如果 key 不存在，那么 key 的值會(huì)先被初始化為 0 ，然后再執(zhí)行 INCR 操作。最重要的是INCR是一個(gè)原子性的自增操作。非常適合用來實(shí)現(xiàn)計(jì)數(shù)器。
引入了Redis之后，遇到高并發(fā)和大數(shù)據(jù)量的問題解決起來就簡(jiǎn)單了——堆機(jī)器。
當(dāng)然，這個(gè)方案雖然在很大程度上解決了大數(shù)據(jù)量和高并發(fā)的問題。但是，如果真的是業(yè)務(wù)量特別巨大，總不能無限制的增加通過增加機(jī)器來解決問題吧，機(jī)器就是成本啊。
關(guān)于這種問題，微博就遇到了，因?yàn)槲⒉┑狞c(diǎn)贊功能和我們的投票功能其實(shí)是類似的。明星的一條微博的點(diǎn)贊數(shù)可能有幾十萬(wàn)，甚至百萬(wàn)以上。有人（微博計(jì)數(shù)器的設(shè)計(jì)）算過一筆帳：
假設(shè) key 為8字節(jié)，value為 4字節(jié)，通過incr存儲(chǔ)的話:
一個(gè) value 通過 createStringObjectFromLongLong 創(chuàng)建一個(gè)robj，由于value在LONGMIN 和LONGMAX 之間，所以可以將value用 ptr指針來存儲(chǔ)，需要占用 sizeof(robj) = 16 字節(jié);
一個(gè)key(即微博id) 最長(zhǎng)64位數(shù)字(Eg: 5612814510546515491)，但通過 sdsdup 以字符串的形式存儲(chǔ)，至少需要 8(struct sdshdr)+19+1 = 28字節(jié);
為了存到Redis 的dict里面，需要一個(gè)dictEntry對(duì)象，繼續(xù) 3*8 = 24字節(jié);
放到db->dict->ht[0]->table中存儲(chǔ)dictEntry的指針，再要 8個(gè)字節(jié); 存儲(chǔ)一個(gè)64位key，32位value的計(jì)數(shù)，Redis也至少需要耗費(fèi): 16 + 28 + 24 + 8 = 76 字節(jié)。
1000億個(gè)key全內(nèi)存的話，就至少需要 100G * 76 = 7.6TB 的內(nèi)存了(折算76G內(nèi)存機(jī)器也需要100臺(tái)！)。
我們的有效數(shù)據(jù)其實(shí)是1000億個(gè)32位 = 400GB，但是卻需要了7.6T來存儲(chǔ)，內(nèi)存的有效利用率約為：400GB/7600GB = 5.3%
總的來說，Redis做為優(yōu)秀的內(nèi)存數(shù)據(jù)結(jié)構(gòu)，接口方便，使用簡(jiǎn)單，對(duì)于小型數(shù)據(jù)量的中高訪問量的計(jì)數(shù)類服務(wù)來說，是一個(gè)很不錯(cuò)的選擇，但是對(duì)于微博計(jì)數(shù)器這種極端的應(yīng)用場(chǎng)景，成本還是無法接受！
所以，微博的點(diǎn)贊功能，其實(shí)是在Redis的基礎(chǔ)上進(jìn)行了二次開發(fā)。如在數(shù)據(jù)機(jī)構(gòu)優(yōu)化、轉(zhuǎn)發(fā)和評(píng)論數(shù) Value的優(yōu)化、key的優(yōu)化、數(shù)據(jù)的持久化、一致性保證等方面做了很多事情。這里不詳細(xì)介紹了，感興趣的同學(xué)可以參考微博計(jì)數(shù)器的設(shè)計(jì)
其他
避免刷票
在創(chuàng)造101的投票規(guī)則中，明確規(guī)定了：請(qǐng)公平參與點(diǎn)贊，如采用違法或違反賽事規(guī)則的點(diǎn)贊行為，將會(huì)被收回相關(guān)點(diǎn)贊數(shù)并追究責(zé)任。
那么，如果我們是這個(gè)投票系統(tǒng)的開發(fā)，如何有效的避免刷票行為呢？
首先，我們要通過設(shè)計(jì)一個(gè)很好的計(jì)數(shù)器，能夠有效的避免高并發(fā)請(qǐng)求帶來的計(jì)數(shù)錯(cuò)誤。因?yàn)橥镀睍r(shí)可能有很多人使用腳本等構(gòu)造多條請(qǐng)求，試圖來突破限制來多投票。
其次，還可以通過一些其他限制手段來防止惡意刷票，如限制同一IP的投票次數(shù)、限制同一帳號(hào)的投票頻率等。
避免數(shù)據(jù)溢出
據(jù)說，在前段時(shí)間的MSI比賽前期，MSI的助威活動(dòng)中，人氣選手uzi的票數(shù)達(dá)到了網(wǎng)站開發(fā)人員設(shè)置的int的最大值。
以上只是個(gè)傳說，我并沒有去辯證他的真?zhèn)危沁@至少給我們一個(gè)提醒，在設(shè)計(jì)投票系統(tǒng)的時(shí)候，要充分的考慮到粉絲們的熱情和實(shí)力！
持久化數(shù)據(jù)的備份
無論最終選用那種方式進(jìn)行計(jì)數(shù)，數(shù)據(jù)的持久化問題都至關(guān)重要，一定要做好數(shù)據(jù)存儲(chǔ)的容災(zāi)工作。避免由于系統(tǒng)問題導(dǎo)致數(shù)據(jù)丟失。
【本文是51CTO專欄作者Hollis的原創(chuàng)文章，作者微信公眾號(hào)Hollis(ID：hollischuang)】
