2015年12月，也就是在一年前，開(kāi)發(fā)了半年的云存儲(chǔ)服務(wù)上線。這對(duì)于付出了半年努力的我們來(lái)說(shuō)，是一件鼓舞人心的事件。因?yàn)檫@個(gè)服務(wù)在我們手上經(jīng)歷了從0到1的過(guò)程。這是我們自己的一小步，卻是整個(gè)云存儲(chǔ)服務(wù)的一大步。

我們開(kāi)發(fā)的是一款視頻監(jiān)控類的軟件，分為視頻采集端跟觀看端。采集端可以是專業(yè)攝像頭，手機(jī)，無(wú)人機(jī)等各類智能設(shè)備，觀看端一般是手機(jī)或者電腦。最基礎(chǔ)的功能，就是視頻觀看，采集端實(shí)時(shí)采集圖像，編碼，傳輸，觀看端進(jìn)行點(diǎn)播服務(wù)。同時(shí)采集端可以監(jiān)測(cè)視頻畫(huà)面的運(yùn)動(dòng)幅度，然后觸發(fā)報(bào)警，并且會(huì)錄制報(bào)警視頻。我們的云存儲(chǔ)服務(wù)就是將錄制的報(bào)警視頻上傳到云端，并且在觀看端提供查看功能 

2.0 石器時(shí)代

第一個(gè)版本叫2.0，至于為什么叫2.0，或許這只是一個(gè)代號(hào)而已。

整個(gè)系統(tǒng)的框架如下：

整個(gè)系統(tǒng)由客戶端， web服務(wù)器， 數(shù)據(jù)庫(kù)， 文件存儲(chǔ)服務(wù)器構(gòu)成。文件服務(wù)器使用的是亞馬遜的S3，對(duì)于小公司來(lái)說(shuō)，選擇亞馬遜比自建存儲(chǔ)的成本要低得多。

我們要求系統(tǒng)要盡可能及時(shí)的上傳報(bào)警視頻。一個(gè)報(bào)警視頻大概錄制30s，及時(shí)意味著報(bào)警一旦觸發(fā)就要開(kāi)始上傳，而不是等報(bào)警視頻錄制結(jié)束了再上傳錄制下來(lái)的報(bào)警文件。而且在有些設(shè)備上，如攝像頭，是可以沒(méi)有存儲(chǔ)卡的，但是也得能上傳，所以選擇上傳報(bào)警視頻文件的方式就不可取了。而在s3服務(wù)使用的是http協(xié)議上傳文件，必須在上傳文件之前告訴服務(wù)器文件的大小，即http頭里面的content-length信息。為了解決這個(gè)問(wèn)題，我們使用了分片上傳的方式。就是首先根據(jù)視頻的分辨率大小，計(jì)算出一個(gè)文件size，這個(gè)大約能存儲(chǔ)10s左右的視頻。在上傳過(guò)程中，計(jì)算已經(jīng)上傳的數(shù)據(jù)量大小，當(dāng)一個(gè)分片存儲(chǔ)滿之后，再開(kāi)始另一個(gè)分片。在最后一個(gè)分片時(shí)，可能報(bào)警視頻已經(jīng)錄制結(jié)束了，但是分片還沒(méi)存滿，這時(shí)候就用空數(shù)據(jù)填充。當(dāng)然空數(shù)據(jù)的位置也得記錄下來(lái)，這樣觀看端在播放時(shí)，就不至于把空數(shù)據(jù)當(dāng)作正常數(shù)據(jù)，導(dǎo)致播放失敗。除了正常的視頻數(shù)據(jù)，在每段報(bào)警視頻的最后還得記錄視頻中的I幀位置信息，主要是用于在播放時(shí)拖動(dòng)，尋找位置信息。這一點(diǎn)是參考mp4文件的錄制方式，由于我們使用的并不是標(biāo)準(zhǔn)的mp4格式，所以在上傳視頻的過(guò)程中，得將I幀的位置信息記錄下來(lái)，待整個(gè)視頻上傳結(jié)束后，將位置信息存儲(chǔ)在視頻的尾部，最后不足一個(gè)分片的部分，再用空數(shù)據(jù)填上。

