遊戲伺服器，每秒需要處理百來次資料庫的讀寫操作，如何設計比較好？

01-15

100+的QPS算不算高，專業的DBA都知道。

關鍵是：

1. 有木有慢查詢？

2. 有木有無意義的操作（明明可以先計算一次反覆讀取使用的，卻過分追求實時性而每次查詢）

3. 有木有過多的關聯查詢（明明可以通過反範式的冗餘減少查詢的，但為了追求規範度而過度精簡）

更關鍵的是，當前的QPS有木有造成DB的瓶頸和壓力。

看業務需求，而不是單純看某個數字。

另外，如果後端可以水平擴展出去，那麼業務量可能的潛在增長也有了應付辦法，這點QPS就更不算啥了。

100次不高啊。

拆適量個數的表

設計好主鍵和索引，保證查詢都能查到索引上，第一索引列能把結果條目減到最少

保證查詢盡量是kv的，範圍查詢盡量在主鍵上

適當冗餘以減少查詢

不要有join操作

像大家說的，cache是必須的

應該是毫無壓力的。。。

前端的操作直接落到資料庫上，死定了。

不是緩存就是數據中間層，太陽下沒有新鮮事。

兩層意思。

一個是前端數據直接寫到資料庫，還是做緩存。

一個是頻繁訪問資料庫的解決方案。

根據業務需求，能用緩存解決的用緩存來解決，盡量減少IO次數。

如果業務要求大流量訪問資料庫，用均衡器+資料庫cluster的方案解決。

我猜你用不到後者。^-^

我們的方案：

1、db讀：設置數據緩存，頻繁訪問的數據放在緩存中，短時間讀取的話直接從cache中返回，跳過讀取db

2、db寫：將單位時間內的對同個主鍵的更新操作進行合併，比如某個玩家在地圖中形走，為了紀錄玩家行走的坐標會有大量的更新db的操作，我們設置幾分鐘更新一次db，分時更新來減少db的寫操作。

數據以內存為主，將資料庫變更通過隊列向資料庫同步，插入隊列中合併相同的操作，比如對一個欄位的增減操作，一般頻繁操作就是pk的時候加血減血喝葯什麼的，實時性要求很高，操作非常頻繁，如果這個都去實時讀寫資料庫的話，一組伺服器能撐多少人在線?？

即然確定要寫百來次了，估計什麼寫緩存啊，什麼減少次數之類的就不說了，直接用多線程讀寫資料庫不就可以了，百來次應該沒有什麼壓力的，

把資料庫砍掉,給他們說買不起資料庫,免費的也不能用

百來次的直接上資料庫把，不需要其他優化，除非數據量特別大

你可以嘗試開源遊戲伺服器端框架firefly，http://firefly.9miao.com

個人建議：不一定要用資料庫的，特別是不一定用關係型資料庫。

您的這個狀況：首先是追求響應速度的吧，

如果用關係資料庫，大量讀寫會導致索引無效，讀寫效率都會比較低下。可以考慮僅僅把那種一旦丟失就影響很大如當前等級、帳號和密碼之類的才持久化保存到關係資料庫中。其他的實時數據，可以考慮使用各種NOSQL方案來達成更高的性能，或者乾脆自己的前端程序在內存中折騰，10分鐘才回寫給資料庫行不行呢。

假如非得用關係資料庫不可，建議採用內存資料庫。

如果沒有內存資料庫可用，可以考慮加大機器內存，反正現在內存也便宜，把各種緩存啊SharedBuffer之類的都開得儘可能的大。還可以考慮上固態硬碟，提高磁碟I/O速度。

再者，就是考慮看能否把數據分離到不同的各個節點，盡量減少單點處理壓力。

是分大區還是不分大區的，一般來說幾百的QPS啥資料庫都行啊， Mysql, PostgreSQL都行，緩存是必須的，我也不是DBA.....

恩,別用關係型尤其事務資料庫,用像mongdo這樣的k-v型資料庫吧.查詢很快.