IBM x system 3650 服务器问题，“3650”四个数字各表示什么

您好：
楼主这问题，问的很专业 呵呵~
X 就是一个X的系列产品
3 就是一个产品的系列，X系列的服务器都是以3开头
6 这个数字就是代表了服务器的性能，这个数字越大，说明服务器越高端，如3850就比3650高端，3550比3650低端。
5 这个数字就是代表了是机架式服务器，如果这一位上是0，那就是塔式服务器。（机架就是高度很小，只有1、2或4U。而塔式则比较高）
0 这个数字代表了是INTEL的CPU，如果是5，那就是AMD的CPU。
希望我的回答对您有帮助！

　网吧无盘客户机配置我已经回答在你另外一个提问中了。现在来回答你最佳而且性能强大的服务器配置：

配置品牌型号数量　价格

CPU　Intel/英特尔 至强E3-1230 V3散片×1138500

散热器　九州风神玄冰400　12CM智能温控风扇×19900

主板　华硕H87-PLUS×179900

内存条　金士顿DDR3 1600 8G骇客神条×446000

显卡　映众GTX750TI 2G黑金至尊版×190000

固态硬盘　三星 MZ-7KE128B/CN 850pro 128G×186000

机械硬盘　Seagate/希捷 ST1000DM003 1T 64MB SATA3　×235500

电源　鑫谷GP700G黑金版×139900

机箱　酷冷至尊刺客U3加强版　×128000

总计：7272

一块固态硬盘做系统盘装win7，两块机械硬盘做RAID1。显卡你也可以选择价格更便宜一些的，反正服务器对显卡的要求不高。但我觉得目前最实惠最佳的是映众GTX750TI 2G黑金至尊版，其次是售价688元的映众 GTX750游戏战神版。

更便宜的显卡性价比就不好了。

从网吧无盘客户机配置中再弄出1台来做收银用就可以了。具体的无盘组网你需要找本地网络商为你建设，交换机、网卡及系统安装之类的相关问题我就不作进一步详细解释，由专业人员来为你具体的处理即可。

在这里我就只推荐你这两种配置的详细方案，这是目前最新的超性价比配置方案，也是最实惠的经典方案。

在确保性能强大的前提下，价格已经做到了最实惠，而且各个硬件都为大厂过硬产品型号。这样子稳定性是非常高的，这是你开网吧经营至关重要的关键哦！

你可不要贪图便宜去换成二三流产品哈！特别是固态硬盘二三流的产品这时间稍用久一些可是会卡钝的哦！到时你焦头烂额麻烦就大了。我给你配的可是三星最新的王牌旗舰级的固态硬盘　三星 MZ-7KE128B/CN 850pro 128G　了！贵是贵了些但物有所值了，服务器的稳定性和极速表现它居功至伟了，生意兴旺财源茂盛，你这些投资很快就回来了剩余的时间全是挣钱。

要是贪便宜弄些二三流的东西经常这出毛病那儿坏，你可就多的都去了哈！

此服务器配置性能可是极其强大的哦！四根8GB高规格内存，加极速高端固态硬盘，带50台无盘机那根本就是太轻松强大的了。多数网吧在同样价格条件下都不可能有我推荐的这两套配置的性能强大，性价比上也很难相比，也就是说在竞争起点上你就已经立于不败之地了。装机成本实惠而电脑的性能强大，顾客想不上门来玩都难！呵呵！

觉得满意的话记得及时采纳本人为满意答案唷！

一个教学机房有120台计算机。问一台服务器只能带动60台计算机，该机房需要两个服务器。
这是包含除法的应用。
根据除法的定义，“已知两个因数的积与其中一个因数，求另一个因数的运算，叫做除法。”
除法只有一种．但除法在实际问题中所反映的实际含义有两种：①把一个数平均分成几份，求每份是多少；②求一个数里包含几个另一个数．前者叫做等分除法，后者叫做包含除法。
做的时候，可以用商不变性质，把被除数和除数同时划去一个零，用12÷6，可一次定商为2
希望我能帮助你解疑释惑。