整個(gè)采集端來(lái)說(shuō)，上傳文件到亞馬遜S3的過(guò)程就是如此，那么跟web服務(wù)器又是怎么交互的呢？

第一步，采集端在觸發(fā)了一個(gè)報(bào)警時(shí)，要向web服務(wù)器申請(qǐng)一個(gè)EVENTID，作為這個(gè)報(bào)警事件的唯一標(biāo)識(shí)，在之后上傳文件都跟這個(gè)EVENTID綁定。觀看端在播放時(shí)，根據(jù)這個(gè)EVENTID查到它對(duì)應(yīng)的視頻文件，然后去亞馬遜S3上下載播放。

第二步，當(dāng)采集端向亞馬遜上傳一個(gè)分片文件時(shí)，需要生成一個(gè)uri，然后才能向這個(gè)uri PUT數(shù)據(jù)。uri的生成，采集端可以直接向亞馬遜申請(qǐng)，但是考慮到申請(qǐng)uri需要攜帶亞馬遜的賬戶秘鑰，放在客戶端做不安全，所以申請(qǐng)uri還是放在web服務(wù)器上。當(dāng)采集端需要上傳文件，向web服務(wù)器去申請(qǐng)。每次采集端申請(qǐng)uri時(shí)，帶上EVENTID，以及一個(gè)分片index，即告訴web服務(wù)器你要申請(qǐng)的是哪個(gè)eventid的第一個(gè)分片。生成的uri格式如下

http://xxxxxxxxxxxxxxxxxxxxxxxx/eventid/index.avi。前面的xxxx表示你在 s3上面創(chuàng)建的存儲(chǔ)桶，index即是第幾個(gè)文件， avi是文件的后綴名（這里是一個(gè)假設(shè)，叫什么都可以）。每開(kāi)始一個(gè)新的分片，index自動(dòng)加1，這樣在只需要記錄一個(gè)最終的index即可。下載時(shí)，根據(jù)最終的index大小，就可以把所有的文件都下載下來(lái)。當(dāng)申請(qǐng)到uri之后，采集端就可以通過(guò)http協(xié)議向這個(gè)uri上傳數(shù)據(jù)了。

第三步，在每個(gè)uri上傳結(jié)束之后，向web服務(wù)器report一次 event信息。這個(gè)event信息，即是第一步開(kāi)始時(shí)申請(qǐng)的eventid。匯報(bào)的信息，包括這個(gè)event 的觸發(fā)時(shí)間，類型，視頻時(shí)長(zhǎng)，視頻分辨率，音頻的采樣率，以及index。可以看到，每個(gè)uri上傳結(jié)束都匯報(bào)一次的信息，其實(shí)也只有index的值不同，其他的值都一樣。本來(lái)是可以等到在一個(gè)視頻完全上傳結(jié)束之后，一次性匯報(bào)一次event信息就OK了。但是考慮到，當(dāng)一個(gè)視頻正在上傳的過(guò)程中，采集端軟件crash了，或者小偷進(jìn)來(lái)后里面將監(jiān)控設(shè)備砸了，所以要每上傳一個(gè)分片都要匯報(bào)一次。這樣，觀看端查看時(shí)，就可以看到一個(gè)未完成的視頻了。除了這點(diǎn)外，也要注意到可能一個(gè)分片都沒(méi)上傳上去，就發(fā)生意外，所以我們?cè)诿看螆?bào)警一觸發(fā)，就立即抓一幅圖片，上傳到S3上。

