Thinking of Game server architecture

Time is always inadvertently when the flow away, suddenly recalled that I have done four years of game development, experienced several game projects, the previous project in the game server framework is not my ideal framework, although I do not know is not enough. Here's a simple thought of my game server architecture. A good game framework can improve development efficiency and save labor costs. First of all, the simplest server framework, that is, as long as a gateway and a game server.

The agentserver is responsible for the client connection, the client sends and receives the data, forwards the client data to the server, forwards the server data to the client, there is little logic, so it can deal with the large concurrent IO. So the agent can take a epoll thread, which is responsible for client connection and data sending. A log thread that is responsible for recording the logs during the run. The main thread is responsible for sending data to Gameserver and Gameserver data to the client send queue. Gameserver is the main game server, mainly responsible for the game logic function. Gameserver threads are: The socket thread is responsible for receiving messages, the log thread is responsible for writing to the log, and the DB thread is responsible for data loading and archiving. Bill Billing thread is responsible for writing some data from the game running to the database as an operational log. The main thread is responsible for logic, which is the logical single-threaded schema pattern. A DB thread can include NoSQL applications such as redis as a cache. This architecture is relatively simple, the logic is clear, no data synchronization and lock-related operations, but this architecture does not implement cross-service functions.

The following is a cross-service game server architecture, such as:

We have added two new server processes, namely the router routing server and the world server, which is the Cross service server. Gameserver and Agentserver server functions are not changed. Router is responsible for routing messages, and the world server handles cross-service functions. The router can be directly responsible for connecting and sending data to and from a thread. The world server is directly the same as the Gameserver threading architecture. This architecture makes it easy to implement cross-service functions, and the logic is simple and easy to develop.

Now the server is multi-core CPU, from the server above, the above server architecture in addition to the logical thread consumes the CPU, the other threads are consuming IO, the CPU consumes little. That is, our servers can not fully play the CPU's parallel computing energy, the only way is the logical multithreading. Logical multithreading can also increase the cost of development and the responsibility of server development while exerting CPU parallel computing power. In order to avoid the use of locks you can add a process.

is a logical multi-threaded architecture:

In order to implement the logical multi-threading, we need to join a local world server, this server process can be responsible for such as trade union friends and other functions, when added to the local World Service in fact, we can easily implement the logical multi-threading and multi-process functions, That is, our servers can assign logic to different processes and threads by function or map.

Above said three kinds of server architecture, I personally think the second is better, after joining router we can increase the gateway server is not the amount, but need gamerserver to handle it. If the game is really special fire the last architecture can be addressed. Gateways can be dynamically increased, and gameserver can be dynamically increased.

Server development in the bill and the protocol can be configured after the XML with the tool directly generated, if the need for protocol compatibility that can use the Google Protocol tool. Memory can be allocated directly with new and join Tcmalloc or JEMALLOC, database select MySQL, cache select Redis. The configuration is preferably XML or database configuration. CSV configuration is prone to problems, inconvenient to find, if you want to do a foreign version of CSV easy translation error, the script generally choose Lua, using Lua_tinker as the intermediate library.

Today's services are almost always running on Linux, so there's no need to do cross-platform functionality.

Thinking of Game server architecture