本文主要是介绍游戏服务器，每秒需要处理百来次数据库的读写操作，如何设计比较好？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
游戏服务器，每秒需要处理百来次数据库的读写操作，如何设计比较好？
按投票排序 按时间排序
13 个回答
职业欠钱 ，一个过气的黑客爱好者，骗过稿费，做过编… 何剑、知乎用户、知乎用户 等人赞同
100+的QPS算不算高，专业的DBA都知道。
关键是：
1. 有木有慢查询？
2. 有木有无意义的操作（明明可以先计算一次反复读取使用的，却过分追求实时性而每次查询）
3. 有木有过多的关联查询（明明可以通过反范式的冗余减少查询的，但为了追求规范度而过度精简）
更关键的是，当前的QPS有木有造成DB的瓶颈和压力。
看业务需求，而不是单纯看某个数字。
另外，如果后端可以水平扩展出去，那么业务量可能的潜在增长也有了应付办法，这点QPS就更不算啥了。
关键是：
1. 有木有慢查询？
2. 有木有无意义的操作（明明可以先计算一次反复读取使用的，却过分追求实时性而每次查询）
3. 有木有过多的关联查询（明明可以通过反范式的冗余减少查询的，但为了追求规范度而过度精简）
更关键的是，当前的QPS有木有造成DB的瓶颈和压力。
看业务需求，而不是单纯看某个数字。
另外，如果后端可以水平扩展出去，那么业务量可能的潜在增长也有了应付办法，这点QPS就更不算啥了。
杨益 ，web开发者，php & js https://github.com/yeaha 知乎用户、知乎用户、石海 等人赞同
前端的操作直接落到数据库上，死定了。
不是缓存就是数据中间层，太阳下没有新鲜事。
不是缓存就是数据中间层，太阳下没有新鲜事。
姚君林 ，手游、手游 谢巍、神之疯神、陈天明 赞同
我们的方案：
1、db读：设置数据缓存，频繁访问的数据放在缓存中，短时间读取的话直接从cache中返回，跳过读取db
2、db写：将单位时间内的对同个主键的更新操作进行合并，比如某个玩家在地图中形走，为了纪录玩家行走的坐标会有大量的更新db的操作，我们设置几分钟更新一次db，分时更新来减少db的写操作。
1、db读：设置数据缓存，频繁访问的数据放在缓存中，短时间读取的话直接从cache中返回，跳过读取db
2、db写：将单位时间内的对同个主键的更新操作进行合并，比如某个玩家在地图中形走，为了纪录玩家行走的坐标会有大量的更新db的操作，我们设置几分钟更新一次db，分时更新来减少db的写操作。
大雄 ，程序员 100次不高啊。
拆适量个数的表
设计好主键和索引，保证查询都能查到索引上，第一索引列能把结果条目减到最少
保证查询尽量是kv的，范围查询尽量在主键上
适当冗余以减少查询
不要有join操作
像大家说的，cache是必须的
应该是毫无压力的。。。
拆适量个数的表
设计好主键和索引，保证查询都能查到索引上，第一索引列能把结果条目减到最少
保证查询尽量是kv的，范围查询尽量在主键上
适当冗余以减少查询
不要有join操作
像大家说的，cache是必须的
应该是毫无压力的。。。
林仔 ，软件工程师 王啸 赞同
两层意思。
一个是前端数据直接写到数据库，还是做缓存。
一个是频繁访问数据库的解决方案。
根据业务需求，能用缓存解决的用缓存来解决，尽量减少IO次数。
如果业务要求大流量访问数据库，用均衡器+数据库cluster的方案解决。
我猜你用不到后者。^-^
一个是前端数据直接写到数据库，还是做缓存。
一个是频繁访问数据库的解决方案。
根据业务需求，能用缓存解决的用缓存来解决，尽量减少IO次数。
如果业务要求大流量访问数据库，用均衡器+数据库cluster的方案解决。
我猜你用不到后者。^-^
李明 ，二手的Python程序猿，二手的iOS程序员，… 数据以内存为主，将数据库变更通过队列向数据库同步，插入队列中合并相同的操作，比如对一个字段的增减操作，一般频繁操作就是pk的时候加血减血喝药什么的，实时性要求很高，操作非常频繁，如果这个都去实时读写数据库的话，一组服务器能撑多少人在线?？
egmkang wang 
森林 高健 个人建议：不一定要用数据库的，特别是不一定用关系型数据库。
您的这个状况：首先是追求响应速度的吧，
如果用关系数据库，大量读写会导致索引无效，读写效率都会比较低下。可以考虑仅仅把那种一旦丢失就影响很大如当前等级、帐号和密码之类的才持久化保存到关系数据库中。其他的实时数据，可以考虑使用各种NOSQL方案来达成更高的性能，或者干脆自己的前端程序在内存中折腾，10分钟才回写给数据库行不行呢。
假如非得用关系数据库不可，建议采用内存数据库。
如果没有内存数据库可用，可以考虑加大机器内存，反正现在内存也便宜，把各种缓存啊SharedBuffer之类的都开得尽可能的大。 还可以考虑上固态硬盘，提高磁盘I/O速度。
再者，就是考虑看能否把数据分离到不同的各个节点，尽量减少单点处理压力。
您的这个状况：首先是追求响应速度的吧，
如果用关系数据库，大量读写会导致索引无效，读写效率都会比较低下。可以考虑仅仅把那种一旦丢失就影响很大如当前等级、帐号和密码之类的才持久化保存到关系数据库中。其他的实时数据，可以考虑使用各种NOSQL方案来达成更高的性能，或者干脆自己的前端程序在内存中折腾，10分钟才回写给数据库行不行呢。
假如非得用关系数据库不可，建议采用内存数据库。
如果没有内存数据库可用，可以考虑加大机器内存，反正现在内存也便宜，把各种缓存啊SharedBuffer之类的都开得尽可能的大。 还可以考虑上固态硬盘，提高磁盘I/O速度。
再者，就是考虑看能否把数据分离到不同的各个节点，尽量减少单点处理压力。
高杰 这篇关于游戏服务器，每秒需要处理百来次数据库的读写操作，如何设计比较好？的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