最近因为写论文的关系，泡知网、泡万方，发现了很多学术界对数据中心网络一些构想，发现里面不乏天才的想法，但日常我们沉迷在各个设备厂商调制好的羹汤中无法自拔，管中窥豹不见全局，还一直呼喊着“真香”，对于网工来说沉溺于自己的一方小小天地不如跳出来看看外界有哪些新的技术和思想，莫听穿林打叶声，何妨吟啸且徐行

当前新的数据中心网络拓扑主要分为两类

1、以交换机为核心，网络连接和路由功能由交换机完成，各个设备厂商的“羹汤”全属于这个领域

2、以服务器为核心，主要互联和路由功能放在服务器上，交换机只提供简单纵横制交换功能

第一类方案中包含了能引发我回忆阴影的Fat-Tree，和VL2、Helios、c-Through、OSA等等，这些方案要么采用更多数量交换机，要么融合光交换机进行网络互联，对交换机软件和硬件要求比较高，第二类主要有DCell、Bcube、FiConn、CamCube、MDCube等等，主要推动者是微软，这类方案中服务器一版会通过多网卡接入网络，为了支持各种流量模型，会对服务器进行硬件和软件的升级。

除了这些网络拓扑的变化外，其实对数据中心网络传输协议TCP/IP、网络虚拟化、网络节能机制、DCI网络互联都有很多创新的技术和概念涌现出来。
FatTree  胖树，2008年由UCSD大学发表的论文，同时也是5年前工作中接触的第一种交换机为中心的网络拓扑，当时没有太理解，跟客户为这事掐的火星四溅，再来一次可能结论会有所改变，同时也是这篇论文引发了学术界对数据中心内部网络拓扑设计的广泛而深刻的讨论，他提出了一套组网设计原则来达成几个目的

1、全网采用低端商用交换机来组网、其实就是采用1U的接入交换机，取消框式设备

2、全网无阻塞

3、成本节省，纸面测算的话FatTree 可以降为常规模式组网成本的1/4或1/5

物理拓扑（按照4个pod设计）

FatTree 的设计原则如下

整个网络包含K个POD，每个POD有K/2个Edge和K/2个Agg 交换机，他们各有K的接口，Edge使用K/2个端口下联服务器，Agg适用K/2个端口上联CORE交换机

Edge使用K/2个端口连接服务器，每个服务器占用一个交换端口

CORE层由K/2K/2共计KK/4个K个端口交换机组成，分为K/2组，每组由K/2ge，第一组K/2台CORE交换机连接各个POD中Agg交换层一号交换机，第二组K/2的CORE交换机连接各POD中Agg的二号交换机，依次类推

K个POD，每个POD有K/2个Edge交换机，每个Edge有K/2端口，服务器总数为KK/2K/2=KKK/4

K取值4的话，服务器总数为16台

常规K取值48的话，服务器为27648台

FatTree的路由设计更加有意思，论文中叫两阶段路由算法，首先要说明的是如果使用论文中的算法是需要对交换机硬软件进行修改的，这种两阶段路由算法和交换设备及服务器的IP地址强相关，首先就是IP地址的编制，这里依然按照K=4来设计，规则如下

1、POD中交换机IP为10podswitch1，pod对应POD编号，switch为交换机所在POD编号（Edge从0开始由左至右到k/2-1，Agg从k/2至k-1）

2、CORE交换机IP为10kji ，k为POD数量，j为交换机在Core层所属组编号，i为交换机在该组中序号

3、服务器IP为10podswitchID，ID为服务器所在Edge交换机序号，交换机已经占用1，所以从2开始由左至右到k/2+1

设计完成后交换机和服务器的IP地址会如下分配
对于Edge交换机（以10201为例）第一阶段匹配10202和10203的32位地址，匹配则转发，没有匹配（既匹配0000/0）则根据目的地址后8位，也就是ID号，选择对应到Agg的链路，如目标地址为xxx2则选择到10221的链路，目标地址为xxx3则选择到10231的链路

