-3

我打算使用sql创建一个纸牌游戏引擎，4个人玩家的游戏组成和卡片在一个sql表中，现在每件事都完成了游戏逻辑和积分，每个游戏都由一个单独的sql表管理，玩家能够创建房间

每个房间都应该有一个游戏桌，其中包含每个玩家代表的卡片数据和一个单独的聊天桌

  1. 如果同时运行 1000 场比赛，并且每次打出一张牌，那么就会向服务器发出请求，从玩家牌组中删除一张牌，记录玩家得分和总游戏得分，这可以在单个 sql 数据库中处理吗没有延迟和性能问题？

  2. 我可以为每个游戏室使用全局临时表##sometable，还是必须手动创建表并在游戏结束后删除它们？

  3. 我还想知道将聊天数据存储在单个 sql 表中是否会产生问题，我想到的一件事是将所有打开房间的聊天数据保存在具有游戏 id 列的单个数据表中，但是如果这会带来一些性能问题有成千上万行的聊天数据？

  4. 还有每场比赛的数据库怎么样，那会不会是过度杀戮？

  5. 此类应用程序如何正常管理？

  6. 我必须使用多个服务器并在它们上分发正在运行的游戏吗？

  7. 您对优化此类事情的任何想法
4

4 回答 4

3

您应该考虑使用基于内存的缓存系统（例如 Velocity 或 Memcached）来解决性能问题。

于 2013-01-10T16:50:02.210 回答
1
  1. 是的。关于如何扩展这样的任务的讨论很长。
  2. 你可以。但是您应该考虑一个更智能的模型，即多个游戏发生在一个表中。
  3. 我会使用SQL Server Service Broker进行聊天
  4. 是的。

我建议您将您的问题分解为多个问题，以便专门研究您问题领域某个方面的贡献者可以做出相应的贡献。

我不知道如何PHP工作；但我相当肯定，让许多游戏逻辑发生在客户端会更有效率。为每个游戏动作进行服务器调用是可行的，我的意见只是它不是最理想的。

于 2013-01-10T16:06:59.173 回答
1
  1. 是的，我希望现场玩家在采取行动之前至少有 1 秒的延迟，并且每场比赛一次只有一场比赛在采取行动。因此，对于 1000 场游戏，每秒大约有 1000 笔交易达到峰值。对现代架构没有过多的负担。
  2. 大多数 DBMS 中创建和销毁表的开销更大。把它们都放在同一张桌子上。
  3. 在一张桌子上聊天就可以了。您可以通过归档以前不活跃游戏的聊天并从主实时数据库中删除来保持性能。
  4. 是的，非常低效。增加了复杂性而没有收获。
  5. 不知道你在问什么。
  6. 仅当您扩展时。我想你会从单个数据库服务器开始，直到你需要更多容量。
  7. 从有经验的人开始的良好设计数据库设计将有很长的路要走。不要一开始就浪费太多时间进行微优化，否则您将永远无法起步。在扩展时根据需要进行优化。
于 2013-01-16T04:28:24.113 回答
0

简而言之，SQL Server 等关系数据库对于游戏来说不是很有用，因为它们无法有效地存储结构化的层次结构数据

我仍然主张避免使用 SQL，但现在有更多选项，NoSQL并且为了真正的性能，您应该考虑使用快速临时存储，例如Redis或 Memcache

您可以快速查看Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Couchbase vs Neo4j vs Hypertable vs ElasticSearch vs Accumulo vs VoltDB vs Scalaris 比较

优化是一个完全不同的主题。对于广泛的和特定的项目。

于 2013-01-13T22:37:02.737 回答