。哇塞，你真是太偉大了，你的系統越來越健壯了，連單一伺服器崩潰都無法阻擋你的前進了，而且你的共享記憶體大小是恆定的，連記憶體碎片都只有對你嘆息的份了，它們也奈何不了你了。真棒！那麼，聰明的你，可否讓我們更完美一些呢？答案當然是可能的。那麼，這個思路看上去**還有瑕疵呢？對了，就是共享記憶體本身，因為我的遊戲伺服器需要修改玩家資料，那樣肯定是會修改共享記憶體的資料。而我的定時程序，也會寫我的共享記憶體（比如標記儲存成功的時間戳）。好傢伙，我有不好的預感。多執行緒讀寫共享記憶體，如果兩個程序同一時刻一起寫乙個位置，程式必崩無疑。這個傢伙太討厭了，我不能讓他阻擋我。我要解決你！讓我再去谷歌一下，我現在覺得谷歌上肯定有很多朋友遇到和我一樣的問題。恩，什麼，共享記憶體鎖？訊號量？這個真給我雪中送炭啊。不過，等等，再讓我看看，什麼，這個鎖會降低系統的效能？也是，多執行緒共享資源，哪個鎖能不降低效能呢？怎麼辦，我要完美，完美！不用鎖，把伺服器的效能體現到最強！有辦法嗎？有辦法嗎？在無數次糾結之後，我忽然想到，如果我把共享記憶體乙份玩家資料，分為頭+體。頭由定時程序進行修改，體由遊戲伺服器本身修改。那麼，會有改善嗎？對於遊戲伺服器，我對資料頭唯讀不寫，對體只寫。定時伺服器我對頭只寫，對體唯讀。只要指標點不同，那麼是否就能繞開鎖呢？我要保證同一時刻，就算都寫，只寫乙個地方。ok。如果你也想到了，證明你比我聰明多了，因為我想這個用了2天時間，呵呵。
(方案6)
伺服器啟動的時候，開始遍歷資料庫，一口氣把最後登入過的5000個活躍使用者資料資料，載入到共享記憶體中，然後遊戲伺服器從中讀取，如果沒有，那麼從介質（資料庫或者檔案）中載入進來，放入共享記憶體，然後我們啟動乙個程式，這個程式**很簡單，定時將共享記憶體的資料刷入介質（資料庫或者檔案）中，在伺服器對共享記憶體訪問上，新增乙個層，負責mru演算法
。共享記憶體乙個使用者資料單元分為頭和體，對於遊戲伺服器，只關心"體"就行了。對於儲存伺服器，它關心的是"頭"。雙寫入錯誤，你拿我也沒辦法了吧。哈哈。哦，對了，可能機智的你會問，你這個想法依舊不完美，如果我的遊戲伺服器正在寫還沒寫完，這時候你的儲存程序恰好在儲存，豈不會儲存乙個"半截"的髒資料？是的，說的好，關於這個問題，我的想法是，我的儲存服務，每次都採用memcpy的方法把資料取出來。那麼你肯定會辯駁，別蒙我！memcpy會被執行緒打斷，ok，沒錯，不過，要符合玩家資料正在修改+儲存服務正在存這個資料+memcpy正好拷貝到這個點。機率並不大，那麼，就算發生了，你的資料5分鐘後還會恰好在這裡嗎？如果次次都遇到，說明你要去買彩票了。髒資料會存在，那麼我能控制在一段時間後會被健康的資料覆蓋，就行了。
寫到這裡，大家肯定知道了乙個思路，下面，就讓我用**來給大家說明一下，畢竟，百說不如一練，寫出來才算本事！
好，下一章，我來講講怎麼實現，當然，個人偏好，我用我的開源服務框架實現這個體系吧。
原文：
mysql資料伺服器 手動配置資料伺服器mysql
1.mysql檔案和資料夾 linux 配置檔案檔案字尾為cnf bin 放可執行性檔案 include 存放標頭檔案 lib 存放庫檔案 share 存放字符集，語言等資訊 my.ini mysql軟體正在使用的配置檔案 my huge.ini 當mysql軟體為超大型資料庫時使用的配置檔案 my...
redis mysql遊戲資料伺服器
資料伺服器在設計上採用三個層次的資料同步，實現玩家資料的高速獲取和修改。資料層次上分為 記憶體資料，redis 資料，mysql 資料設計目的 首先保證資料的可靠，防止資料丟失，保證資料完整。然後實現資料的高速訪問，減少由玩家數量增加對資料伺服器效能造成的影響。最後實現運維資料的入庫，以及資料持久化...
AIX RAC資料伺服器開關機流程
aix rac資料伺服器開關機流程 簡介機器型號為ibm p750 管理位址為 10.和10.採用rac 集群方式進行資料庫的管理。目前資料庫擁有兩個資料庫例項分別為 db1和db2。開關機流程 開機流程 1 開啟電源，通過 hmc控制台啟用分割槽，啟動機器。2 lspv 3 smit clstar...