History

  • 历史

写程序一开始，我就对检查状态并修改数据感到很困惑。特别是程序复杂分模块以后， 此时检查所有的状态，最后修改数据，就需要每个模块状态检查代码提取出来提前一起判断。 所以一直希望能有个事务环境，在碰到状态不正确时，回滚所有的修改，把数据 恢复到 开始的时候。2007年的时候，开始做游戏，就用java写了个xdb，在程序中支持事务。这 个版本在需要访问数据时，马上加锁。由于访问数据的顺序跟逻辑相关，就有可能死锁。当 时的解决方法是使用java的死锁检测，发现死锁就打断重做。或者程序员在一个事务 开 始的时候把所有需要访问的数据的锁都提前（这是可以排序）锁上。

  • 死锁就成为xdb最大的问题，也是xdb不大好用的地方。

2013年的时候，当时的同事 pirunxi 提出了乐观锁：所有的数据修改先仅在本事务中 可见，执行完了以后（此时可以知道所有的数据，就可以排序加锁，就不会死锁了），加锁 和判断数据状态，不冲突的话，事务成功，冲突的话保持已有的锁重做。这个方案解决了死 锁问题，系统易用性大大提升。

  • 在2014-2017年间，pirunxi 实现了好多个基于乐观锁的版本。

  • 我大概是2015年开始参与讨论。
  • 今年（2020）新冠疫情期间

老婆孩子不在身边，我闲着没事。一次就问了 pirunxi 最新版本的情况。 然后（闲着没事）就写了 Zeze 这个版本， 这是我的第一个 c# 程序。正如当时xdb是我的第一个java程序。

  • 同一个世界同一个梦想（2008）

不是很喜欢游戏分组的做法。当前很多游戏运营商把不断开新服合并旧服当作一种运营 策略，用来增加玩家游戏时间，这种情况下使用可以按单个独立GameServer模式使用Zeze， 或者按小规模分布式的模式使用Zeze。当需要全球同服这种运营模式时，就能充分利用Zeze 的分布式架构。有了Zeze分布式事务，就能更接近同一个世界同一个梦想。当然由于一些 国家的法律法规限制，不能实现全球同服。这个即时我当了联合国秘书长也是解决不了的。 也许瓦肯人的出现能解决这个问题。