在說(shuō)分庫(kù)分表之前,先簡(jiǎn)單介紹下網(wǎng)站架構(gòu),這樣有助于理解為何需要分庫(kù)分表這種技術(shù)。因?yàn)樗械募夹g(shù)，大多都是因?yàn)闃I(yè)務(wù)的需要而產(chǎn)生的.

1、網(wǎng)站發(fā)展的第一階段

大致架構(gòu)如下,因?yàn)闆](méi)有多少用戶訪問(wèn),所以單臺(tái)服務(wù)器都搞定所有的事情,上面跑著數(shù)據(jù)庫(kù)、資源站點(diǎn)、以及所有的業(yè)務(wù)站點(diǎn).

?

2、網(wǎng)站發(fā)展的第二階段

這個(gè)時(shí)候訪問(wèn)量開(kāi)始增加,發(fā)現(xiàn)服務(wù)器的資源不夠用了,用戶體驗(yàn)越來(lái)越差,所以,第一想法,升級(jí)服務(wù)器配置.ok,暫時(shí)解決了問(wèn)題,站點(diǎn)又能提供穩(wěn)定且高效的服務(wù).

?

3、網(wǎng)站發(fā)展的第三階段

訪問(wèn)量持續(xù)增加,這個(gè)時(shí)候升級(jí)服務(wù)器的配置所產(chǎn)生的代價(jià)太大,而且,就算繼續(xù)升級(jí)也無(wú)法解決本質(zhì)的問(wèn)題,所以開(kāi)始考慮其它的方案!

很簡(jiǎn)單,將業(yè)務(wù)和數(shù)據(jù)分離,將業(yè)務(wù)站點(diǎn)和數(shù)據(jù)庫(kù)和資源站點(diǎn)分開(kāi),如下架構(gòu):

這里需要注意:業(yè)務(wù)站點(diǎn)需要處理大量的業(yè)務(wù)邏輯,所以CPU的性能一定要高,文件服務(wù)器則需要大一點(diǎn)的硬盤(pán),數(shù)據(jù)庫(kù)服務(wù)器則需要更快的硬盤(pán)和更大的內(nèi)存.

ok,問(wèn)題又解決了,站點(diǎn)又能提供穩(wěn)定且高效的服務(wù).

?

4、網(wǎng)站發(fā)展的第四階段

訪問(wèn)量持續(xù)增加,單臺(tái)應(yīng)用服務(wù)器的IIS線程并發(fā)連接有限,而且隨著用戶的上升開(kāi)始出現(xiàn)超時(shí),異常,直至站點(diǎn)崩潰.所以必須解決這個(gè)問(wèn)題.

ok,增加應(yīng)用服務(wù)器,實(shí)現(xiàn)小集群(每次加一臺(tái)),上nginx(關(guān)于nginx不了解請(qǐng)參考Nginx),做反向代理,分發(fā)用戶的請(qǐng)求到不同的應(yīng)用服務(wù)器,如果涉及登陸做下Ip_Hash.

ok,問(wèn)題又解決了,站點(diǎn)又能提供穩(wěn)定且高效的服務(wù).

?

5、網(wǎng)站發(fā)展的第五階段

訪問(wèn)量持續(xù)增加,應(yīng)用服務(wù)器也越來(lái)越多,數(shù)據(jù)庫(kù)的壓力越來(lái)越大,而且數(shù)據(jù)隨著用戶的上升爆發(fā)時(shí)的增加,數(shù)據(jù)庫(kù)面臨了性能瓶頸,因?yàn)閱伪頂?shù)據(jù)的上升,所以必須分表,提升查詢的速度.所以必須開(kāi)始動(dòng)數(shù)據(jù)庫(kù)了.

第一步:實(shí)現(xiàn)數(shù)據(jù)庫(kù)的讀寫(xiě)分離,主要是配置,網(wǎng)商有很多文章,自行參考

第二步:分庫(kù)分表

?

6、關(guān)于分庫(kù)分表常用的設(shè)計(jì)思路

