re: 基于binlog的游戲數據儲存引擎 Daly 2012-12-07 16:41
@ZealotYin
嗯，是這個意思。另外兩次snapshot保存之間如果crash會丟數據，binlog可以保證恢復。
re: 大區中分配玩家唯一ID的辦法(續) Daly 2012-12-07 13:08
以前設計過這樣的方案, 也是一種常見的id分配方案了。
這個方案的短板在于：分配能力受DB處理能力限制，單點故障問題，另外這個SepTab表的數據至關重要，數據要從一而終，不能容許任何閃失。
利用劃分號段的方法，比方說：server_id * 1000000 + local increment也是一種不錯的解決方案。全球手機號碼分配，IP分配也就是這么干嘛。
這方案的缺點是玩家最大ID數會受限制，而且所有玩家id長度相等，視乎你的玩家規模了。
re: 服務器程序常見bug總結 Daly 2012-12-07 12:31
@譚軍
一般用epoll等event驅動的典型寫法是，listen的fd有讀事件，那么在回調函數里就會accept一個新socket, 如果是 while(true) { accept() }不斷接受新連接, 就有可能被攻擊。假如管理socket的容器沒有加上限，就會爆滿。
re: 開始記錄編程方面的技巧 Daly 2012-07-19 09:31
同感啊。不過現在關于經驗記錄都在evernote上面了。總結性強的才擺上博客。
re: 基于binlog的游戲數據儲存引擎 Daly 2012-07-02 12:43
@zuhd
當數據變化寫binlog的順序IO大到一定程度，則系統性能更糟糕（就是diff的數據量大于數據snapshot本身）, 這個做法就不適合。所以要考慮數據規模，數據變化頻率等因素。
re: 基于binlog的游戲數據儲存引擎 Daly 2012-07-02 12:39
@zuhd
其實snapshot的保存還是需要的，只是用來binlog可以大大延長存盤間隔。
主要缺陷是：
1. 如果熱數據很多，并且很頻繁。binlog文件增長非常快, 硬盤很容易吃滿. 對于熱數據量大的項目不合適
2. 要勾住項目里的k-v變化, 對引用型的復雜類型(map或list)，有可能會漏掉。如果代碼里的k-v set都是用統一接口，則問題不大。
3. 要對復雜類型(map或list)的改變定義opcode比較難，要依賴于具體數據意義做opcode的定義，不然要整個map給dump下去，太耗了。
4. 這個binlog系統的opcode由于是高度定制，不同項目間不具有移植性。
5. 寫log一般是單獨的線程或進程，要注意數據一致性等等細節，要詳細驗證。