上面基本就是整個(gè)系統(tǒng)上傳部分的流程。web服務(wù)器負(fù)責(zé)生成eventid, 申請(qǐng)uri，以及寫(xiě)數(shù)據(jù)庫(kù)。數(shù)據(jù)庫(kù)只要存儲(chǔ)一張event表項(xiàng)就可以了，表項(xiàng)里面記錄了這個(gè)event 的詳細(xì)信息。

在2.0版本中，雖然使用了redis緩存，用來(lái)降低mysql的訪問(wèn)壓力，但是緩存的使用很簡(jiǎn)單，僅僅存儲(chǔ)了一個(gè)采集端每天的event個(gè)數(shù)。這樣觀看端查詢時(shí)，可以一次性獲取到最近30天，每天的event個(gè)數(shù)。因?yàn)槲覀冎唤o用戶保留最近30天的數(shù)據(jù)，在redis上做了個(gè)數(shù)統(tǒng)計(jì)，就不用再去數(shù)據(jù)庫(kù)讀表統(tǒng)計(jì)了。

接下來(lái)再說(shuō)說(shuō)觀看端的查詢流程

首先，就是去查詢采集端最近一個(gè)月每天的event個(gè)數(shù)。

然后，再具體查看某一天的報(bào)警時(shí)，帶上日期，起 始時(shí)間段，去服務(wù)器查詢event列表。在返回結(jié)果之后，將event信息作本地緩存。如果下次再查詢，先查看本地緩存中是否存在，如果有就直接返回。

最后，根據(jù)web服務(wù)器返回的event信息，包括了這個(gè)event對(duì)應(yīng)著亞馬遜服務(wù)器上的uri，通過(guò)uri下載視頻數(shù)據(jù)播放。同時(shí)也將視頻數(shù)據(jù)緩存到本地文件中，供下次查看時(shí)使用。

3.0 青銅時(shí)代

2.0版本完成了0到1 的跨越，但是整個(gè)系統(tǒng)與服務(wù)還處于初級(jí)階段。在剛上線之后，就開(kāi)始了3.0的開(kāi)發(fā)工作。

3.0版本的主要目的是完成視頻數(shù)據(jù)與事件的分離。在2.0 版本中，我們以事件為單位，向AWS 上傳文件，這種業(yè)務(wù)模型有著一定局限性，文件數(shù)據(jù)強(qiáng)依賴事件。理想的狀態(tài)應(yīng)該是，文件數(shù)據(jù)應(yīng)該是一個(gè)整體，而不應(yīng)該按照事件來(lái)劃分。事件只需要記錄，其對(duì)應(yīng)的文件數(shù)據(jù)即可。對(duì)于一個(gè)事件，我們只需要在數(shù)據(jù)庫(kù)保存它的一些基本信息(比如時(shí)間，類型等等)，然后記錄下這個(gè)事件對(duì)應(yīng)的數(shù)據(jù)在云端的位置。這樣做有兩個(gè)好處：

1 數(shù)據(jù)與事件解耦，云端存儲(chǔ)的只是一堆文件，易于維護(hù)

2 數(shù)據(jù)可以復(fù)用，比如兩個(gè)事件發(fā)生的時(shí)間有重疊，在2.0版本，重疊的數(shù)據(jù)就要上傳兩次，浪費(fèi)了存儲(chǔ)空間

