1.3.4　業務處理框架

業務處理框架是為了便于業務功能開發，對影響業務功能開發的公共部分進行架構規劃，盡量讓開發人員專心于功能設計與開發，并提供底層的基礎支持。一般有3個模塊。

1.消息管理

游戲用戶操作的過程，對服務器來講就是修改游戲數據。在服務器架構中，網絡層的數據接收和請求的業務處理會在不同的線程中，一個游戲用戶的數據只有一份，用戶有可能同時修改這份數據，這就有可能出現多線程操作共享數據的問題。解決這個問題的一種方式是對數據修改進行加鎖。但是由于游戲用戶數據很多，導致需要對服務器發送大量并發請求，多線程執行加鎖代碼時，為了獲取執行權和保存線程執行狀態，會導致CPU大量的上下文切換（指CPU從正在執行的線程切換執行另一個線程），反而減少了服務器的消息處理的吞吐量，使性能下降。而且如果控制不好加鎖，也容易出現死鎖的現象。

另一種方式是不加鎖，讓同一個用戶的數據按順序處理。一種實現方法是把同一個用戶的請求先放到一個隊列中，不同的用戶的請求可以分到不同的隊列中，再對每個隊列固定啟動一個對應的線程處理隊列中的消息。這樣可以避免加鎖引起CPU產生大量的上下文切換，也保證同一個用戶的數據，都在同一個線程中處理，避免并發修改共享數據。

2.線程管理

在游戲服務器中，線程是一種非常珍貴且重要的資源，也是處理并發的唯一手段。但并不是說線程越多越好，線程太多，也會使CPU產生大量的上下文切換，使線程處理業務的能力下降。要合理地規劃線程的使用，才能使線程的利用率最大化。

對線程的合理分配，可以更好地優化服務器的性能。比如分配專門的線程池處理游戲業務，另外分配專門的線程池負責數據的操作，把耗時操作隔離到固定的線程中，減少對業務線程的卡頓，增加業務消息的吞吐量。因此在游戲服務開發中，不能隨意地創建線程，一定要有規則和標準。

3.數據緩存與持久化

在業務服務中，所有的操作都是依賴于數據。數據存儲于數據庫，但是把數據緩存在內存之中，可以避免操作數據時查詢數據庫而浪費時間。因此游戲數據什么時候加載到內存，如何將內存中的數據更新到數據庫之中，也是架構要解決的問題。這樣可以把數據的管理統一化，業務開發中只需要操作內存的數據即可，即使不了解數據庫相關的知識也能很快開發業務。