Mobile Internet combat--social game leaderboard Design and implementation (2)

Objective:
Game areas, especially mobile social games, leaderboards have become a great magic weapon to enhance experience interaction and increase user stickiness. This is about how to design and implement the game rankings under the different user scale, game service/game platform trend. This article focuses on the role of NoSQL in the game standings. Small (Mumuxinfei) The understanding of this piece is relatively shallow, the viewpoint does not represent the mainstream (industry) practice, hope can be a catalyst.

Adhering:
Previous post, see: Social game leaderboard Design and implementation (1)

Advanced article:
As data volume/concurrency increases, MySQL cluster also presents some fatigue.
　　(1). When the database is divided into tables, the join between the tables actually loses its meaning. The table data to join is in a different library.
　　(2). The database read and write performance can easily reach the upper limit.
How to hack:
Let's go back and look at some table definitions and use
Table Tb_score uses user_id to access score scores, in fact user_id equivalent to key, score equals value. Therefore, it can be implemented with the help of NoSQL persistent key/value system, and redis/mongodb/leveldb/hbase, so that both in the read and write speed , or in the application of extensibility , have achieved a great improvement.
Table Tb_friend uses user_id to get the friend_id list, which essentially equals user_id as key, list<friend_id> as value, The key corresponds to the value list, which can be used with REDIS (data structure server) or sorted Key/value db system. Here we choose sorted Key/value db, because its data is stored in the order of key .
Sorted Key/value db is characterized by:
　　(1) Support for key prefix lookup
　　(2) Support batch/range query
We can key/value the following friend list format

Key = User_id:friend_idvalue = Score

Commentary:
key=>user_id:friend_id says friend_id is a friend of user_id.
The query for our buddy list evolves into a range query prefixed with "user_id" .
System Evolution: relational database MySQL is transformed into a nosql system .
　　

Cache Chapter:
Distributed cache, is always the Dogskin plaster of the internet community, no matter what pain, stickers always have curative effect. The introduction of the cache is also seen in blood sealing throat, the effect is very significant, but need to pay attention to data consistency problem. However, the internet can tolerate weak transactional/weak data consistency (C), while emphasizing availability and scalability (APs). Mobile gaming, in fact, is a similar execution strategy (except for money-related business). Common caches are memcache/redis, which are hash-hashed memory caches.
Simple to use Key/value, instead of using Redis's key/sort-list approach.
Value is a JSON-formatted list:

JSON-formatted content [{' user_id ': ' Score '}, {' user_id ': ' Score '}, {...}]

Ranking is relatively static, so the caching system can block out most of the data read.

But after the introduction of the cache, the consistency of the data , how to ensure?
Simulate the following application scenarios:
　　1). The friend broke the new record
　　2). Add/Remove friend relationship
When these conditions occur, the Friends ' leaderboard is updated. The cache needs to be updated so that persistent data for the cache and backend services is consistent.
So how to achieve?
Here, let's talk about three common ideas.
　　1). Sync Update: When friends Add/delete, actively delete the leaderboard cache. When the user's score innovation is high, actively traverse the Friend list, notify the deletion of the corresponding cache.
　　2). Asynchronous update: When a friend is added/deleted, or the user score is highly innovative, it posts an event into a queue, with the queue consumer doing this time-consuming synchronization operation.
　　3). Cache is deleted periodically: Set cache Key's validity period TTL, do not pay attention to friends Add/delete, score update event occurrence, allow the data consistency has a certain delay.
The pros and cons of these three options can be compared as follows:

	Real-time sex	Operating costs	Scalability
Synchronizing updates	Best	Have side effects, embed friends Add/Remove code logic, response becomes larger	Not good, future friends Add/Remove logic will become more and more bloated
Asynchronous update	So so	Affect small	Well, the introduction of queues can be handled differently by different consumer terminals
Cache is deleted periodically	So so	Almost no impact	---

Commentary: Notification of the top version of the update is a heavy operation , more time-consuming, synchronous operation will affect the response time.
For games, if the leaderboard is not in real-time rankings, using scenario 2/3 is acceptable. for Scenario 3, this heartless practice is actually the simplest and most effective (personal view).

Service/platform-based
When a social app evolves into a platform, the friend module and the game module will naturally separate, and its database/nosql system logic is not a piece, such as the app, its internal affirmation of various services have been split, its data is isolated from each other . In this service/platform evolution, the friend specific game leaderboard, how to break?
We assume the following services, whose interaction flow is as follows.
Gameservice/friendservice Module
　　
Commentary: A friend update event actively triggers the game module, which is also very expensive (as described above). It also requires the friend module to add the relevant logic code, which makes the modules tightly coupled .
With queues , it is implemented asynchronously . This is equivalent to using the Observer (Observer) pattern between the modules, as long as the event's trigger simply posts the event in the (topic mode) Queue . Then the service module that needs to focus on the event is actively subscribing to it . The new model translates to the following:
　　
　　Commentary: The asynchronous event through the queue, using the way the subscription, to achieve decoupling.
After the service platform, this practice is often used in industry.

Postscript:
Originally just wanted to write an article about the design of the community game leaderboard. But found that the content is some long, so split into two pieces, the contents of the simple involved in some, and did not specifically unfold. Small series (Mumuxinfei) on this piece is still shallow, if there is any shortage, hope to correct.