<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>分布式 on 云溪的 blog</title>
    <link>https://www.yunxicoding.top/categories/%E5%88%86%E5%B8%83%E5%BC%8F/</link>
    <description>Recent content in 分布式 on 云溪的 blog</description>
    <image>
      <title>云溪的 blog</title>
      <url>https://www.yunxicoding.top/papermod-cover.png</url>
      <link>https://www.yunxicoding.top/papermod-cover.png</link>
    </image>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Fri, 14 Dec 2018 17:47:08 +0800</lastBuildDate><atom:link href="https://www.yunxicoding.top/categories/%E5%88%86%E5%B8%83%E5%BC%8F/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>redis实现分布式锁</title>
      <link>https://www.yunxicoding.top/post/distributed/redis-lock/</link>
      <pubDate>Fri, 14 Dec 2018 17:47:08 +0800</pubDate>
      
      <guid>https://www.yunxicoding.top/post/distributed/redis-lock/</guid>
      <description>起因 消息队列处理任务中，由于消息队列中有相同的处理请求并且消费端存在多个，因此出现了并发消费的问题，于是产生了利用分布式锁来锁定消费，保证同一时间只有一个请求在处理，找了一下分布式锁的实现方式常见的有：
基于数据库 基于Zookeeper 基于redis 选型 基于数据库相对来说，更直观，实现起来也比较简单，至于要设置一个唯一索引，在插入时判断是否正常插入，不能插入则说明获取锁失败，缺点是会增加数据库开销，增加数据库压力，所以此方案PASS。基于Zookeeper实现分布式锁，会引新的软件，将会增加原有系统的复杂度，因而此方案也PASS。基于 redis 本身是对内存的操作，相对来说效率会非常高，并且原有系统也已经存在了 redis ，因而也不会增加原系统的复杂度，所以选择了 redis 来实现分布式锁。
背景介绍 SETNX key value
将 key 的值设为 value ，当且仅当 key 不存在。若给的 key 已经存在，则 SETNX 不做任何动作。SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写。
redis&amp;gt; EXISTS job # job 不存在(integer) 0redis&amp;gt; SETNX job &amp;#34;programmer&amp;#34; # job 设置成功(integer) 1redis&amp;gt; SETNX job &amp;#34;code-farmer&amp;#34; # 尝试覆盖 job ，失败(integer) 0redis&amp;gt; GET job # 没有被覆盖&amp;#34;programmer&amp;#34; 当 key 不存在时，返回 1， 如果设置的 key 存在时则返回 0 ，该操作本身具有原子性，因此可以利用 redis 此特性进行分布式锁实现的基础。</description>
    </item>
    
  </channel>
</rss>