对于Agg交换机（以10221为例）第一阶段匹配本POD中网段10200/24和10210/24，匹配成功直接转发对应Edge，没有匹配（既匹配0000/0）则根据目的地址后8位，也就是ID号确定对应到Core的链路，如目标地址为xxx2则选择到10411的链路，目标地址为xxx3则选择到10412的链路

对于Core交换机，只有一个阶段匹配，只要根据可能的POD网段进行即可，这里是10000/16~10300/16对应0、1、2、3四个口进行转发

容错方面论文提到了BFD来防止链路和节点故障，同时还有流量分类和调度的策略，这里就不展开了，因为这种两阶段路由算法要对交换机硬件进行修改，适应对IP后8位ID进行匹配，现实中没有看到实际案例，但是我们可以设想一下这种简单的转发规则再加上固定端口的低端交换机，对于转发效率以及成本的压缩将是极为可观的。尤其这种IP地址规则的设计配合路由转发，思路简直清奇。但是仔细想想，这种按照特定规则的IP编制，把每个二层限制在同一个Edge交换机下，注定了虚拟机是没有办法跨Edge来迁移的，只从这点上来看注定它只能存在于论文之中，但是顺着这个思路开个脑洞，还有什么能够编制呢？就是MAC地址，如果再配上集中式控制那就更好了，于是就有了一种新的一种路由方式PortLand，后续我们单独说。

如此看来FatTree 是典型的Scale-out模式，但是由于一般交换机端口通常为48口，如果继续增加端口数量，会导致成本的非线性增加，底层Edge交换机故障时，难以保障服务质量，还有这种拓扑在大数据的mapreduce模型中无法支持one-to-all和all-to-all模式。

把脑洞开的稍微小一些，我们能否用通用商业交换机+通用路由来做出来一种FatTree变种拓扑，来达到成本节省的目的呢，答案一定是确切的，目前能看到阿里已经使用固定48口交换机搭建自己的变种FatTree拓扑了。

以交换机为中心的网络拓扑如VL2、Helios不再多说，目前看到最好的就是我们熟知的spine-leaf结构，它没有设计成1:1收敛比，而且如果使用super层的clos架构，也可以支撑几万台或者百万台的服务器规模，但是FaTtree依靠网络拓扑取消掉了框式核心交换机，在一定规模的数据中心对于压低成本是非常有效的

聊完交换机为核心的拓扑设计后，再来看看服务器为核心的拓扑，同样这些DCell、Bcube、FiConn、CamCube、MDCube等，不会全讲，会拿DCell来举例子，因为它也是2008年由微软亚洲研究院主导，几乎和FatTree同时提出，开创了一个全新的思路，随后的年份里直到今天一直有各种改进版本的拓扑出现

这种服务器为核心的拓扑，主导思想是在服务器上增加网卡，服务器上要有路由转发逻辑来中转流量数据包，并且采用递推方式进行组网。

DCell的基本单元是DCell0，DCell0中服务器互联由一台T个端口的mini交换机完成，跨DCell的流量要通过服务器网卡互联进行绕转。通过一定数量的Dcell0组成一个DCell1，按照一定约束条件进行递推，组成DCell2以及DCellk
上图例中是一个DCell1的拓扑，包含5个Dcell0，每台服务器2个端口，除连接自己区域的mini交换机外，另一个端口会依次连接其他DCell0中的服务器，来组成全互联的结构，最终有20台服务器组成DCell1，所有服务器按照（m，n）坐标进行唯一标识，m相同的时候直接通过moni交换机交互，当m不同时经由mini交换机中继到互联服务器，例子中红色线为40服务器访问13服务器的访问路径。

DCell组网规则及递归约束条件如下：

DCellk中包含DCellk-1的数量为GK

DCellk中包含服务器为Tk个，每台服务器k+1块网卡，则有

GK=Tk-1+1

TK=Gk-1 ✕ Tk-1

设DCell0中有4台服务器

DCell1 中有5个DCell0 （G1=5）

