游戏服务器，每秒需要处理百来次数据库的读写操作，如何设计比较好？

编程入门行业动态更新时间:2024-10-24 12:32:59

游戏服务器，每秒需要处理百来次数据库的读写操作，如何设计<a href=https://www.elefans.com/category/jswz/34/1767521.html style= 比较好？"/>

游戏服务器，每秒需要处理百来次数据库的读写操作，如何设计比较好？

1 条评论分享按投票排序按时间排序

13 个回答

职业欠钱，一个过气的黑客爱好者，骗过稿费，做过编… 何剑、知乎用户、知乎用户等人赞同 100+的QPS算不算高，专业的DBA都知道。
关键是：
1. 有木有慢查询？
2. 有木有无意义的操作（明明可以先计算一次反复读取使用的，却过分追求实时性而每次查询）
3. 有木有过多的关联查询（明明可以通过反范式的冗余减少查询的，但为了追求规范度而过度精简）

更关键的是，当前的QPS有木有造成DB的瓶颈和压力。
看业务需求，而不是单纯看某个数字。

另外，如果后端可以水平扩展出去，那么业务量可能的潜在增长也有了应付办法，这点QPS就更不算啥了。发布于 2012-02-21 2 条评论感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利杨益，web开发者，php & js 知乎用户、知乎用户、石海等人赞同前端的操作直接落到数据库上，死定了。
不是缓存就是数据中间层，太阳下没有新鲜事。发布于 2012-02-21 1 条评论感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利姚君林，手游、手游谢巍、神之疯神、陈天明赞同我们的方案：
1、db读：设置数据缓存，频繁访问的数据放在缓存中，短时间读取的话直接从cache中返回，跳过读取db
2、db写：将单位时间内的对同个主键的更新操作进行合并，比如某个玩家在地图中形走，为了纪录玩家行走的坐标会有大量的更新db的操作，我们设置几分钟更新一次db，分时更新来减少db的写操作。发布于 2012-02-21 9 条评论感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利大雄，程序员 100次不高啊。
拆适量个数的表
设计好主键和索引，保证查询都能查到索引上，第一索引列能把结果条目减到最少
保证查询尽量是kv的，范围查询尽量在主键上
适当冗余以减少查询
不要有join操作
像大家说的，cache是必须的
应该是毫无压力的。。。

发布于 2012-02-21 2 条评论感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利林仔，软件工程师王啸赞同两层意思。
一个是前端数据直接写到数据库，还是做缓存。
一个是频繁访问数据库的解决方案。
根据业务需求，能用缓存解决的用缓存来解决，尽量减少IO次数。
如果业务要求大流量访问数据库，用均衡器+数据库cluster的方案解决。
我猜你用不到后者。^-^ 发布于 2012-02-21 2 条评论感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利李明，二手的Python程序猿，二手的iOS程序员，… 数据以内存为主，将数据库变更通过队列向数据库同步，插入队列中合并相同的操作，比如对一个字段的增减操作，一般频繁操作就是pk的时候加血减血喝药什么的，实时性要求很高，操作非常频繁，如果这个都去实时读写数据库的话，一组服务器能撑多少人在线?？发布于 2012-03-08 添加评论感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利李志辉，游戏研发即然确定要写百来次了，估计什么写缓存啊，什么减少次数之类的就不说了，直接用多线程读写数据库不就可以了，百来次应该没有什么压力的，发布于 2012-02-27 添加评论感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利 egmkang wang ，C/C++/Lua,网游服务器开发,价值投资把数据库砍掉,给他们说买不起数据库,免费的也不能用

发布于 2012-02-21 添加评论感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利森林，乐呵呵哭兮兮百来次的直接上数据库把，不需要其他优化，除非数据量特别大发布于 2014-06-25 添加评论感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利匿名用户你可以尝试开源游戏服务器端框架firefly，发布于 2013-09-26 添加评论感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利高健个人建议：不一定要用数据库的，特别是不一定用关系型数据库。
您的这个状况：首先是追求响应速度的吧，
如果用关系数据库，大量读写会导致索引无效，读写效率都会比较低下。可以考虑仅仅把那种一旦丢失就影响很大如当前等级、帐号和密码之类的才持久化保存到关系数据库中。其他的实时数据，可以考虑使用各种NOSQL方案来达成更高的性能，或者干脆自己的前端程序在内存中折腾，10分钟才回写给数据库行不行呢。

假如非得用关系数据库不可，建议采用内存数据库。
如果没有内存数据库可用，可以考虑加大机器内存，反正现在内存也便宜，把各种缓存啊SharedBuffer之类的都开得尽可能的大。还可以考虑上固态硬盘，提高磁盘I/O速度。
再者，就是考虑看能否把数据分离到不同的各个节点，尽量减少单点处理压力。发布于 2013-07-31 添加评论感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利吴伟，低调的悲催IT民工。。是分大区还是不分大区的，一般来说几百的QPS啥数据库都行啊， Mysql, PostgreSQL都行，缓存是必须的，我也不是DBA..... 发布于 2012-09-05 添加评论感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利高杰，一休攻城师恩,别用关系型尤其事务数据库,用像mongdo这样的k-v型数据库吧.查询很快.