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