服务器结构整理一些思考（1）

协议路由的设定

每个玩家在引擎的实体的驱动下，每个实体下有包含了玩家的各个属性，有的属性自成系统。在多人的开发模式下，各个系统需要并行开发，相互之间通过消息或接口进行通信。现碰到的设计问题是，client的RPC，如何才能定位到实体下的系统的接口，玩家的每个系统都是与实体相关联的对象，而RPC的方法只能调用到实体，那么，需要实体将方法路由到具体的系统中区，这个过程如何设计才够方便呢？
方法有多种，为了不改变原有client的接口，将路由的标识放到RPC的首个参数，不好的方面是增加流量开销，每次消息增加了平均少于10个字符的开销。

#前者是路由，后面是参数，开发者只管参数部分。这种做法要求rpc_function是全局唯一的。
rpc_function = ['route_module'] + ['param1', 'param2','param3']

当server收到rpc_function，参数被序列化为{‘param1’: ‘v1’, ‘param2’:’v2’, ‘param3’:’v3’}，rpc_function[0]是决定路由模块的索引。

重复提交问题

考虑几种极端的情况下，比如，client发起购买道具请求（记录为A），server收到并处理返回，但是，返回结果丢失。client进行每次RPC请求相当于一次业务，要么成功，要么失败（包括超时）。当A发送超时，在没有通知用户的情况下（是否由用户来触发本次请求？），发起重复的RPC请求，server收到重复的RPC请求，认为是重复请求，于是，不做处理，将上次的请求结果发送给client，保证用户触发的请求RPC是唯一的，client进行重试时，可能导致重复，即使出现重复，那么，服务器做了处理。
如果要考虑断网情况，就需要保证数据存储。

对象间的访问

通过消息机制，不相互调用对方的接口。

#请求某个对象的某个属性
def get_obj_attr(name, attr):
    return self._avatar.objs[name].get(attr)
#设置某个对象属性信息
def set_obj_attr(name, attr, value):
    self._avatar.objs[name][attr] = value

定时存储

在每个储存的tick时刻，收集每个obj的需要persistent的数据，确认是否更新，写入database，回调失败或成功结果。

def persistent(self):
    persist = {}
    persist  = self.need_to_persistent()
    for _name, obj in self.objs.iteritems():
        persist.update(obj.need_to_persistent())
    self.persistent_to_database()

每次从各个obj中拿到需要更新的数据，然后save，保证上次save完成之后，才可以进行下一次的数据存储save

即时存储

某个obj的更新可能会关联到其他多个对象的更新，若采用通知各个obj去完成数据的即时存储，会导致对database的多次更新操作，这是可以优化的，简化为在触发的obj进行一次归结写入，写入成功之后，通知各个相关的obj更新内存中的数据就可以，接着通知client更新，这个过程除了写入database通过回调异步之外，其他都是同步的。