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一般是单独的线程或进程，要注意数据一致性等等细节，要详细验证。