正经扯淡

当我还没有游戏开发运营经验时，我领着一班和我一样无甚经验的兄弟们写下最初的游戏程序代码。 出来混，总是要还的。当合服近在眼前时，我发现时间全部花费在了开发和debug上，对合服没有任何思想准备，更谈不上什么工具。让我感到麻烦的是我们的数据库和游戏世界一样是独立的，一服一世界，一服一DB。代表玩家的数据在每个数据库里都是从0依次增长的。这就意味着多组服务器合并，就要把多个数据库里的数据也合并在一起

之前我们向运营要求更多的导入，运营说每每开服导入流量，我们的留存并不高，拒绝更多流量导入。 刚刚完成的压力测试，我发现大量用户在集中时间内涌入服务器，创角进入游戏占用了90%的cpu时间，服务器基本没有cpu资源响应其他。 这是个很严重的问题，第一次的体验决定了这个玩家的感受，决定了游戏的留存。 阅读代码，创角和进入游戏的代码含有不少的同步数据库操作。怎么破？

从事游戏开发也有年头了，许多积累下来的知识和经验并没有做很好的梳理。 之前虽然也零零散散写过一点关于挂机和调试的短文，这次写点关于数据同步的东西。 游戏是个低延时，高并发应用。一般为了提供给用户足够好的体验都会把数据库单独放置一台机器，为的是让游戏进程和数据库进程都能得到充足的资源，都能提供优秀的服务。这也产生了一个问题，如何保证数据库的数据和游戏进程中用户本身没有差别。实际上这个问题一直

如果上次耗时总和小于(World_Sleep_Const+prevSleepTime)，那么小于多少，就睡眠多少，并修改prevSleepTime为小于的数值；否则立刻进入下一轮轮询，并修改prevSleepTime为0。 update的耗时不可能稳定在一个值，表现为时大时小。耗时多，不必睡眠，应该立进入下一次轮询，多余的耗时应该在以后的睡眠时间里扣掉。这样才能在总体上保证每秒20次计算。

branch是功能分支，用来使代码应对不同的需求。 tag是里程碑分支，用来稳定一个相对完整和稳定的版本。 如果要开发一个面向东南亚的产品。典型的做法是从一个功能和特性合适的tag 创建一个branch，东南亚组的开发同学在这个branch上开发。新的功能和特性一般不合并。 如果产品刚刚发布，马上进入了新的开发周期。应该从主干上创建一个分支用作新功能和特性的开发，在新的分支功能特性通

很多应用程序都是写在容器内的。

出来混迟早要还的！ 现代的计算机配置似乎达到了良好运行一切的程度，或者说良好运行大多数。我们期盼的是高速cpu和大内存和io极快的硬盘能解放使用者，使用者不再需要恶补计算机和软件的知识硬着头皮冒充计算机专家调整自己机器这样那样的参数；能解放程序员，程序员能专心于开发消费者真正需要的功能和良好的使用体验，而不是而不是为了运行的快一些，内存使用 何为性能问题 在性能测试中存在两个概念： (