如圖所示，我們?cè)谏蟼鞅镜財(cái)?shù)據(jù)文件時(shí)，依然使用分片方式上傳。每讀取一幀數(shù)據(jù)，判斷一下數(shù)據(jù)的時(shí)間戳有沒(méi)有到達(dá)事件的開(kāi)始時(shí)間。如果到達(dá)，那么就向web服務(wù)器匯報(bào)一次事件信息，并且記錄下這個(gè)事件的開(kāi)始在該分片文件中所處的位置。同樣，判斷當(dāng)前正在處理的事件，比較時(shí)間戳，是否已經(jīng)達(dá)到結(jié)束時(shí)間。如果已經(jīng)結(jié)束，同樣記錄一個(gè)結(jié)束位置。一個(gè)分片文件可能對(duì)應(yīng)多個(gè)event，有些event在這個(gè)分片文件的某個(gè)地方開(kāi)始，有些event在這個(gè)分片文件的某個(gè)地方結(jié)束，還有些event可能占有整個(gè)分片文件。當(dāng)一個(gè)分片文件上傳結(jié)束時(shí)，需要向web服務(wù)器匯報(bào)分片文件信息，包括一些基本信息（大小，媒體參數(shù)，以及文件的uri等），以及分片文件與event的映射關(guān)系，即event的位置信息。在數(shù)據(jù)庫(kù)的設(shè)計(jì)中，event存儲(chǔ)一個(gè)表項(xiàng)，分片文件存儲(chǔ)一個(gè)表項(xiàng)，映射關(guān)系存儲(chǔ)一個(gè)表項(xiàng)。

關(guān)系如下圖所示：

在event與file的映射表項(xiàng)中，存儲(chǔ)了event與file id，以及這個(gè)event的開(kāi)始位于file的位置(start_pos)以及結(jié)束位置file中的位置(end_pos)。如果這個(gè)event不在這個(gè)file中開(kāi)始，也不在這個(gè)file中結(jié)束，那么說(shuō)明這個(gè)file處于這個(gè)event的中間，既不是第一個(gè)分片，也不是最后一個(gè)分片，那么start_pos就是0，end_pos就是分片文件大小，即分片的結(jié)束。index就是這個(gè)分片文件是該event的第幾個(gè)分片文件。

當(dāng)我們觀看某個(gè)云視頻時(shí)，只需要在數(shù)據(jù)庫(kù)中按照event進(jìn)行查找，即可以返回這個(gè)event的所有分片文件。觀看端拿到這些分片文件信息去亞馬遜S3下載，就行播放。

對(duì)于數(shù)據(jù)庫(kù)的影響：

2.0版本中，對(duì)于一個(gè)event在上傳一個(gè)分片文件之后，就要向web服務(wù)器匯報(bào)一次。web服務(wù)器判斷該event是否是第一次匯報(bào)，如果是在數(shù)據(jù)庫(kù)插入一行新的表項(xiàng)；如果不是，則要更新之前插入的表項(xiàng)

3.0版本中，分片文件每次匯報(bào)，只需要插入表項(xiàng)即可，沒(méi)有更新操作。event信息在開(kāi)始的時(shí)候匯報(bào)一次，在結(jié)束的時(shí)候需要更新一次。

整體來(lái)說(shuō)，3.0版本中減少了數(shù)據(jù)庫(kù)的update操作。搞過(guò)數(shù)據(jù)庫(kù)的人都知道，更新操作比插入對(duì)數(shù)據(jù)庫(kù)的消耗大得多，從某種意義上來(lái)說(shuō)也變相減輕了數(shù)據(jù)庫(kù)的負(fù)載。

在3.0版本中，我們修改了redis的使用策略。2.0版本僅僅用redis來(lái)統(tǒng)計(jì)每天的event數(shù)量，但是其實(shí)在查詢的時(shí)候，我們并不需要關(guān)心有多個(gè)數(shù)量。移動(dòng)端查詢時(shí)，是按業(yè)來(lái)查詢的，每次查詢10個(gè)，每次向下翻頁(yè)就再查詢10個(gè)，無(wú)法再翻頁(yè)時(shí)，就說(shuō)明已經(jīng)查詢出當(dāng)天所有數(shù)據(jù)了。為了提高查詢性能，我們將event的信息存儲(chǔ)在redis里面。包括event 的觸發(fā)時(shí)間，時(shí)長(zhǎng)，icon信息。按照日期+cid(采集端的id，唯一標(biāo)識(shí))+type(event類型)作為key, value是一個(gè)list類型的值，保存當(dāng)天所有的event id信息。然后再用eventid作key, value保存event的詳細(xì)信息。這樣在查詢時(shí)，先按照cid+日期+類型找到列表key，從里面讀取一頁(yè)的數(shù)據(jù)。然后再根據(jù)這一頁(yè)的數(shù)據(jù)，去查詢里面每個(gè)event的詳細(xì)信息。這樣在查詢列表時(shí)就不要再訪問(wèn)數(shù)據(jù)庫(kù)了。

