redis并发锁机制_多线程并发问题解决之redis锁

一 问题背景

我们做的是医疗信息化系统，在系统中一条患者信息对医院中当前科室中的所有诊断医生是可见的，当有一个诊断医生点击按钮处理该数据时，数据的状态发生了变化，其他的医生就不可以再处理此患者的数据了。我们开始的做法是，在医生点击按钮时先去后台数据库获取当前数据状态，根据状态判断数据是否可以操作，如果可以操作，则修改数据状态，进行业务逻辑处理，否则提示数据已被其他人处理，不能处理。

二 问题分析

按照上边的业务逻辑，我们画个图分析，如下图

在上图中，如果用户A和B同时向数据库发起请求获取数据状态，数据库返回wait，A和B都拿到了相同的状态，判断是可以操作数据的，这时他们处理数据。A用户处理完成后提交了数据，数据库状态变为done，记录此数据的处理人为A。由于B用户也可以处理数据，所以他也提交数据，这时数据的操作人记录为了B。有人会说，在A和B提交数据修改状态时再做一个状态的判断，这种也难以避免最开始的获取状态的问题，即使这一步状态获取到了，提示后边的人不能修改，这又会产生系统不友好的问题(我操作了半天，到最后你告诉我不能处理，我白忙活了)。以上问题产生的主要原因就是在多线程情况下对共享数据的资源竞争处理不当，