起因

這段時(shí)間我們游戲在持續(xù)推廣，每天數(shù)萬(wàn)的玩家注冊(cè)，服務(wù)器壓力增加得很快。雖然我們服務(wù)器進(jìn)程可以多開(kāi)，redis用的是集群版，也可以水平擴(kuò)展，但數(shù)據(jù)庫(kù)不是，一直是只有一個(gè)數(shù)據(jù)庫(kù)在支撐。即便大部分玩家數(shù)據(jù)都存放在redis中，只有redis中的數(shù)據(jù)過(guò)期后才會(huì)去請(qǐng)求數(shù)據(jù)庫(kù)進(jìn)行查詢(xún)，但一樣頂不住人多，現(xiàn)在每天日活躍玩家將近20萬(wàn)，同時(shí)在線(xiàn)接近2萬(wàn)，數(shù)據(jù)庫(kù)壓力還是很大，所以擴(kuò)展成多個(gè)數(shù)據(jù)庫(kù)支持是唯一選擇

思考

原來(lái)只有一個(gè)數(shù)據(jù)庫(kù)，現(xiàn)在要擴(kuò)展多個(gè)數(shù)據(jù)庫(kù)，把新玩家哈希到不同的數(shù)據(jù)庫(kù)上，同時(shí)還要兼容原來(lái)的老玩家，依然能正確讀取，更新其舊數(shù)據(jù)，不能出錯(cuò)

第一種方法

再買(mǎi)2個(gè)數(shù)據(jù)庫(kù)（當(dāng)然也可以買(mǎi)多個(gè)），加上原來(lái)的數(shù)據(jù)庫(kù)，這樣一共有3個(gè)數(shù)據(jù)庫(kù)，新注冊(cè)的玩家根據(jù)playerID對(duì)3進(jìn)行取余，這樣把新玩家的數(shù)據(jù)均勻地哈希到3個(gè)數(shù)據(jù)庫(kù)上，以做負(fù)載均衡。當(dāng)讀取玩家數(shù)據(jù)時(shí)，按照playerID對(duì)3進(jìn)行取余的算法，得到數(shù)據(jù)庫(kù)ID，先嘗試從這個(gè)數(shù)據(jù)庫(kù)里面讀取，如果讀取不到，說(shuō)明是舊玩家，那么再到舊數(shù)據(jù)庫(kù)里面讀取。修改更麻煩一些，因?yàn)橐扰袛嘣谀膫€(gè)數(shù)據(jù)庫(kù)上，然后再進(jìn)行更新。

看似也沒(méi)什么問(wèn)題，既能哈希式地存儲(chǔ)，也能哈希式地讀取

請(qǐng)仔細(xì)想一下，這種方法有什么問(wèn)題嗎？

如果后面數(shù)據(jù)庫(kù)壓力越來(lái)越大，3個(gè)數(shù)據(jù)庫(kù)也不夠了怎么辦呢？只能再買(mǎi)幾個(gè)數(shù)據(jù)庫(kù)，比如5個(gè)，這樣一共有8個(gè)數(shù)據(jù)庫(kù)，進(jìn)行新的哈希算法，新注冊(cè)的玩家根據(jù)playerID對(duì)8進(jìn)行取余，把新玩家的數(shù)據(jù)均勻地哈希到8個(gè)數(shù)據(jù)庫(kù)上。讀取的時(shí)候就麻煩了，因?yàn)橛腥?lèi)不同的玩家了，先對(duì)8取余得到一個(gè)數(shù)據(jù)庫(kù)進(jìn)行查詢(xún)，沒(méi)有的話(huà)再對(duì)3進(jìn)行取余進(jìn)行查詢(xún)，仍然沒(méi)有的話(huà)再到最舊的數(shù)據(jù)庫(kù)上進(jìn)行查詢(xún)。讀取更新玩家數(shù)據(jù)的話(huà)就更痛苦了，要進(jìn)行多次哈希算法庫(kù)判斷到底在哪個(gè)數(shù)據(jù)庫(kù)上，找到后才能進(jìn)行更新，數(shù)據(jù)庫(kù)操作需要多次

看到了吧，每擴(kuò)展一次數(shù)據(jù)庫(kù)，讀取玩家數(shù)據(jù)的時(shí)候就要多嘗試一次DB

想一想，讀取，更新玩家數(shù)據(jù)庫(kù)的地方有很多，每次都這么麻煩的判斷，累也累死了

