OnlineSvr和OfflineSvr的数据交互有一点讲究。简单以角色的EXP做为交互例子。有一个角色R，在OnlineSvr1上，他的经验值记为EXP；有另外一个角色，是R的好友，记为RF吧，在OnlineSvr2上。这个例子我只考虑R的EXP变化。
交互策略一
流程
1. R登录后，从OfflineSvr获取EXP1。 2. R执行某个行为后，获取了一些EXP，总的EXP就变成了EXP2，OnlineSvr1把EXP2同步到OfflineSvr。 3. 以此同时，OnlineSvr2上的RF获取了OfflineSvr的R的经验值EXP1。接着RF执行对R的某种SNS行为(比如挑战，挑战过程R不知道)，R也可以获取一些经验，R的总经验变成了EXP3，最后OnlineSvr2也会把EXP3同步到OfflineSvr。 注意上面两个步骤是同时进行的，而且谁先同步都不确定。 4. OfflineSvr收到EXP2和EXP3，最终EXP变成EXP2或EXP3都是不对的，有一部分的EXP丢失了。 从上面流程描述可以看出，直接用总量数据进行服务器间数据同步，业务并行时，同步会出错。交互策略二
1. R登录后，从OfflineSvr获取EXP1。
2. R执行某个行为后，获取了一些EXP，总的EXP就变成了EXP2，OnlineSvr1把增加的EXP，就是增量DeltaExp传给到OfflineSvr。 3. 以此同时，OnlineSvr2上的RF获取了OfflineSvr的R的经验值EXP1。接着RF执行对R的某种SNS行为，R也可以获取一些经验，OnlineSvr2也将增加的EXP DeltaEXP3传给OfflineSvr。 4. OfflineSvr收到DeltaEXP2和DeltaEXP3，最终将DeltaEXP2和DeltaEXP3家到EXP1上。 5. OfflineSvr传DeltaEXP3给OnlineSvr1；或者，OnlineSvr1主动获取DeltaEXP3。OnlineSvr1上的EXP1和OfflineSvr保持一致。
交互策略三
交互策略二存在点问题，DeltaEXP如果丢失了，OnlineSvr和OfflineSvr的EXP1将会不一致。对策略二的处理方法做点改进。
1. R登录后，从OfflineSvr获取EXP1。
2. R执行某个行为后，获取了一些EXP，总的EXP就变成了EXP2，OnlineSvr1把EXP2同步到OfflineSvr。
3. 以此同时，OnlineSvr2上的RF获取了OfflineSvr的R的经验值EXP1。接着RF执行对R的某种SNS行为， R也可以获取一些经验，OnlineSvr2将增加的EXP DeltaEXP3传给OfflineSvr。
4. OfflineSvr收到EXP2和DeltaEXP3，最终将EXP1替换成 EXP2，并且把DeltaEXP3保存起来。
5. OnlineSvr1主动获取DeltaEXP3，将DeltaEXP3加到EXP2，又将结果同步到OfflineSvr。
其他问题
这类服务器数据交互，可以归纳为下面三个要素：
1. 基准数据服务器
相同的数据有多份副本在不同服务器上，应用要确定以哪个服务器上为准。基准服务器的确定，是由业务特点决定的，一般哪个服务器数据改变频率最高，就可以以该服务器上的数据为基准数据。这样可以减少服务器间的数据同步或通知的频率，减少流量，减少数据不一致的时间长度。
2. 全量数据同步和增量数据通知
上面的EXP1,2,3就是全量数据，DeltaEXP3就是增量数据。同步全量数据到另外一个服务器，还是通知增量数据，由哪一方是基准数据服务器决定。
3. 服务器对增量数据实时性要求
处理OnlineSvr和OfflineSvr中的数据实时性方法不一样。
OnlineSvr需要及时获取变化数据方法
当位于OnlineSvr2上的其他角色让EXP(EXP是OnlineSvr1上一个角色的EXP)发生变化时，记EXP变化量为DeltaEXP ，OnlineSvr1不能及时知道。 下面是一种比较安全的处理过程：
① OnlineSvr2通知DeltaEXP到OfflineSvr，OfflineSvr保存DeltaEXP。
② OfflineSvr向OnlineSvr1发一个通知，某个角色EXP发生变化了。
③ OnlineSvr1从OfflineSvr取DeltaEXP。
④ DeltaEXP被取走后，OfflineSvr将DeltaEXP清0。