一、玩家數(shù)據(jù)在redis與mysql之間的同步
由于redis操作可以保證多個(gè)進(jìn)程讀寫同一個(gè)玩家數(shù)據(jù)時(shí)的原子性。所以之前多個(gè)邏輯服務(wù)器讀寫同一玩家數(shù)據(jù)時(shí)沒(méi)有什么問(wèn)題，但是現(xiàn)在redis和mysql之間需要同步玩家的數(shù)據(jù)（例如定時(shí)將redis里的在線玩家數(shù)據(jù)刷進(jìn)mysql里做持久化）。這個(gè)同步的邏輯代碼放哪呢？
觀察需求特性，玩家上線加載到redis做cache、定時(shí)更新持久層、玩家離線時(shí)清掉cache并更新到持久層，都是redis和mysql之間的數(shù)據(jù)交互。這些可以放到一個(gè)服務(wù)里，單進(jìn)程實(shí)現(xiàn)，或者集成到現(xiàn)在的邏輯服務(wù)器里。
方便實(shí)現(xiàn)，做下限制。玩家登陸的邏輯服務(wù)器記為他的owner服務(wù)器，每個(gè)玩家數(shù)據(jù)的redis/mysql同步只由他owner來(lái)做。 這樣問(wèn)題就簡(jiǎn)化了。
這里有些做法是突然想到的，就像《暗時(shí)間》里提到的聯(lián)想式的，而不是歸納演繹的。最近在看《暗時(shí)間》，好書，里邊就提到邊寫邊思考，思考時(shí)“大腦內(nèi)存”有上限的，邊寫就能把部分思考分支換出筆記這種“硬盤”上，然后大腦專心思考其中一兩個(gè)分支，想的差不多，再回過(guò)頭將“筆記硬盤”上的數(shù)據(jù)換入“大腦內(nèi)存”……將正在思考的東西寫博客的習(xí)慣已經(jīng)形成一段時(shí)間了，看了書后，更深切體會(huì)到這種好處。
如果邏輯服務(wù)器宕機(jī)，它上邊的玩家就掉線了，而這臺(tái)邏輯服務(wù)器是不能對(duì)這些玩家做離線數(shù)據(jù)持久化的。這種情況需要進(jìn)一步思考TODO。另外之前這種玩家怎么標(biāo)記為離線，需要再想一遍，也TODO了。
二、從本質(zhì)出發(fā)review我們的存儲(chǔ)架構(gòu)
不要走的太遠(yuǎn)而忘了為什么出發(fā)，從本質(zhì)上思考，棄掉那些不必要的思考分支，簡(jiǎn)化問(wèn)題。
本質(zhì)我們的架構(gòu)是為實(shí)現(xiàn)游戲的玩法目標(biāo)來(lái)做的，另一方面我們考慮開發(fā)成本、維護(hù)成本、機(jī)器成本。好的架構(gòu)是權(quán)衡目標(biāo)實(shí)現(xiàn)程度和這些成本的耗費(fèi)。
目標(biāo)是實(shí)現(xiàn)同一國(guó)家的玩家不分區(qū)分服。之前緩存和持久化都是用redis來(lái)做，開發(fā)成本和維護(hù)成本都挺低的。但是需要很多機(jī)器。現(xiàn)在控制機(jī)器成本，所以需要分析我們數(shù)據(jù)的特點(diǎn)，將冷數(shù)據(jù)放到mysql這種機(jī)器需求量少的數(shù)據(jù)庫(kù)。具體到表的分析這里就不方便貼了。說(shuō)下大概分類：
（1）離線玩家的冷數(shù)據(jù)，離線玩家的私人數(shù)據(jù)，不需也不能與別人交互的；
（2）離線玩家的熱數(shù)據(jù)，例如名字，好友是想看到離線好友的名字的；
（3）在線玩家的一直更新的數(shù)據(jù)，例如經(jīng)驗(yàn)值，游戲貨幣等；
（4）在線玩家的到強(qiáng)實(shí)時(shí)玩法時(shí)才更新的數(shù)據(jù)。
（1）里的數(shù)據(jù)無(wú)疑問(wèn)放在mysql里。（2）里的數(shù)據(jù)還得根據(jù)情況看是否一致放在redis里，即離線的玩家這部分?jǐn)?shù)據(jù)也放在redis里。（3）里的數(shù)據(jù)無(wú)疑問(wèn)在線是放到redis里。（4）里的數(shù)據(jù)可以根據(jù)情況考慮下延遲加載什么的，即玩家上線時(shí)這部分?jǐn)?shù)據(jù)不馬上加載到redis，而是等玩家開始這個(gè)玩法時(shí)才從mysql里加載到redis里。這個(gè)需要考慮這個(gè)玩法的數(shù)據(jù)量以及是否玩家參與度高。
三、擴(kuò)展
先了解mysql單表數(shù)據(jù)上限、然后mysql單庫(kù)上限。這里的上限指不影響效率的上限，而不是物理上限。拿到上限數(shù)據(jù)后，做預(yù)分庫(kù)分表。分庫(kù)分表也要好好想想。
查了下，mysql 5.1里InnoDB引擎表空間最大容量為64TB。在查我們公司服務(wù)器配置表里硬盤，最低有100G的，最高600多G的。
初步確定mysql的sharding和partition為這樣：不同物理機(jī)之間的sharding為分個(gè)大的id段，單個(gè)物理機(jī)上即單庫(kù)內(nèi)的如果表還是很大就做自己的partition。最終看上線怎么定，再定這個(gè)跨機(jī)sharding的id段長(zhǎng)度，至于單機(jī)的partition，對(duì)代碼來(lái)說(shuō)是不需要管的，運(yùn)維根據(jù)性能搞就行了。
先簡(jiǎn)單算下，每人100k，500w人一個(gè)sharding，需要大約500G空間。
四、其他架構(gòu)展望
有單機(jī)內(nèi)容；需要聯(lián)網(wǎng)時(shí)才聯(lián)網(wǎng)；弱聯(lián)網(wǎng)時(shí)弱聯(lián)網(wǎng)，強(qiáng)實(shí)時(shí)時(shí)做強(qiáng)實(shí)時(shí)聯(lián)網(wǎng)。一直糾結(jié)這個(gè)會(huì)不會(huì)影響現(xiàn)在的存儲(chǔ)架構(gòu)，但是想了下，不大影響，變的只是鏈接形式，玩家數(shù)據(jù)處理還是一樣的。