（有個(gè)優(yōu)化點(diǎn)，我們可以記錄下來(lái)分界點(diǎn)玩家ID，歸于哪個(gè)時(shí)間段生成的，在這個(gè)時(shí)間段內(nèi)的玩家都是用一種算法，比如playerID在1~M之間的玩家直接到舊的數(shù)據(jù)庫(kù)上查詢(xún)，playerID在M~N之間的玩家直接對(duì)3進(jìn)行取余后到對(duì)應(yīng)的數(shù)據(jù)庫(kù)上進(jìn)行操作，playerID在N之后的玩家對(duì)8進(jìn)行取余后到對(duì)應(yīng)的數(shù)據(jù)庫(kù)上進(jìn)行操作。這個(gè)M，N可以提前在代碼里面定好，玩家注冊(cè)的時(shí)候也根據(jù)M，N進(jìn)行不同的哈希算法。但是缺點(diǎn)也有，那就是M，N的預(yù)估不能出錯(cuò)，而且沒(méi)法測(cè)試，一旦啟用了這個(gè)規(guī)則，玩家數(shù)據(jù)就會(huì)被自動(dòng)歸類(lèi)，出錯(cuò)就完蛋了。而且再擴(kuò)展一次數(shù)據(jù)庫(kù)的話(huà)要在所有選擇數(shù)據(jù)庫(kù)的地方修改一遍，吐血到死）

問(wèn)題在哪里呢？

答案：擴(kuò)展數(shù)據(jù)后，讀取更新玩家數(shù)據(jù)時(shí)的算法嚴(yán)重依賴(lài)生成數(shù)據(jù)時(shí)的算法，二者必須一樣也就是高耦合，因?yàn)橛信f數(shù)據(jù)，只能多次哈希后判斷在不在當(dāng)前數(shù)據(jù)庫(kù)上

所以我們要找到一個(gè)讀取更新數(shù)據(jù)時(shí)，不依賴(lài)于生成數(shù)據(jù)時(shí)算法的辦法，也就是下面方法2

第二種方法

再買(mǎi)N個(gè)數(shù)據(jù)庫(kù)，比如2個(gè)，加上原來(lái)的一個(gè)舊數(shù)據(jù)庫(kù)，一共3個(gè)。仍然采用對(duì)3取余的哈希辦法，把新玩家均衡的撒在3個(gè)數(shù)據(jù)庫(kù)上，但是同時(shí)記錄下新玩家所在的數(shù)據(jù)庫(kù)號(hào)，建議記錄在redis中，這樣最高效。讀取更新玩家數(shù)據(jù)時(shí)，先從redis中查到這個(gè)玩家所在的數(shù)據(jù)庫(kù)號(hào)，再到對(duì)應(yīng)的數(shù)據(jù)庫(kù)上進(jìn)行操作，如果redis中不存在，說(shuō)明是舊玩家那就到舊數(shù)據(jù)庫(kù)中。由于redis的效率超高，每秒達(dá)到10萬(wàn)級(jí)別，相對(duì)于數(shù)據(jù)庫(kù)的操作，這點(diǎn)兒耗時(shí)可以說(shuō)忽略不計(jì)了

這個(gè)辦法有

優(yōu)點(diǎn)

1.?查詢(xún)更新玩家數(shù)據(jù)時(shí)的算法永不需改變，只用先從redis中查找所在數(shù)據(jù)庫(kù)號(hào)，再到對(duì)應(yīng)的數(shù)據(jù)庫(kù)操作即可，永遠(yuǎn)只有一次數(shù)據(jù)庫(kù)操作。redis中查詢(xún)不到說(shuō)明是當(dāng)初沒(méi)有記，直接到舊數(shù)據(jù)庫(kù)查詢(xún)即可

2.?代碼改動(dòng)比較小，只需新玩家記錄下數(shù)據(jù)庫(kù)ID號(hào)，讀取更新數(shù)據(jù)庫(kù)時(shí)根據(jù)redis的值選擇對(duì)應(yīng)的數(shù)據(jù)庫(kù)連接即可

3.?以后再擴(kuò)展數(shù)據(jù)庫(kù)的時(shí)候，只需更改玩家注冊(cè)時(shí)的哈希算法。讀取，更新時(shí)找數(shù)據(jù)庫(kù)的算法不需更新

缺點(diǎn)

1. 需要額外引入redis，且這些數(shù)據(jù)在redis中永久存在

2. 若redis出問(wèn)題導(dǎo)致數(shù)據(jù)丟了，那這些玩家就找不到準(zhǔn)確的歸屬數(shù)據(jù)庫(kù)了。不過(guò)現(xiàn)在云redis的集群模式下，數(shù)據(jù)安全是有保證的。如果你仍然不放心，也可以先到數(shù)據(jù)庫(kù)中保存一份玩家的歸屬數(shù)據(jù)庫(kù)ID，再加載到redis中做長(zhǎng)期保存，這樣更保險(xiǎn)，即使redis中丟了，再到數(shù)據(jù)庫(kù)中查詢(xún)導(dǎo)入即可。由于我們絕大多數(shù)都是查詢(xún)r(jià)edis，數(shù)據(jù)庫(kù)里面只是用來(lái)做備份保險(xiǎn)用，性能不用擔(dān)心

總結(jié)

以上是生活随笔為你收集整理的记一种数据库水平扩展的技巧的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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