Tk1=20台服务器（T1=20）

DCell2 中有21个DCell1 （G2=21）

Tk2=420台服务器（T2=420）

DCell3 中有421个DCell2 （G3=421）

Tk3=176820台服务器（T3=176820）

…

Tk6=3260000台服务器
经过测算DCell3中每台服务器的网卡数量为4，就能组建出包含17万台服务器的数据中心，同样DCell的缺点和优点一样耀眼，这种递归后指数增长的网卡需求量，在每台服务器上可能并不多，但是全量计算的话就太过于惊人了，虽然对比FatTree又再一次降低交换机的采购成本，但是天量的网卡可以想象对于运维的压力，还有关键的问题时高层次DCell间通信占用低层次DCell网卡带宽必然导致低层次DCell经常拥塞。最后还有一个实施的问题，天量的不同位置网卡布线对于施工的准确度以及未知的长度都是一个巨大的挑战。

DCell提出后，随后针对网卡数量、带宽抢占等一系列问题演化出来一批新的网络拓扑，思路无外乎两个方向，一个是增加交换机数量减少单服务网卡数量，趋同于spine-leaf体系，但是它一直保持了服务器多网卡的思路。另一种是极端一些，干脆消灭所有交换机，但是固定单服务器网卡数量，按照矩阵形式组建纯服务器互联结构，感兴趣的同学可以继续探索。

数据中心的路由框架涵盖范围和领域非常多，很多论文都选择其中的一个点进行讨论，比如源地址路由、流量调度、收敛、组播等等，不计划每个展开，也没有太大意义。但是针对之前FatTree的两阶段路由有一个更新的路由框架设计PortLand，它解决了两段路由中虚拟机无法迁移的问题，它的关键技术有以下几点

1、对于FatTree这种高度规范化的拓扑，PortLand设计为采用层次化MAC编址来支持大二层，这种路由框架中，除了虚拟机/物理机实际的MAC外（AMAC），还都拥有一个PortLand规范的伪MAC（PMAC），网络中的转发机制和PMAC强相关，PMAC的编址规则为

podpositionportvmid

pod (2字节) 代表虚拟机/服务器所在POD号，position（1字节）虚拟机/服务器所在Edge交换机在POD中编号，port（1字节）虚拟机/服务器连接Edge交换机端口的本地编号，vmid（2字节）服务器在Edge下挂以太网交换机编号，如果只有一台物理机vmid只能为1

2、虚拟机/服务器的编址搞定后，Edge、Aggregate、Core的编址呢，于是PortLand设计了一套拓扑发现机制LDP（location discovery protocol），要求交换机在各个端口上发送LDP报文LDM（location

discovery message）识别自己所处位置，LDM消息包含switch_id（交换机自身mac，与PMAC无关）pod（交换机所属pod号）pos（交换机在pod中的编号）level（Edge为0、Agg为1、Core为2）dir（上联为1，下联为-1），最开始的时候Edge角色会发现连接服务器的端口是没有LDM的，它就知道自己是Edge，Agg和Core角色依次收到LDM后会计算并确定出自己的leve和dir等信息。

3、设计一个fabric manager的集中PortLand控制器，它负责回答Edge交换机pod号和ARP解析，当Edge交换机学习到一个AMAC时，会计算一个PMAC，并把IP/AMAC/PMAC对应关系发送给fabric manager，后续有虚拟机/服务器请求此IP的ARP时，会回复PMAC地址给它，并使用这个PMAC进行通信。

4、由于PMAC的编址和pod、pos、level等信息关联，而所有交换机在LDM的交互过程中知晓了全网的交换机pod、pos、level、dir等信息，当数据包在网络中传播的时候，途径交换机根据PMAC进行解析可得到pod、pos这些信息，根据这些信息即可进行数据包的转发，数据包到达Edge后，Edge交换机会把PMAC改写为AMAC，因为它是知道其对应关系的。当虚拟机迁移后，由fabric manager来进行AMAC和PMAC对应更新和通知Edge交换机即可，论文中依靠虚拟机的免费ARP来触发，这点在实际情况中执行的效率要打一个问号。

