Daly的游戏人生

@ZealotYin
嗯,是这个意思。另外两次snapshot保存之间如果crash会丢数据,binlog可以保证恢复。
以前设计过这样的方案, 也是一种常见的id分配方案了。

这个方案的短板在于:分配能力受DB处理能力限制,单点故障问题,另外这个SepTab表的数据至关重要,数据要从一而终,不能容许任何闪失。

利用划分号段的方法,比方说:server_id * 1000000 + local increment也是一种不错的解决方案。全球手机号码分配,IP分配也就是这么干嘛。
这方案的缺点是玩家最大ID数会受限制,而且所有玩家id长度相等,视乎你的玩家规模了。
@谭军
一般用epoll等event驱动的典型写法是,listen的fd有读事件,那么在回调函数里就会accept一个新socket, 如果是 while(true) { accept() }不断接受新连接, 就有可能被攻击。假如管理socket的容器没有加上限,就会爆满。
同感啊。不过现在关于经验记录都在evernote上面了。总结性强的才摆上博客。
@zuhd

当数据变化写binlog的顺序IO大到一定程度,则系统性能更糟糕(就是diff的数据量大于数据snapshot本身), 这个做法就不适合。所以要考虑数据规模,数据变化频率等因素。
@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一般是单独的线程或进程,要注意数据一致性等等细节,要详细验证。