关于网络游戏开发的数据架构以及事务架构的思考。。。

数据架构包含两种数据的架构：一种是持久化数据的架构；一种是服务数据的架构。

持久化数据架构意指与持久化相关的数据架构。好比，哪些数据须要持久化，怎么持久化，在哪里持久化，何时持久化。对游戏的服务器来讲，是持久层的问题。

服务数据架构指的是与用来服务的数据的架构。是从运行时的角度出发考虑的数据架构。即：我须要怎样的数据服务。

由于对于游戏来讲，服务器最主要的工做就是在线处理。而“在线处理”的对象即数据。数据是整个服务器的中心。在整个服务器中，除去一些逻辑操做，剩下的就只是数据服务了。

而在数据服务的过程当中，有时须要对数据进行持久化，有时不须要。这就引出了另外一个问题：系统在哪里？由于，假设系统在某一个时段中历来未曾进行过或只进行过不多的持久化操做，那么，我甚至能够把数据库或文件系统当作是系统的一个附属件。

从另外一个角度看，系统的逻辑其实都在应用服务器里面。这一点在专家系统或规则引擎中其实表现得更为明显：逻辑所有在规则引擎中。这时候，我甚至能够认为规则引擎就是系统。系统的其他部分，均可以被当作是规则引擎的延伸。好比，一些具体的BEAN类以及对它们的持久化，缓存，事务化，以及负责通讯的消息模块，负责分布式实现的底层模块，状态管理模块。

ANYWAY。。。若是系统在应用服务器，那么毫无疑问的是，数据也应该在应用服务器。至少大部分或主要数据，应该都是放在应用服务器上面或至少应该在应用服务器上存在一个拷贝的。由于，若是每次系统都去数据库拿数据，那就暗示着数据库在系统中占有更重要的地位。而实际上却并不是如此的。数据库能作的其实只有持久化。它不能完成任何持久化之外的工做如数据服务。数据服务每每是经过持久层与数据库进行通讯之后才能往上提供的。所以显然，数据服务的工做应该放在也的确正在被放在，也只能被放在，系统的持久层上。也就是说，数据服务的工做，不管如何，都是在应用服务器上面完成的。

。。。

服务器内存，服务器磁盘，数据库或目标文件系统磁盘、内存，以及客户机磁盘与内存，这些东西，是系统可资利用的全部资源。正确的策略，应该是在权衡用户体验的基础上，最大化本地资源利用率的策略！

既然这样，为何不在服务器上作数据缓存呢？将服务器内存转作其它用途，是否能产生更大的效益比呢？

游戏的数据常常只是一点点，而每次数据库查询，依赖于具体的查询次序，可能大部分都会须要一次单独的磁盘IO。若是是这样的话，缓存在大部分状况下应该会好于不缓存。

解决方法：

1，对全部的QUERY进行统计分析。看看到底哪些QUERY的频率高，哪些QUERY的频率低；

2，对全部的系统资源，包括静态资源，动态共享资源，动态非共享资源，进行综合分析。看看哪些能够被缓存，哪些不能够被缓存，能够被缓存的地方，能够被缓存的时间。

3，内容压缩（包括动态与静态内容）；

4，系统优化的目的不在于性能节约，而在于解决高峰问题。提升用户体验。