游戏服务器,每秒需要处理百来次数据库的读写操作,如何设计比较好?
1 条评论
分享
按投票排序
按时间排序
13 个回答
100+的QPS算不算高,专业的DBA都知道。
关键是:
1. 有木有慢查询?
2. 有木有无意义的操作(明明可以先计算一次反复读取使用的,却过分追求实时性而每次查询)
3. 有木有过多的关联查询(明明可以通过反范式的冗余减少查询的,但为了追求规范度而过度精简)
更关键的是,当前的QPS有木有造成DB的瓶颈和压力。
看业务需求,而不是单纯看某个数字。
另外,如果后端可以水平扩展出去,那么业务量可能的潜在增长也有了应付办法,这点QPS就更不算啥了。
关键是:
1. 有木有慢查询?
2. 有木有无意义的操作(明明可以先计算一次反复读取使用的,却过分追求实时性而每次查询)
3. 有木有过多的关联查询(明明可以通过反范式的冗余减少查询的,但为了追求规范度而过度精简)
更关键的是,当前的QPS有木有造成DB的瓶颈和压力。
看业务需求,而不是单纯看某个数字。
另外,如果后端可以水平扩展出去,那么业务量可能的潜在增长也有了应付办法,这点QPS就更不算啥了。
我们的方案:
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的方案解决。
我猜你用不到后者。^-^
数据以内存为主,将数据库变更通过队列向数据库同步,插入队列中合并相同的操作,比如对一个字段的增减操作,一般频繁操作就是pk的时候加血减血喝药什么的,实时性要求很高,操作非常频繁,如果这个都去实时读写数据库的话,一组服务器能撑多少人在线??
个人建议:不一定要用数据库的,特别是不一定用关系型数据库。
您的这个状况:首先是追求响应速度的吧,
如果用关系数据库,大量读写会导致索引无效,读写效率都会比较低下。可以考虑仅仅把那种一旦丢失就影响很大如当前等级、帐号和密码之类的才持久化保存到关系数据库中。其他的实时数据,可以考虑使用各种NOSQL方案来达成更高的性能,或者干脆自己的前端程序在内存中折腾,10分钟才回写给数据库行不行呢。
假如非得用关系数据库不可,建议采用内存数据库。
如果没有内存数据库可用,可以考虑加大机器内存,反正现在内存也便宜,把各种缓存啊SharedBuffer之类的都开得尽可能的大。 还可以考虑上固态硬盘,提高磁盘I/O速度。
再者,就是考虑看能否把数据分离到不同的各个节点,尽量减少单点处理压力。
您的这个状况:首先是追求响应速度的吧,
如果用关系数据库,大量读写会导致索引无效,读写效率都会比较低下。可以考虑仅仅把那种一旦丢失就影响很大如当前等级、帐号和密码之类的才持久化保存到关系数据库中。其他的实时数据,可以考虑使用各种NOSQL方案来达成更高的性能,或者干脆自己的前端程序在内存中折腾,10分钟才回写给数据库行不行呢。
假如非得用关系数据库不可,建议采用内存数据库。
如果没有内存数据库可用,可以考虑加大机器内存,反正现在内存也便宜,把各种缓存啊SharedBuffer之类的都开得尽可能的大。 还可以考虑上固态硬盘,提高磁盘I/O速度。
再者,就是考虑看能否把数据分离到不同的各个节点,尽量减少单点处理压力。