项目经验-王红波_2006年中国首届杰出数据库工程师 王红波

项目一：数据库实时同步

项目简介（功能与用途）：

功能：将系统平台需要访问或者产生的数据每10分钟写入备份数据库上。

用途：由于备份数据库和系统数据库的结构完全相同，在数据库服务器发生灾难性破坏时，可以将数据库访问指向备份数据库服务器。

说明：一方面弥补全备份和差异备份的时间连贯性不够，另一方面也在最短的时间恢复平台的正常运行。

项目难点与解决方案：

难点：数据量大，读出和写入的频率非常高。操作最频繁的地方数据量最大，高达2000多万的数据量。同时，数据同步非常消耗系统性能，况且单位时间产生的数据量非常大，所以要预先估计数据库服务器的负载能力。另外，数据同步随着时间的偏移，可能会有些数据不能真实的同步。

解决方案：

数据产生的数量大，就要进行测试还判断多少时间来同步一次才不至于影响了服务器的正常工作。

关于数据同步的可靠性，相关的技术文档并没有提过ms sql server的数据复制会100%正确。所以需要定期生成快照，重新初始化所有数据。这样才能尽量保证数据的正确性。

经过多次测试后，我选择的是事物复制，因为它可以满足实时的特征，然后选择每周初始化一次备份数据库，因为初始化的时候，需要重新生成快照，数据库的数据量又很大，并且服务器上是有几十个数据库相互关联，所以生成快照的时候最容易让锁升级成库锁，从而让数据库服务器停止响应。

项目成功与失败的经验归纳：

我做这个同步的时候，查阅了网上的朋友做过的类似的工作。找了几篇相关的文章出来。但似乎这文章要么是用触发器来实现，要么是复制了微软相关的文档，并没有经过自己的实践。所以文章中提到了有些东西，服务运行的帐号，和服务器之间的信任关系，这些实际上分散了实施人员的精力，我测试后发现这些其实是不需要必备的东西。我最初做这个任务的时候，设置的是每天初始化一次备份数据库，所以会出现锁死的现象，数据库的正常运行，在出现阻塞的时候，会不断让锁升级，当库锁发生的时候，系统尽管会牺牲部分事物，但短时间是无法恢复的。所以我选择了1周初始化一次，并且系统中的多个数据库分散在不同的日期。

你在项目中岗位与贡献：

独立完成。现在同步运行的很好，并且对数据库服务器的正常运行没造成破坏。很好地保障了

平台对对数据的要求。

项目二：用户表扩容

项目简介（功能与用途）：

功能：保障用户量升级为目前数量10倍的时候，系统依然可以平稳运行。

用途：满足平台运行需要，在线人数在突破性增长，需要提前做好准备。

项目难点与解决方法：

由于平台属于游戏平台，对用户基本信息的操作非常频繁，尤其是在线人数很高的时候。对于一个用户信息表来讲，当它的数据量超过500万的时候，性能会明显下降。现在已经约400万的信息，目前是靠删除部分过期帐号来保持。但是每天新增用户的数量越来越大，必须要让数据库对用户信息的处理方式在结构上调整，来满足平台的需要。

难点：该数据库服务器同时跑两个数据库实例。每个实例约25个数据库。服务器是4cpu, 3G 内存。所以要尽可能做到最优化的结构，以最小的硬件需要来满足最大的数据操作需要。

我首先是参考了各个大型网络游戏对用户信息的处理方式。主要是两种方式：一种是直接做数据库群集，以最大化的硬件条件来彻底解决性能限制。第二种是分表，将用户归类，这就体现在网游的登陆需要选择登陆区这个地方了。他们把用户基本限制在某个固定的区域，跨区域的很少，所以就相当于把数据需要都分散了，这样做的好处很明显，一个1000万的表容易发生阻塞，但分成三个300万的表就几乎不可能阻塞了。

解决方安：显然，做群集现在不行，没有这个硬件条件是主要因素，况且平台底层所划分的结构也需要进行调整。现在的要求单方面从数据库调整来对用户容量进行扩展。然后我考虑的是使用分表的方式，那么如果像其他游戏那样对用户进行分区登陆，现在也不行，因为那也需要修改游戏运行的平台。所以分区登陆，只能存在于数据库的逻辑中，对游戏平台和游戏用户来讲，应该是透明的才对。那么在数据库中对用户进行分类，存储在不同的表中，就有个问题，用户的唯一标志怎么处理。所有的游戏数据库，全都会给每个帐号一个唯一ID,并且是自增长这样的ID,如果划分成多个表那么这个ID该怎么处理。这一步的操作必须保证用户ID是由同一接口生成才行。经过思考后，我决定在逻辑上给用户一个新的唯一标志，做一个游戏通行证。 那么这个通行证表，只保留用户的逻辑区编号和用户的ID，当然，用户的ID就改成在这里生成。然后根据范围，交到不同的分区用户表，他们的相关处理流程，也根据ID值走向各自的处理过程。

项目成功与失败的经验归纳：

尽管我采用的也是分表的思想，我经过考虑后，加上一个游戏通行证之后，就对以后保留了很大个操作空间。现在可以加一个400万的区，需要的时候，再加就很容易，只需要在通行证生成编号的时候再加一个逻辑区，然后在用户信息处理请求接收的接口那里加一个流转方向就可以了，因为所有用户的处理接口实际是一样的，只需要修改对应的表名就可以了。

你在项目中岗位与贡献：

独立设计。（目前该策略还在测试和修改的过程，还没有投入使用）

项目三：数据库性能调优

项目简介（功能与用途）：

检查存储过程在数据库中的操作。优化这些操作，尽可能提高数据操作的性能。避免数据阻塞的出现。不允许库锁的出现。

项目难点与解决方法：

由于游戏平台的特征，现在数据库实例上有三十个用户数据库，现在首先要找出对系统性能影响比较大的操作。如果一个个的数据操作接口进行调试，需要花费的时间很长才能找到主要问题。所以我考虑先找在目前对系统影响最大的接口。那么首先是从数据库中查看当前所有的锁，主要是看表锁，因为几乎所有的库锁都是由表锁升级而来，一般来讲超过1000条记录处理的操作会有表锁，超过10000条的就会有库锁，当然，在实际的情况中，这些是比较隐含的，只能对存储过程这些操作，查看流程，单步调试，在能找出在哪一步消耗的资源最大。所以如果对系统性能影响比较大的话，这个操作一定会引起表锁，那么我可以直接从引起表锁的进程列表中查看，来确定一个比较小的数据操作列表了。可以对这个列表中出现的存储过程进行调试，检查是否比较合理的利用了索引，是否对数据的操作比较合理。

优化的方式还是照一般的方法，就是读操作比较多的，根据查询条件建立索引，写操作多的尽量减少索引。

项目成功与失败的经验归纳：

如果做这个工作的人数比较多的话，实际是应该检查所有的操作，对每一个数据操作就进行细致的调试和优化，但在这样特殊的条件下，没有其他人一起，自己面对大量的存储过程需要分析的情况下，可以按照我的方式，先解决主要问题，就是从数据库反映出的有表级锁的操作来查找问题所在。

你在项目中岗位与贡献：

独立完成。现在系统中已经避免了大数据量的操作，数据库的性能处于很平稳的状态。