濃縮視頻，壓倒數(shù)據(jù)庫(kù)的最后一根稻草

3.0版本上線三個(gè)月之后，系統(tǒng)運(yùn)行的還算良好，但是我們發(fā)現(xiàn)數(shù)據(jù)庫(kù)表項(xiàng)在飛速膨脹。我們的云服務(wù)用戶已經(jīng)有幾萬(wàn)個(gè)，每個(gè)采集端每天平均都要上傳幾十條視頻，所以按照這種速度，單表記錄很快就來(lái)到了將近1000w。在mysql上，1000萬(wàn)幾乎就是單表記錄上限了。搞web的兄弟發(fā)現(xiàn)這一趨勢(shì)后，做了分表方案。按照采集端的cid尾數(shù) 即(0-9)，將event，file，以及映射表分成了10張表。雖然是解決了存儲(chǔ)方面的問(wèn)題，但是隨著使用云服務(wù)的用戶在不斷增加，數(shù)據(jù)庫(kù)的訪問(wèn)壓力也在漸增。在3.0版本，我們新增了濃縮視頻功能，就是將一天中的視頻變化壓縮成很短的幾分鐘。由于短視頻每天才產(chǎn)生一個(gè)，所以我們?cè)诋?dāng)天錄制完之后，第二天的0點(diǎn)之后開(kāi)始上傳前一天產(chǎn)生的濃縮視頻。這個(gè)功能在3.0版本上運(yùn)行了一段時(shí)間，剛開(kāi)始沒(méi)有問(wèn)題。但是在不知不覺(jué)中，卻為自己刨了一個(gè)大坑。那段時(shí)間運(yùn)營(yíng)部門搞促銷活動(dòng)，用戶登錄送積分，用積分贈(zèng)送云服務(wù)。突然有一天，測(cè)試人員早上過(guò)來(lái)后發(fā)現(xiàn)前一天的濃縮視頻沒(méi)有上傳，翻開(kāi)采集端日志一看，在凌晨0點(diǎn)之后那段時(shí)間，所有的web請(qǐng)求全部失敗了。讓運(yùn)維同學(xué)查看了下凌晨那段時(shí)間發(fā)生了啥，一看驚呆了，在0點(diǎn)0分0秒那一刻，瞬間涌入了上萬(wàn)的請(qǐng)求。web服務(wù)器還好，有負(fù)載均衡，但是數(shù)據(jù)庫(kù)只有一臺(tái)，1s之內(nèi)成千上萬(wàn)的請(qǐng)求，數(shù)據(jù)庫(kù)不死才怪。由于在采集端做了失敗重試，請(qǐng)求失敗之后又會(huì)接著再次請(qǐng)求，數(shù)據(jù)庫(kù)幾乎一直在"臥倒"狀態(tài)。幸好的是，采集端做了重試次數(shù)限制，所以基本在凌晨1點(diǎn)之后請(qǐng)求數(shù)也就慢慢降下來(lái)了。而這一切，都是由于濃縮視頻集中在凌晨那段時(shí)間上傳導(dǎo)致的。做促銷活動(dòng)的那幾天，每天都會(huì)送出1w多的云服務(wù)，一下子就把數(shù)據(jù)庫(kù)壓垮了。其實(shí)解決這個(gè)問(wèn)題的方法很簡(jiǎn)單，對(duì)于濃縮視頻來(lái)說(shuō)，我們只要保證上傳了就可以，沒(méi)必要非得全部擠在0點(diǎn)這個(gè)時(shí)間。我們把上傳的時(shí)間隨機(jī)延長(zhǎng)至0~5點(diǎn)之間任何一個(gè)時(shí)間點(diǎn)，保證用戶在早上起來(lái)后能查看到即可。很快就出了更新版本，服務(wù)器的訪問(wèn)壓力隨即降了下來(lái)，服務(wù)也回歸正常。但是還是有一種隱約的不安，因?yàn)橛脩暨€在快速增長(zhǎng)，不知道哪一天服務(wù)器又會(huì)遇到類似的問(wèn)題。

