在游戲服務(wù)器中，線程的管理是重中之重，因為線程數(shù)量不能太多，所以為了提高游戲服務(wù)器并發(fā)性，就需要在線程處理業(yè)務(wù)的速度要快，不能長時間卡住線程，比如，不能有網(wǎng)絡(luò)io,磁盤IO等耗時的操作。所以我們會把有限的線程數(shù)進配按需分配。線程的主要分配方式如下：

游戲服務(wù)器中多線程之間如何通信？

1，與客戶端的IO線程

負責(zé)接收客戶端消息，和向客戶端發(fā)送消息。

2，處理玩家業(yè)務(wù)的邏輯線程

負責(zé)業(yè)務(wù)邏輯的處理與計算。

3，處理rpc或數(shù)據(jù)庫同步的網(wǎng)絡(luò)線程。

負責(zé)不同服務(wù)之間的通信

4，處理日志的磁盤IO 線程

相應(yīng)的線程分別做自己該做的時間。但是這時候問題來了，既然按用途分配了這些線程，那不可免費的就會出現(xiàn)不同線程之間的數(shù)據(jù)交互了。舉個例子來說，比如玩家登陸和排隊，假如說一個區(qū)一臺物理機，處理與客戶端的IO線程占1個，業(yè)務(wù)邏輯線程16個，請求數(shù)據(jù)庫的線程3個。其它的先忽略不算。

這個時候，服務(wù)器收到客戶端登陸的請求，業(yè)務(wù)線程收到這個請求，第一件事情是去數(shù)據(jù)庫查用戶的信息，因為業(yè)務(wù)邏輯線程是多個用戶之間共用的，所以你不能在這里等待數(shù)據(jù)庫請求的返回，要不然會卡別的業(yè)務(wù)邏輯處理。最好的做法就是，把這個請求封裝成一個事件，發(fā)送到數(shù)據(jù)庫同步線程中去處理這個事。等待數(shù)據(jù)庫線程處理完了，再把結(jié)果告訴業(yè)務(wù)邏輯線程，然后再處理業(yè)務(wù)，這個時候處理的數(shù)據(jù)都在內(nèi)存中了，所以速度非?？欤幚硗曛笤俜祷乜蛻舳?。

有人說，那這樣還不是卡登陸嗎?是的，必卡登陸，因為處理數(shù)據(jù)庫的線程就那么3個。

對于mysql的查詢性能測試如下：

我們3個線程按1500個計算，那么也只有登陸并發(fā)達到1500的時候，才會覺得服務(wù)慢一些，(實際情況可能會再底一些)，如果并發(fā)能達到這么高，說明游戲很火了，可以等待數(shù)錢了。如果再多的人，我們就可以使用排隊的功能的?？梢圆樵兊綌?shù)據(jù)庫線程中正在等待執(zhí)行任務(wù)的數(shù)量，如果達到某個值，就可以在業(yè)務(wù)服務(wù)中給客戶端返回正在排隊的，讓客戶端過一會再來請求即可。

回到正題，那么游戲服務(wù)器線程之間該如何傳遞數(shù)據(jù)呢，可能每個人的做法不一樣，這里只列舉中一個，希望給大家給帶來些參考，就當是交流學(xué)習(xí)了。如果你有更好的方法，也希望您評論分享。

在Java中，多線程之間交互數(shù)據(jù)，即A線程給B線程一個請求事件，A線程還要獲取B線程的執(zhí)行結(jié)果，比如登陸，請數(shù)據(jù)庫線程去查庫，查完之后告訴邏輯線程。Java提供了一個Future/Callable的機制，詳細大家可以自動百度它們的用法，但是它們有一個缺點，就是A線程在獲取結(jié)果時(調(diào)用future.get())的時候是同步的，如果B線程沒有執(zhí)行完，還是會卡A線程。這顯示不是我們想要的。對于這一點，我們偉大的異步框架，netty的作者給出了一個解決方法，那就是Future / promise模式。這里對它的源碼暫不做分皙了，有時間另寫文章說明吧，有興趣的同學(xué)可以自己查看。這里只說一下它的用法。

此代碼只是模擬，真實應(yīng)用中還需要自己設(shè)計，首先是數(shù)據(jù)庫查詢的管理類：

然后是業(yè)務(wù)管理類：

通過這個例子，其它關(guān)于多線程交互數(shù)據(jù)的功能實現(xiàn)，大家就可以舉一返回三了。

755800為網(wǎng)絡(luò)游戲營運公司提供了高性能、高可用、可伸縮性、高性價比的IDC數(shù)據(jù)中心解決方案！詳詢在線客服！

海外服務(wù)器免費測試：http://hbjsdrq.com/