不可否认，PortLand的一些设计思路非常巧妙，这种MAC地址重写非常有特色。规则设计中把更多的含义赋给PMAC，并且通过LDP机制设计为全网根据PMAC即可进行转发，再加上集中的控制平面fabric manager，已经及其类似我们熟悉的SDN。但是它对于转发芯片的要求可以看出要求比较低，但是所有的转发规则会改变，这需要业内对于芯片和软件的全部修改，是否能够成功也看市场驱动力吧，毕竟市场不全是技术驱动的。

除了我们熟悉的拓扑和路由框架方面，数据中心还有很多比较有意思的趋势在发生，挑几个有意思的

目前数据中心都是以太网有线网络，大量的高突发和高负载各个路由设架构都会涉及，但是如果使用无线是不是也能解决呢，于是极高频技术在数据中心也有了一定的研究（这里特指60GHZ无线），其吞吐可达4Gbps，通过特殊物理环境、波束成形、有向天线等技术使60GHZ部署在数据中心中，目前研究法相集中在无线调度和覆盖中，技术方案为Flyways，它通过合理的机柜摆放及无线节点空间排布来形成有效的整体系统，使用定向天线和波束成形技术提高连接速率等等新的技术，甚至还有一些论文提出了全无线数据中心，这样对数据中心的建设费用降低是非常有助力的。

数据中心目前应用的还是TCP，而TCP在特定场景下一定会遇到性能急剧下降的TCP incast现象，TCP的拥塞避免和慢启动会造成当一条链路拥塞时其承载的多个TCP流可能会同时触发TCP慢启动，但随着所有的TCP流流量增加后又会迅速达到拥塞而再次触发，造成网络中有时间流量很大，有时间流量又很小。如何来解决

数据中心还有很多应用有典型的组通信模式，比如分布式存储、软件升级等等，这种情况下组播是不是可以应用进来，但是组播在数据中心会不会水土不服，如何解决

还有就是数据中心的多路径，可否从TCP层面进行解决，让一条TCP流负载在不同的链路上，而不是在设备上依靠哈希五元组来对每一条流进行特定链路分配

对于TCPincast，一般通过减少RTO值使之匹配RTT，用随机的超时时间来重启动TCP传输。还有一种时设计新的控制算法来避免，甚至有方案抛弃TCP使用UDP来进行数据传输。

对于组播，数据中心的组播主要有将应用映射为网络层组播和单播的MCMD和Bloom Filter这种解决组播可扩展性的方案

对于多路径，提出多径TCP（MPTCP），在源端将数据拆分成诺干部分，并在同一对源和目的之间建立多个TCP连接进行传输，MPTCP对比传统TCP区别主要有

1、MPTCP建立阶段，要求服务器端向客户端返回服务器所有的地址信息

2、不同自流的源/目的可以相同，也可以不同，各个子流维护各自的序列号和滑动窗口，多个子流到达目的后，由接收端进行组装

3、MPTCP采用AIMD机制维护拥塞窗口，但各个子流的拥塞窗口增加与所有子流拥塞窗口的总和相关

还有部分针对TCP的优化，如D3协议，D3是针对数据中心的实时应用，通过分析数据流的大小和完成时间来分配传输速率，并且在网络资源紧张的时候可以主动断开某些预计无法完成传输的数据流，从而保证更多的数据流能按时完成。

这的数据中心节能不会谈风火水电以及液冷等等技术，从网络拓扑的角度谈起，我们所有数据中心拓扑搭建的过程中，主要针对传统树形拓扑提出了很多“富连接”的拓扑，来保证峰值的时候网络流量的保持性，但是同时也带来了不在峰值条件下能耗的增加，同时我们也知道数据中心流量多数情况下远低于其峰值设计，学术界针对这块设计了不少有脑洞的技术，主要分为两类，一类时降低硬件设备能耗，第二类时设计新型路由机制来降低能耗。