按時(shí)間、按地區(qū)(IP)、按業(yè)務(wù)進(jìn)行劃分,無(wú)外乎這三種方式.下面簡(jiǎn)單的介紹個(gè)例子,假設(shè)站點(diǎn)是個(gè)登陸站點(diǎn),主要分為QQ登陸和微信登陸,站點(diǎn)需要記錄每次用戶的登陸的一些信息.

假設(shè)每天有10萬(wàn)用戶登陸.做過(guò)單表10萬(wàn)數(shù)據(jù)查詢的知道,不加索引的情況下,還是有點(diǎn)慢的.所以我們需要對(duì)這個(gè)登陸記錄表進(jìn)行拆分.第一步按QQ登陸和微信登陸進(jìn)行分庫(kù),將通過(guò)QQ登陸的用戶登陸信息存儲(chǔ)到QQ登陸庫(kù),微信同理,這樣每個(gè)庫(kù)每天承擔(dān)5萬(wàn)的寫(xiě)操作.

但是單表5萬(wàn)記錄查詢還是有點(diǎn)慢,這個(gè)時(shí)候還可以進(jìn)行細(xì)分,比如按用戶Id,進(jìn)行拆封按用戶Id拆分一般有兩種(用戶Id算法):

(1)、如果Id是int整數(shù)(如SqlServer的自增Id)，可以采用Id%10取余算法,找到目標(biāo)表。采用這種算法,那么原先的單表被拆封成0~9十個(gè)表,每個(gè)表承擔(dān)5000的寫(xiě)操作,這樣壓力瞬間就下來(lái)了

(2)、如果Id是Guid(長(zhǎng)度固定,全大寫(xiě)),獲取最后1個(gè)字母,找到目標(biāo)表,采用這種算法,那么原先的單表被拆封成A-Z36個(gè)表,每個(gè)表承擔(dān)寫(xiě)壓力就更小了.

上面兩個(gè)都可取,但是可以根據(jù)具體的業(yè)務(wù)酌情選擇.

目前為止,解決了單天的性能瓶頸,但是每天都有10萬(wàn)數(shù)據(jù)進(jìn)來(lái),肯定是不行的,所以按照上面的思路每天的數(shù)據(jù)必須在當(dāng)前被清空,因?yàn)椴磺蹇?隨著數(shù)據(jù)每天加10萬(wàn)的操作,查詢到最后還是受不了.

所以必須寫(xiě)個(gè)定時(shí)服務(wù),每天在業(yè)務(wù)低峰期清除QQ登陸信息庫(kù)和微信登陸信息庫(kù)的數(shù)據(jù),清楚的同時(shí)將它們遷移到對(duì)應(yīng)QQ登陸信息歷史庫(kù)和微信登陸歷史庫(kù)中,關(guān)于歷史庫(kù)的構(gòu)建就需要仔細(xì)考慮了.

考慮了幾種方案:

(1)、就兩個(gè)歷史庫(kù)(微信登陸歷史庫(kù)和QQ登陸歷史庫(kù)),直接Pass,每天10萬(wàn)數(shù)據(jù)的遞增,不用一年就直接崩了.

(2)、按年分庫(kù) 月+日+用戶Id 進(jìn)行分表 直接Pass,這個(gè)方案會(huì)產(chǎn)生大概3600個(gè)表

(3)、權(quán)衡考慮采用按年分庫(kù) 月+用戶Id 進(jìn)行分表 如果用戶Id采用用戶Id算法的第一種,那么會(huì)產(chǎn)生大概120個(gè)表.

確定好歷史庫(kù)設(shè)計(jì)方案之后,將每天的登陸信息記錄同步到對(duì)應(yīng)的歷史庫(kù)中.

?

轉(zhuǎn)載于:https://www.cnblogs.com/GreenLeaves/p/10053935.html

總結(jié)

以上是生活随笔為你收集整理的基于.Net + SqlServer的分库分表设计方案的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。