Redis集群中的二次投票问题探讨（redis集群二次投票）

Recent，when using Redis in various projects, it is sometimes necessary to use the Redis Cluster mode to ensure service stability. In this case, when using it in voting, there will be a problem of ‘second vote’. Now let’s explore it.

First of all, let’s define the so-called ‘second vote’. When using Redis Cluster as the medium for voting, due to the distributed architecture of the Redis Cluster, the same data of different voting nodes may be distributed to different master and slave nodes of the same Redis Cluster. In this case, if a voting is re-issued, the same data may be written to the master and slave nodes of the same Redis Cluster. At this point, when the data is searched, the voting data of the same user ID appears twice, resulting in the so-called duplicate vote problem.

Therefore, in order to solve this problem, we need to consider how to avoid duplicate votes when using the Redis Cluster. Among them, there are two simple and feasible solutions.

The first is to use pipe buffering. When a user votes, it is necessary to determine whether the user ID has been written in all the master and slave nodes of the corresponding Redis Cluster. If it has not been written, it can be written in batches. For example, you can use the following code:

MULTI — open the buffer pool set userId 1 — Set key-value prs EXEC — Submit the buffer pool

Through this code, we can ensure that a data is written to the Redis Cluster only once.

The second is to use Redlock distributed mutex lock. When using Redis Cluster in voting, we need to use distributed locks in the voting process, such as the Redlock distributed mutex lock. This lock can ensure that the same user ID is written only once to the Redis Cluster. The code is as follows:

//Defines the function used to obtn distributed locks const Redlock = require(“redlock”); const lock = new Redlock([client.client1(), client.client2(), client.client3()], {retryCount: 10}); //Information required when obtning a lock const id = “userId” const resource = [“voting”,id].join(“:”); const ttl = 10000 const attemptLock = function () { lock.lock(resource, ttl).then(function (votingLock) { //Read data set userId 1 // Write data votingLock.unlock().catch(function (err) { //Force to unlock }) }) } // Call the attemptsLock function to lock attemptLock();

Using Redlock distributed mutex lock, we can ensure that the same user ID is written to the Redis Cluster only once, thereby avoiding the ‘second vote’ problem.

In summary, when using Redis cluster in voting services, in order to avoid the ‘second vote’ problem, we can use the pipe buffering or Redlock distributed mutex lock to ensure that only one voting data of the same user ID is written to all the master and slave nodes of the Redis Cluster.

创新互联成都网站建设公司提供专业的建站服务，为您量身定制，欢迎来电（028-86922220）为您打造专属于企业本身的网络品牌形象。
成都创新互联品牌官网提供专业的网站建设、设计、制作等服务，是一家以网站建设为主要业务的公司，在网站建设、设计和制作领域具有丰富的经验。

文章名称：Redis集群中的二次投票问题探讨（redis集群二次投票）
标题来源：http://www.shufengxianlan.com/qtweb/news38/363888.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联