硬件能耗的降低主要从设备休眠和速率调整两个方面来实现，其难点主要时定时机制及唤醒速度的问题，当遇到突发流量交换机能否快速唤醒，人们通过缓存和定时器组合的方式进行。

节能路由机制，也是一个非常有特点的技术，核心思想是通过合理的选择路由，只使用一部分网络设备来承载流量，没有承载流量的设备进行休眠或者关闭。Elastic Tree提出了一种全网范围的能耗优化机制，它通过不断的检测数据中心流量状况，在保障可用性的前提下实时调整链路和网络设备状态，Elastic Tree探讨了bin-packer的贪心算法、最优化算法和拓扑感知的启发算法来实现节能的效果。

通过以上可以看到数据中心发展非常多样化，驱动这些技术发展的根本性力量就是成本，人们希望用最低的成本达成最优的数据中心效能，同时内部拓扑方案的研究已经慢慢成熟，目前设备厂商的羹汤可以说就是市场化选择的产物，但是数据中心网络传输协议、虚拟化、节能机制、SDN、服务链等方向的研究方兴未艾，尤其是应用定制的传输协议、虚拟网络带宽保障机制等等，这些学术方面的研究并不仅仅是纸上谈兵，对于我知道的一些信息来说，国内的阿里在它的数据中心网络拓扑中早已经应用了FatTree的变种拓扑，思科也把数据中心内部TCP重传的技术应用在自己的芯片中，称其为CONGA。

坦白来说，网络从来都不是数据中心和云计算的核心，可能未来也不会是，计算资源的形态之争才是主战场，但是网络恰恰是数据中心的一个难点，传统厂商、学术界、大厂都集中在此领域展开竞争，创新也层出不穷，希望能拓展我们的技术视野，能对我们有一些启发，莫听穿林打叶声、何妨吟啸且徐行~

您好，我来为您解答：
查看CPU型号,总个数
cat /proc/cpuinfo | grep name | cut -f2 -d: | uniq -c
查看CPU的单个核心数
cat /proc/cpuinfo | grep physical | uniq -c
如果我的回答没能帮助您，请继续追问。

单服务器容器规模指的是在一台服务器上运行多个容器实例的数量。这个数量通常受到服务器硬件资源的限制，如CPU、内存、磁盘空间等。对于一台具有良好硬件配置的服务器来说，可以运行数十甚至上百个容器实例。
但是，容器的规模并不仅仅与硬件资源有关，还与应用程序的特性有关。例如，一个I/O密集型的应用程序会大量使用磁盘I/O，可能会使磁盘资源成为瓶颈，从而影响容器的规模。另一个例子是内存密集型应用程序，可能会需要大量的内存才能支持运行，从而限制容器的数量。
因此，在确定单服务器容器规模时，需要考虑应用程序的特性和硬件资源的限制，并进行实际测试和评估，以确定最适合的容器数量。同时，还需要考虑容器之间的互相影响，以避免容器间的资源竞争和瓶颈问题。

说一道常见面试题：

一个很简单的答案就是去使用 Redission 客户端。Redission 中的锁方案就是 Redis 分布式锁得比较完美的详细方案。

那么，Redission 中的锁方案为什么会比较完美呢？

正好，我用 Redis 做分布式锁经验十分丰富，在实际工作中，也 探索 过许多种使用 Redis 做分布式锁的方案，经过了无数血泪教训。

所以，在谈及 Redission 锁为什么比较完美之前，先给大家看看我曾经使用 Redis 做分布式锁是遇到过的问题。

我曾经用 Redis 做分布式锁是想去解决一个用户抢优惠券的问题。这个业务需求是这样的：当用户领完一张优惠券后，优惠券的数量必须相应减一，如果优惠券抢光了，就不允许用户再抢了。

在实现时，先从数据库中先读出优惠券的数量进行判断，当优惠券大于 0，就进行允许领取优惠券，然后，再将优惠券数量减一后，写回数据库。

当时由于请求数量比较多，所以，我们使用了三台服务器去做分流。

