小程序低成本抗住千萬日活的秘訣 二維碼
33
短期內(nèi)數(shù)據(jù)波動(dòng)極大,是很多小程序的特點(diǎn),一個(gè)產(chǎn)品成為爆款,可能就是幾個(gè)小時(shí)的過程。我們也曾經(jīng)歷過24小時(shí)之內(nèi)日活從幾萬暴增到千萬的過程。 如果遇到這樣的時(shí)候,服務(wù)器一旦宕機(jī),所造成的影響和損失就太巨大了。 我們在這方面吃了很多虧。記得當(dāng)年"圣誕帽"刷屏的時(shí)候,我們小程序一個(gè)小時(shí)就涌入200多萬人,導(dǎo)致WEB服務(wù)器和數(shù)據(jù)庫全部宕機(jī),只能望洋興嘆。 從那之后,我們痛定思痛,通過不斷的嘗試,總結(jié)了一些方法,低成本應(yīng)對突然爆發(fā)的流量。主要從以下三個(gè)方面: 1、客戶端 特別要注意核心頁面的接口請求數(shù)量,盡量減少一個(gè)頁面內(nèi)的請求數(shù)量 同時(shí),客戶端做好數(shù)據(jù)緩存。對于同一個(gè)用戶可能短時(shí)間內(nèi)多次訪問的數(shù)據(jù),可以在本地緩存一段時(shí)間,這樣能極大減少服務(wù)器請求。 2、服務(wù)端 服務(wù)端的性能優(yōu)化主要從兩個(gè)方面: 1)WEB服務(wù)器 通過隊(duì)列的方式來異步處理耗時(shí)(網(wǎng)絡(luò)請求)、耗資源(視頻處理等)的任務(wù),降低阻塞的可能 2)數(shù)據(jù)庫 通過Redis來緩存大量頻繁請求的數(shù)據(jù),減少數(shù)據(jù)庫查詢; 部分?jǐn)?shù)據(jù)先序列化到Redis,等服務(wù)器空閑之后,再持久化到數(shù)據(jù)庫,減少數(shù)據(jù)庫的寫入; 建好數(shù)據(jù)庫索引,上線之后經(jīng)常關(guān)注慢查詢?nèi)罩荆?/p> 3、云端 1)負(fù)載均衡+彈性伸縮 這兩個(gè)在云平臺(tái)上(阿里云、騰訊云等)都是很常見的功能。 負(fù)載均衡器就是一個(gè)流量的分發(fā)中介,你的域名解析到一個(gè)負(fù)載均衡器的IP上,一個(gè)負(fù)載均衡器后面可以設(shè)置很多個(gè)服務(wù)器。 彈性伸縮簡單來講,就是設(shè)置一些規(guī)則,滿足這些條件下,就自動(dòng)新增或者釋放服務(wù)器。 比如我把服務(wù)器做好鏡像,設(shè)置現(xiàn)在的服務(wù)器如果CPU或者帶寬超過50%就自動(dòng)創(chuàng)建一臺(tái)新的服務(wù)器,新的服務(wù)器使用現(xiàn)有的配置。當(dāng)CPU或者帶寬降下來的時(shí)候,就釋放掉剛才創(chuàng)建的服務(wù)器,整個(gè)過程都是自動(dòng)完成的。 注意:自動(dòng)伸縮配置里面,**選擇服務(wù)器按量付費(fèi),畢竟都是臨時(shí)的。 這里是按量付費(fèi)的服務(wù)器價(jià)格情況,是不是很便宜?。?br style="box-sizing:border-box;margin:0px;" /> 這里是伸縮條件的示例: 2)云開發(fā) 云開發(fā)里面的數(shù)據(jù)庫資源,是按照使用量(讀寫次數(shù)、容量)付費(fèi)的,價(jià)格低廉,性能也比較有保障。因?yàn)檫@樣的計(jì)費(fèi)模式,我們完全可以創(chuàng)建多個(gè)數(shù)據(jù)庫來分開存儲(chǔ)各個(gè)業(yè)務(wù)的數(shù)據(jù),成本不變,同時(shí)又不會(huì)輕易達(dá)到瓶頸(連接數(shù)限制等) 下面是云開發(fā)的數(shù)據(jù)庫的價(jià)格,是不是很香? 總的來說,客戶端的優(yōu)化,是最容易被忽略的,但是做的好的話可能減少一半的服務(wù)器壓力。 WEB服務(wù)器的瓶頸相對來說容易解決,帶寬或者CPU滿了的時(shí)候,可以通過彈性伸縮出新的服務(wù)器來分流,成本非常低。 數(shù)據(jù)庫的壓力往往**,WEB服務(wù)器可以很容易快速分流,數(shù)據(jù)庫就不行了。數(shù)據(jù)庫服務(wù)器一旦CPU100%,很難快速解決,升級數(shù)據(jù)庫服務(wù)器的配置能解決部分問題,但是成本相對WEB服務(wù)器會(huì)高很多。 通過這三個(gè)方面的不斷優(yōu)化,我們曾經(jīng)做到千萬日活的當(dāng)天,整個(gè)服務(wù)器端的成本就增加了2萬元(大部分還是CDN的成本)。 |