After the analysis and design of the previous articles in this series, we have successfully developed our own SDK server. Everything runs normally in our own debugging environment, but of course we can't just deploy this SDK server to the official production environment. Students with a little experience in formal large-scale projects should know that performance optimization and deployment and online related design are important for services. The importance of terminal projects. These designs have not been considered in our analysis design so far. So, for the application scenarios like our SDK server, which related optimization and design should we focus on?
Data Access Optimization
In our application scenario, the scenarios that need to use storage are mainly in the following processing:
l Obtain configuration information
For each received request, it is necessary to obtain the corresponding configuration information according to various information such as its source game channel, and then process it. Configuration information is accessed frequently, but is basically read-only and is not modified during processing.
l Access order information
For the order message generated by the payment, the server's processing includes creating an order, querying the order, and modifying the order status, etc. The processing of the data includes storing and reading, and the frequency of the two operations is basically the same.
l Save log information
For the received requests and generated errors, the server needs to save the log. This action is a pure write operation, and the operation frequency is relatively high.
For these types of data, our processing strategies are also different:
Frequently accessed data such as configuration information with small changes, in order to speed up the access as much as possible, we usually choose to store it in memory. However, if the configuration information is saved as a configuration file, it cannot be managed flexibly. Considering further dynamic loading configuration requirements, here we can use memory cache to access. That is, when the application starts, the configuration is read from the external storage ( DB ), stored in the memory to be called, and the configuration is updated periodically by checking the update flag.
Order information is important structured information and should undoubtedly be stored in DB . But looking back at the payment arrival request process analyzed in the previous texts, we can find that this process puts forward quite high requirements on our processing efficiency. If we cannot complete the entire query comparison and delivery process in the shortest possible time, it will cause the channel to determine that the game server processing timeout, thus triggering the channel's order resending mechanism. In the worst case, before the previous processing process is over, the next resend request of the channel arrives again, which will cause the processing efficiency of the system to drop rapidly or even crash. Therefore, we need to build a cache for the order to bear the query pressure for the DB . In this regard, common cache products on the market such as Redis Memcache can meet this requirement, and the specific design will not be repeated here.
Log information is write-only but not read-only. If all the logs are stored in the DB , the performance of the DB will undoubtedly be consumed unnecessarily in terms of space and efficiency . We generally choose to store logs in the form of files. In addition, this write operation must be handled asynchronously, otherwise performance will be greatly reduced. Regarding asynchronous processing, it will be further explained later.
asynchronous processing
Anything that can be done later should be done later, and asynchronous processing is based on this principle. Specific to our server design, we can conclude that the following logic can be designed as an asynchronous operation.
l All logging operations
l Most write operations to DB (including modifying order status / saving order information, etc.)
The read operation is usually a synchronous operation, and we cannot require a request to query an order to " return a message that the query request has been received, and then provide the query result asynchronously " .
l During the delivery process, the HTTP request operation communicated with the game server .
In fact, the asynchronous operation can be realized by the SDK side or the game side to achieve our goal, but it is more reasonable to implement it by the game server side.
The specific asynchronous implementation method is not discussed in detail here because the implementation of development languages and tools is different.
cluster deployment
In the scenario of high concurrent access to the website, use load balancing technology to build a server cluster composed of multiple servers for an application, and distribute concurrent access requests to multiple servers for processing, so as to avoid the slow response of a single server due to excessive load pressure , so that user requests have better response latency characteristics.
When using cluster deployment and load balancing technology, we are required to pay attention to the technical details of concurrent processing when designing applications, such as repeated request filtering, transactional processing logic, and other designs. In principle, it is enough to pay attention to these problems caused by simultaneous processing of multiple servers.
Code optimization
The reason why the code optimization part is put at the end is because this part is nothing more than some old-fashioned things. I believe that every reader has dealt with similar optimization work. Including connection pool resource reuse, data structure optimization, using garbage collection mechanism and so on. Here it is necessary for readers to actually operate according to the development tools and languages used.
The series of texts on the idea and architecture of the server design will come to an end in this article, and then we will use a few texts and codes to actually explain how to implement the server designed in this series of texts. And how to solve design problems encountered in actual coding. And further discuss more in-depth optimization methods in the process of actually solving the problem.
This project has been open sourced. If you are interested, you can do your own research or refer to the project to write your own aggregation SDK
project address: https://code.csdn.net/typesdk_code
project address: https://github.com/typesdk