这个时候会出现一个问题：

如果其中一台服务器上的 A 应用获取到了优惠券的数量之后，由于处理相关业务逻辑，未及时更新数据库的优惠券数量；在 A 应用处理业务逻辑的时候，另一台服务器上的 B 应用更新了优惠券数量。那么，等 A 应用去更新数据库中优惠券数量时，就会把 B 应用更新的优惠券数量覆盖掉。

看到这里，可能有人比较奇怪，为什么这里不直接使用 SQL：

原因是这样做，在没有分布式锁的协调下，优惠券数量可能直接会出现负数。因为当前优惠券数量为 1 的时候，如果两个用户通过两台服务器同时发起抢优惠券的请求，都满足优惠券大于 0 每个条件，然后都执行这条 SQL 说了句，结果优惠券数量直接变成 -1 了。

还有人说可以用乐观锁，比如使用如下 SQL:

这种方式就在一定几率下，很可能出现数据一直更新不上，导致长时间重试的情况。

所以，经过综合考虑，我们就采用了 Redis 分布式锁，通过互斥的方式，以防止多个客户端同时更新优惠券数量的方案。

当时，我们首先想到的就是使用 Redis 的 setnx 命令，setnx 命令其实就是 set if not exists 的简写。

当 key 设置值成功后，则返回 1，否则就返回 0。所以，这里 setnx 设置成功可以表示成获取到锁，如果失败，则说明已经有锁，可以被视作获取锁失败。

如果想要释放锁，执行任务 del 指令，把 key 删除即可。

利用这个特性，我们就可以让系统在执行优惠券逻辑之前，先去 Redis 中执行 setnx 指令。再根据指令执行结果，去判断是否获取到锁。如果获取到了，就继续执行业务，执行完再使用 del 指令去释放锁。如果没有获取到，就等待一定时间，重新再去获取锁。

乍一看，这一切没什么问题，使用 setnx 指令确实起到了想要的互斥效果。

但是，这是建立在所有运行环境都是正常的情况下的。一旦运行环境出现了异常，问题就出现了。

想一下，持有锁的应用突然崩溃了，或者所在的服务器宕机了，会出现什么情况？

这会造成死锁——持有锁的应用无法释放锁，其他应用根本也没有机会再去获取锁了。这会造成巨大的线上事故，我们要改进方案，解决这个问题。

怎么解决呢？咱们可以看到，造成死锁的根源是，一旦持有锁的应用出现问题，就不会去释放锁。从这个方向思考，可以在 Redis 上给 key 一个过期时间。

这样的话，即使出现问题，key 也会在一段时间后释放，是不是就解决了这个问题呢？实际上，大家也确实是这么做的。

不过，由于 setnx 这个指令本身无法设置超时时间，所以一般会采用两种办法来做这件事：

1、采用 lua 脚本，在使用 setnx 指令之后，再使用 expire 命令去给 key 设置过期时间。

2、直接使用 set(key,value,NX,EX,timeout) 指令，同时设置锁和超时时间。

以上两种方法，使用哪种方式都可以。

释放锁的脚本两种方式都一样，直接调用 Redis 的 del 指令即可。

到目前为止，我们的锁既起到了互斥效果，又不会因为某些持有锁的系统出现问题，导致死锁了。这样就完美了吗？

假设有这样一种情况，如果一个持有锁的应用，其持有的时间超过了我们设定的超时时间会怎样呢？会出现两种情况：

出现第一种情况比较正常。因为你毕竟执行任务超时了，key 被正常清除也是符合逻辑的。

但是最可怕的是第二种情况，发现设置的 key 还存在。这说明什么？说明当前存在的 key，是另外的应用设置的。

这时候如果持有锁超时的应用调用 del 指令去删除锁时，就会把别人设置的锁误删除，这会直接导致系统业务出现问题。

所以，为了解决这个问题，我们需要继续对 Redis 脚本进行改动……毁灭吧，累了……

首先，我们要让应用在获取锁的时候，去设置一个只有应用自己知道的独一无二的值。

