Common Practices

This section describes common practices of DCS to help you better use it.

Practice	Description
Serializing Access to Frequently Accessed Resources	In Internet scenarios such as seckill, the system needs multiple machines to run concurrently to handle traffic burst. If two users' requests arrive at the same time but on two different machines. Although the two requests can be handled spontaneously, an inventory oversold or disordered access problem may still occur. This is because a machine has a unique lock and a machine's lock only takes effect on threads in the Java VM where the machine runs. To serialize access to resources, you can use DCS Redis instances for distributed locking.
Merging Game Servers with DCS	Merging game servers takes place when large-scale online games start a new server (zone) or merge old and new servers. During this process, game developers must consider how to synchronize data among different servers. With the pub/sub message queuing mechanism of DCS for Redis, data changes can be published to Redis channels. Other game servers can subscribe to the channels to receive messages of changes. This practice describes how to synchronize servers using Redis.
Connecting a Redis Client to DCS Through CCE	With the development of the container technology, more and more applications are deployed in containers. This practice describes how to deploy a Redis client in a Cloud Container Engine (CCE) cluster container and connect it to DCS.