一、常見的遊戲使用資料庫方式
1、mysql或mongo等關聯式資料庫落地，redis作為快取、排行榜、訊息佇列使用
好處：缺點：程序擴容、更新、down機重啟需要去冷資料庫中重新拉取資料，或者做資料轉移，容易產生效能瓶頸。
如果對資料做快取則會有多份資料同時存在，容易導致資料不一致問題。還有快取穿透現象。
特別是全區全服遊戲，資料庫壓力較大。利用共享記憶體快取資料，程序更新、重啟直接從共享記憶體中載入資料。
好處：缺點：
資料儲存多份、需要自己寫擴容邏輯、資料路由也比較麻煩。
好處：
效能高，不需要關心擴縮容，資料路由問題。
解放程式設計師心智，可以花更多精力在玩法、場景等遊戲核心體驗上。
缺點：全redis方案在網際網路行業不流行，程式設計師接受度較低，或者直接沒考慮過這種用法。
無法自定義資料結構。
二、redis能為遊戲帶來哪些好處
遊戲中的玩家資料其讀寫都是有明顯的約束的—玩家id。redis這種資料庫和遊戲可以說是天作之和，非常適合用來儲存遊戲資料。
1、高效能、高可靠性
單redis例項每秒可以達到10萬+qps，近似本地記憶體的效能。
據了解還沒有因為redis本身的bug造成過遊戲down機，或者redis自身down機情況。
2、資料結構、介面豐富、不需要提前配置資料結構
zlist:排行榜
hash:
set:
除了需要強關係查詢的功能，基本都可以找到實現方案。
最後還有萬金油lua，涉及到事務，自定義操作都可以通過lua實現。
3、託管絕大部分資料，取代掉遊戲中大部分的狀態資料
基於redis的高效能與豐富的資料結構，可以將遊戲絕大部分資料放入redis中，程序中只快取變化特頻繁丟失對系統無影響的資料（如對戰中的玩家位置，某次戰鬥中的hp等），系統可以做到隨時重啟、更新、擴容。方便運維、減少各種原因導致的停機對遊戲體驗的的影響。
三、redis目前存在的問題
1、擴容困難
官方集群方案對客戶端不透明。
2、落地方式比較粗糙
rdb全量落地、利用系統cow特性，fork子程序進行落地。需要兩倍的記憶體容量。
aof實時落地
3、資料無法回滾到任意時間點
rdb落地間隔較長，aof格式中沒有時間戳。回滾只能回滾到大概的時間節點，不能保證強一致性。
4、資料全存記憶體中
成本較高，機器有問題則資料丟失，利用rdb與aof載入資料需要時間較長。
5、單執行緒
單執行緒避免了執行緒切換和競態產生的消耗。但是對於每個命令的執行時間有要求。如果某個命令執行時間過長會造成其它命令的阻塞。
我們需要的redis:
四、自動化運維、平滑擴容、高可用
1、自動申請、部署redis系統
2、通過**實現集群功能、**和後端的redis都可以平滑擴容
3、**遮蔽後端redis例項的主從切換
4、日誌功能的二次開發，必要的情況下可以回滾到任意時間點
五、全面的監控預警系統
1、zset,list元素個數，熱key，大key，慢查詢
有的時候開發會將大量資料儲存在乙個key中，造成key的資料量太大，容易造成系統阻塞。
通過監控熱key可以找出系統單點瓶頸。比如乙個全區排行榜操作太頻繁造成系統卡頓。可以實時告警，為開發優化系統提供建議。
大key和慢查詢是各種資料中基本的監控項。
六、冷熱自動分離
1、冷資料淘汰出記憶體，存入硬碟
2、自動備份、擴容
3、方便好用的日誌，資料匯出等周邊工具
安利一波TabNine
外網上看到tabnine的推薦，安裝試了一下，剛開始覺得幫助不大，乙個上午的使用之後就發現真的太ai了，我tornado習慣手寫sql語句，tabnine能夠幫助我直接補全模板。當然好處不止這些，使用的越久，他的深度學習演算法越能夠掌握你的 風格，自動幫你補全 我使用的intellij系的ide，此...
C語言安利一波函式封裝
最近學弟學妹們在寫聊天室，期間遇到了很多問題，也 逼迫 我們這些大二 其實即將大三 狗考慮了許多以前沒有考慮過的東西。現在就著我們小組的聊天室的專案，送給學弟學妹們 幾個可能安全的封裝函式。ssize t sendlen int fd,const void buf,size t len,int fl...
vector理解一波
vector 標頭檔案 include using namespacestd 定義 vector 型別 q 類同於 型別 q vector 型別 q 1010 類同於 型別 q 1010 操作 往vector存入乙個個資料 函式名 w.push back 資料 include include usi...