通过这个唯一值，系统在释放锁的时候，就能识别出这锁是不是自己设置的。如果是自己设置的，就释放锁，也就是删除 key；如果不是，则什么都不做。

脚本如下：

或者

这里，ARGV[1] 是一个可传入的参数变量，可以传入唯一值。比如一个只有自己知道的 UUID 的值，或者通过雪球算法，生成只有自己持有的唯一 ID。

释放锁的脚本改成这样：

可以看到，从业务角度，无论如何，我们的分布式锁已经可以满足真正的业务需求了。能互斥，不死锁，不会误删除别人的锁，只有自己上的锁，自己可以释放。

一切都是那么美好！！！

可惜，还有个隐患，我们并未排除。这个隐患就是 Redis 自身。

要知道，lua 脚本都是用在 Redis 的单例上的。一旦 Redis 本身出现了问题，我们的分布式锁就没法用了，分布式锁没法用，对业务的正常运行会造成重大影响，这是我们无法接受的。

所以，我们需要把 Redis 搞成高可用的。一般来讲，解决 Redis 高可用的问题，都是使用主从集群。

但是搞主从集群，又会引入新的问题。主要问题在于，Redis 的主从数据同步有延迟。这种延迟会产生一个边界条件：当主机上的 Redis 已经被人建好了锁，但是锁数据还未同步到从机时，主机宕了。随后，从机提升为主机，此时从机上是没有以前主机设置好的锁数据的——锁丢了……丢了……了……

到这里，终于可以介绍 Redission（开源 Redis 客户端）了，我们来看看它怎么是实现 Redis 分布式锁的。

Redission 实现分布式锁的思想很简单，无论是主从集群还是 Redis Cluster 集群，它会对集群中的每个 Redis，挨个去执行设置 Redis 锁的脚本，也就是集群中的每个 Redis 都会包含设置好的锁数据。

我们通过一个例子来介绍一下。

假设 Redis 集群有 5 台机器，同时根据评估，锁的超时时间设置成 10 秒比较合适。

第 1 步，咱们先算出集群总的等待时间，集群总的等待时间是 5 秒（锁的超时时间 10 秒 / 2）。

第 2 步，用 5 秒除以 5 台机器数量，结果是 1 秒。这个 1 秒是连接每台 Redis 可接受的等待时间。

第 3 步，依次连接 5 台 Redis，并执行 lua 脚本设置锁，然后再做判断：

再额外多说一句，在很多业务逻辑里，其实对锁的超时时间是没有需求的。

比如，凌晨批量执行处理的任务，可能需要分布式锁保证任务不会被重复执行。此时，任务要执行多长时间是不明确的。如果设置分布式锁的超时时间在这里，并没有太大意义。但是，不设置超时时间，又会引发死锁问题。

所以，解决这种问题的通用办法是，每个持有锁的客户端都启动一个后台线程，通过执行特定的 lua 脚本，去不断地刷新 Redis 中的 key 超时时间，使得在任务执行完成前，key 不会被清除掉。

脚本如下：

其中，ARGV[1] 是可传入的参数变量，表示持有锁的系统的唯一值，也就是只有持有锁的客户端才能刷新 key 的超时时间。

到此为止，一个完整的分布式锁才算实现完毕。总结实现方案如下：

这个分布式锁满足如下四个条件：

当然，在 Redission 中的脚本，为了保证锁的可重入，又对 lua 脚本做了一定的修改，现在把完整的 lua 脚本贴在下面。

获取锁的 lua 脚本：

对应的刷新锁超时时间的脚本：

对应的释放锁的脚本：

到现在为止，使用 Redis 作为分布式锁的详细方案就写完了。

我既写了一步一坑的坎坷经历，也写明了各个问题和解决问题的细节，希望大家看完能有所收获。

最后再给大家提个醒，使用 Redis 集群做分布式锁，有一定的争议性，还需要大家在实际用的时候，根据现实情况，做出更好的选择和取舍。

原文 >