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