4.0 火炮時(shí)代

3.0版本告一段落之后，隨即開(kāi)始了4.0版本的規(guī)劃。4.0版本主要要解決的，就是服務(wù)器的訪問(wèn)壓力，包括web服務(wù)器以及數(shù)據(jù)庫(kù)。主要的性能瓶頸還在數(shù)據(jù)庫(kù)上， web服務(wù)器作水平擴(kuò)容很簡(jiǎn)單，因?yàn)樵趙eb服務(wù)器前面有nginx作為接入層做負(fù)載均衡，新增一臺(tái)web服務(wù)器直接在nginx上加個(gè)配置就行了。但是數(shù)據(jù)庫(kù)因?yàn)檫€沒(méi)有做分庫(kù)，所以只能先優(yōu)化單臺(tái)數(shù)據(jù)庫(kù)的性能。使用Innodb引擎寫(xiě)性能每秒幾百個(gè)，還能再撐一段時(shí)間。運(yùn)行云存儲(chǔ)服務(wù)的采集端大約有幾萬(wàn)臺(tái)，每秒鐘的并發(fā)請(qǐng)求量還沒(méi)那么大。但是數(shù)據(jù)量增長(zhǎng)太快卻是一個(gè)問(wèn)題，雖然已經(jīng)按照采集端的cid做了分表，但是表項(xiàng)的數(shù)據(jù)按照現(xiàn)在的增長(zhǎng)速度很快又會(huì)到千萬(wàn)。分表也不可能這樣無(wú)限制的做下去，但是分表策略卻是可以調(diào)整的。其實(shí)我們的云服務(wù)有一個(gè)特點(diǎn)，就是數(shù)據(jù)只保存30天，查詢的時(shí)候也是按天來(lái)查詢，所以優(yōu)先應(yīng)該選擇按天來(lái)分表才對(duì)。30天過(guò)后，直接刪除掉老的表項(xiàng)，這樣數(shù)據(jù)就不會(huì)無(wú)限量的膨脹。每天建一張表，數(shù)據(jù)量也不會(huì)達(dá)到單表上限。僅僅是這樣實(shí)現(xiàn)一下其實(shí)也不復(fù)雜，但是考慮到版本兼容就沒(méi)那么簡(jiǎn)單了。數(shù)據(jù)庫(kù)還是只有一臺(tái)，用戶如果還是使用3.0的版本，我們也得按照新的分表方式來(lái)寫(xiě)表。這樣就帶來(lái)一個(gè)問(wèn)題，即按時(shí)間分表，到底是按照event的觸發(fā)時(shí)間來(lái)分表，還是按照event的上傳時(shí)間來(lái)分表？這到底有什么區(qū)別呢。一般情況下，采集端在觸發(fā)報(bào)警時(shí)，要立馬上傳視頻。但是如果當(dāng)時(shí)斷網(wǎng)了，我們也會(huì)緩存在本地，等到網(wǎng)絡(luò)恢復(fù)了再上傳。所以有可能在當(dāng)天觸發(fā)的報(bào)警視頻在第二天才能上傳，也有可能更晚。剛開(kāi)始想按照event的上傳時(shí)間來(lái)做分表，這樣做只要在服務(wù)器端判斷下當(dāng)前時(shí)間，將請(qǐng)求直接插入到對(duì)應(yīng)日期的表項(xiàng)中就行了。但是這種做法，查詢性能就比較差了。查詢的時(shí)候按日期查詢，這個(gè)日期是event的觸發(fā)時(shí)間。我們并不能確切地知道這一天的報(bào)警視頻到底被存儲(chǔ)在哪些表項(xiàng)當(dāng)中。只能遍歷這一天的前后幾張表，都查詢一遍。很顯然這會(huì)影響到查詢性能。于是就考慮按照event的觸發(fā)時(shí)間來(lái)做分表。但是又有另外一個(gè)問(wèn)題，每個(gè)event在剛開(kāi)始上傳時(shí)，需要向web服務(wù)器匯報(bào)一次event信息，結(jié)束時(shí)要再匯報(bào)一次，更新event的上傳狀態(tài)和總時(shí)長(zhǎng)。在開(kāi)始匯報(bào)時(shí)，帶了event的觸發(fā)時(shí)間信息，但是在結(jié)束匯報(bào)時(shí)并沒(méi)有帶時(shí)間信息，只有event id。因?yàn)樵?.0版本中，是根據(jù)cid來(lái)分表的，在結(jié)束匯報(bào)時(shí)帶了cid信息。但是按照4.0版本的分表方式，老版本的采集端在結(jié)束時(shí)匯報(bào)，緊靠cid信息就不知道到哪張表里去更新了。簡(jiǎn)單的方法就是從當(dāng)天的表項(xiàng)，往前遍歷，直到查到為止。但是這樣效率就很低了，更新一次帶來(lái)的性能壓力太大。后來(lái)想到了利用redis緩存,其實(shí)在event第一次匯報(bào)信息時(shí)，我們就已經(jīng)將這些信息記錄在redis里面了，所以只要根據(jù)eventid 在redis里面查到event的觸發(fā)時(shí)間，然后就可以直接插入到數(shù)據(jù)庫(kù)中。這是為了兼容3.0版本的策略，但是在4.0版本中，我們直接在申請(qǐng)eventid時(shí)，就帶上了日期信息，保證獲取到的eventid的前面幾位就是event的觸發(fā)時(shí)間日期。這樣根據(jù)eventid就可以知道分表信息了，省略了查詢緩存的過(guò)程。4.0版本的優(yōu)化大概就是這樣了。但是這還遠(yuǎn)未結(jié)束，僅僅的分表策略終究是有它的極限的，單臺(tái)數(shù)據(jù)庫(kù)的讀寫(xiě)性能就擺在那里，下一步要做分庫(kù)才行。為了提高性能，還可以使用異步化寫(xiě)入，即數(shù)據(jù)先保存到緩存中，然后批量寫(xiě)數(shù)據(jù)庫(kù)，降低數(shù)據(jù)庫(kù)的峰值壓力。

總結(jié)：

很多時(shí)候， 我們談到高并發(fā) 高負(fù)載，就會(huì)想到集群 ，分布式等一些高大上的名詞。但是如果連單機(jī)性能都沒(méi)有做好，談那些也就是空中樓閣了。記得之前看到，說(shuō)訪問(wèn)量排名全世界前20的網(wǎng)站stackoverflow,只有區(qū)區(qū)20多臺(tái)服務(wù)器，而且用的是.net。可見(jiàn)對(duì)業(yè)務(wù)本身的優(yōu)化，比基礎(chǔ)設(shè)施的建設(shè)更加重要。業(yè)務(wù)優(yōu)化應(yīng)該達(dá)到兩個(gè)目的：第一，使你的代碼運(yùn)行性能更高；第二，使得整體的業(yè)務(wù)架構(gòu)易于擴(kuò)展。談集群，分布式部署，也不是一蹴而就。在開(kāi)發(fā)代碼時(shí)，就要考慮到能夠水平擴(kuò)展等因素。這樣在未來(lái)，擴(kuò)展集群時(shí)，便也輕松了許多