The application of Redis in game development

Redis is an emerging NoSQL data caching component, similar to Memcache, but with more functionality than memcache. First, both Redis and Memcache are memory-based, so read and write speeds are very fast. However, Memcache only supports simple key-value data storage, and Redis has good support for Key-value, hash,list,set,sortset and other data structures. Below is a brief introduction to Redis in the development and application of the game.

It book network: http://www.myitbook.cn

< Span style= "FONT-SIZE:18PX; Color: #330033 "> one, data cache
At this point, Redis and Memcache are the same. is to put the data into memory in advance. When data is needed in logic processing, it is read from memory, the same, write to memory first, and then manipulate the database to increase the speed of data processing. Unlike Redis with the ability to write data to the hard disk, a specific write policy can be configured in the Redis configuration file. This way, when the host suddenly fails, such as a power outage, restarting the machine will not cause data loss. This is especially important in the application of the game. Generally in game development, data processing takes the following: Cache + Persistent queue + database (MySQL) architecture. The process is to write the data to the cache first, then put the persisted data into the persistence queue, start a daemon thread, continuously fetch the data from the persistent queue, and deposit or update to the database. If you use memcache so that there is no write to the hard disk function of the cache component, in the event of failure, if there is no processing of data in the persistent queue, then the data will be lost, referring to the player's data for a brief return. Of course, these can also develop some of their own features to prevent, but increase the development costs.
Two, implementation of a persistent queue without data loss
said that Redis has the ability to write data to the hard disk, and supports a variety of data structures. Then you can use the Redis list to implement the persistence queue, and when the machine fails, there will be no data loss in the queue, after rebooting, the data will be automatically loaded into the Redis list.
Implementation Method: (1) construct a list store in Redis
(2) A thread uses Redis's Lpush method to add data to the left side of the list
(3) Another thread uses the Redis Rpop method, The data is fetched from the list and removed from the list. This enables a simple queue of producer-consumer patterns.
Three, control of concurrency

It book network:http://www.myitbook.cn
In general, we operate a data flow is such, take out-processing---storage, so in single-threaded operation is no task problem, but in the multi-threaded environment is not applicable, we must consider the problem of data synchronization, to ensure the atomicity of data operations. If in the game, the player team's properties are updated, generally in the database will save a teaminfo table, there are players corresponding attributes, such as name, grade, gold, diamonds and so on. Save a Teaminfo object in Memcache, when the player obtains the gold coin, we need to take out all the attributes of the player, then set the gold coin, and then store the whole object. This time you have to consider the synchronization of data, if in the operation, another thread B modified the diamond, and completed the storage, and this time I changed the gold coins after the storage, then, there is data chaos results. Considering data synchronization is nothing more than locking or optimistic synchronization. Not only increases the amount of code, but also increases the difficulty of maintenance. In Redis, it supports the manipulation of hash data structures. We can play with the objects of the home by each field stored in the Redis hash. Structures such as:
When I need to update coins, such as increase or decrease, I can use Redis's own atomic manipulation method: Hincrby (String key,string field,int value) to operate, value is positive plus, minus is minus, This simplifies and avoids some concurrency, and this also reduces the number of steps to operate on the data, because there is no process to remove, then manipulate, and write only once. And in the game rarely update very many fields, if there is such a situation, the following method can solve

third, support for the business
Redis provides a mechanism for transactional operations, and the MULTI command is used to open a transaction, which always returns OK.
After the MULTI executes, the client can continue to send any number of commands to the server, which are not executed immediately, but are placed in a queue and all commands in the queue are executed when the EXEC command is called.
On the other hand, by calling DISCARD, the client can empty the transaction queue and discard the execution transaction.
Here is an example of a transaction that atomically adds the values of Foo and bar two keys:
> MULTI
Ok

> INCR foo
QUEUED

> INCR Bar
QUEUED

> EXEC
1) (integer) 1
2) (integer) 1
The reply to the EXEC command is an array, and each element in the array is the reply generated by the command in the execution transaction. Where the order of the reply elements is the same as the order in which the commands are sent. When the client is in a transactional state, all incoming commands return a state reply (status reply) that is QUEUED, and these queued commands are executed when the EXEC command is invoked. Starting with Redis 2.6.5, the server records the failure of the command to queue and denies execution and automatically discards the transaction when the client invokes the EXEC command.
Four, provide external CAs behavior, realize optimistic locking mechanism
In game development, it is sometimes necessary for us to implement an optimistic locking mechanism externally, the Watch command can provide Check-and-set (CAS) behavior for Redis transactions, the watch key will be monitored, and the keys will be found to have been altered. If at least one of the monitored keys has been modified before exec executes, the entire transaction is canceled, and EXEC returns an empty number of bulk replies (null Multi-bulk reply) to indicate that the transaction has failed.
For example, suppose we need to atomically add 1 to a value (assuming INCR does not exist).
First we might do this:
val = GET MyKey
val = val + 1
SET MyKey $val
The above implementation can be performed very well when there is only one client. However, when multiple clients perform such operations on the same key at the same time, a race condition is created.
For example, if both client A and B read the original value of the key, such as 10, then two clients will set the value of the key to 11, but the correct result should be 12.
With WATCH, we can easily solve this kind of problem:
WATCH MyKey
val = GET MyKey
val = val + 1
MULTI
SET MyKey $val
Exec
Using the above code, if after the WATCH executes, before EXEC executes, there are other clients that modify the value of MyKey, the current client's transaction will fail. What the program needs to do is to retry the operation until no collisions occur. This form of lock is called an optimistic lock, and it is a very powerful locking mechanism. And because in most cases, different clients have access to different keys, and collisions are generally rare, so there is usually no need to retry.

Iv. control of the cache life cycle

In the game server, in order to save performance, we do not need to have all the player's information cached in memory. For example, there are some infrequently logged in players, then his information is not necessary to stay in the cache, need to clear. Redis provides a method for this feature: expire, which can set the lifetime of a key in seconds, such as 300s, then the record will be deleted in memory after five minutes. This will not only save memory, but also increase the performance of the server.
It book network:http://www.myitbook.cn

The application of Redis in game development