标签：

如果在对某行记录的更新时不采取任何防范措施,在多线程访问时,就容易出现库存为负数的错误.

以下用php、mysql,apache ab工具举例说明:

mysql表结构

CREATE TABLE`yxt_test_concurrence` (

`id`int(11) NOT NULLAUTO_INCREMENT,

`value`int(11) NOT NULL COMMENT ‘库存‘,PRIMARY KEY(`id`)

) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci COMMENT=‘库存表‘;

CREATE TABLE`yxt_test_pv` (

`id`int(10) unsigned NOT NULLAUTO_INCREMENT,

`val`int(255) DEFAULT NULL COMMENT ‘该线程读取到的库存数量‘,PRIMARY KEY(`id`)

) ENGINE=MyISAM AUTO_INCREMENT=351 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci COMMENT=‘访问记录表,每次访问都增加一条记录,并记录此次访问时的库存数‘;

在库存表中存入模拟库存500个.

在此,为方便,php采用TP框架:

public functiontc(){$this->tc = M("test_concurrence");//模拟商品的剩余数量

$this->pv = M("test_pv");//模拟访问次数

$res=$this->tc->field(‘value‘)->find(1);//查到的剩余数量

$value=$res[‘value‘];if($value>0){//如果大于0,则进行下面的逻辑

$this->pv->data(array(‘val‘=>$value))->add();//这个是用来记录访问的次数,并记录此次访问时的库存数

M()->execute("UPDATE `yxt_test_concurrence` SET `value`=`value` - 1 WHERE `id` = 1");//商品数量减1}

}

使用ab工具模拟并发访问:

C:\Users\chenhui>ab -c 50 -n 500 http://study.com/course/Course/tc/

This is ApacheBench, Version 2.3Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking studyyxtcmf.com (be patient)

Completed 100 requests

Completed 200 requests

Completed 300 requests

Completed 400 requests

Completed 500 requests

Finished 500 requests

Server Software: Apache/2.4.9

Server Hostname: studyyxtcmf.com

Server Port: 80

Document Path: /course/Course/tc/

Document Length: 25786 bytes

Concurrency Level: 50

Time taken for tests: 60.035 seconds

Complete requests: 500

Failed requests: 450

(Connect: 0, Receive: 0, Length: 450, Exceptions: 0)

Total transferred: 12973630 bytes

HTML transferred: 12785130 bytes

Requests per second: 8.33 [#/sec] (mean)

Time per request: 6003.543 [ms] (mean)

Time per request: 120.071 [ms] (mean, across all concurrent requests)

Transfer rate: 211.03 [Kbytes/sec] received

Connection Times (ms)

min mean[+/-sd] median max

Connect: 0 1 2.1 1 34

Processing: 781 5915 1578.6 5996 12272

Waiting: 765 5901 1581.8 5983 12261

Total: 783 5916 1578.4 5997 12272

Percentage of the requests served within a certain time (ms)

50% 5997

66% 6385

75% 6707

80% 6850

90% 7387

95% 8402

98% 9734

99% 10300

100% 12272 (longest request)

查看数据库记录:

SELECT * fromyxt_test_pv;--截取一段记录(左边是第几次访问,右侧是当次访问看到的库存)

| 338 | 164 |

| 339 | 164 |

| 340 | 163 |

| 341 | 162 |

| 342 | 162 |

| 343 | 162 |

| 344 | 162 |

| 345 | 157 |

| 346 | 156 |

| 347 | 156 |

| 348 | 153 |

| 349 | 155 |

| 350 | 151 |

可以发现在341-343次读取的库存数量是一样的,在库存还很多的情况时,并不会出现问题:因为程序中减库存的逻辑,是当前库存量减去1.但是库存不多的时候,就很可能出现问题,比如库存只有一个了,而此时有多个线程查询到此时还有一个库存,因为1>0满足条件,所以库存减1,多个线程都对当前库存减1,最后就多减了库存,出现负数,这是不允许的.

所以一定要采取措施.

我认为,总的原则是:对于某一个时刻的库存,只允许一个会话去修改.要满足此条件.有两种选择:

1.对于某一个时刻的库存,只允许一个会话去读取(锁机制).待锁被释放后,其他会话才可以读取库存.

2.对于某一个时刻的库存,设定版本(即增加一个版本字段,用于比较.我对版本的理解是刻个记号),更新库存时要判断版本是否发生变化,若没发生变化,则更新库存的同时,更新版本号.若更新库存时发现版本发生变化了,那一定是有别的线程早已对库存修改,此情况下就放弃修改.

选择1.使用mysql的锁机制.(悲观锁)

public functiontc(){$this->tc = M("test_concurrence");//模拟商品的剩余数量

$this->pv = M("test_pv");//模拟访问次数

//对表加锁,注意,如果加锁过程中要操作多个表,要对这几个表都加锁,否则会报错

//mysql> lock table yxt_test_concurrence read;--只锁了一张表

//Query OK, 0 rows affected (0.00 sec)

//mysql> SELECT * from yxt_test_pv;--读取没有被锁的表

//ERROR 1100 (HY000): Table ‘yxt_test_pv‘ was not locked with LOCK TABLES--报错,提示查询的表没有被锁住

M()->execute("lock tables yxt_test_concurrence write,yxt_test_pv write;");$res=$this->tc->field(‘value‘)->find(1);//查到的剩余数量

$value=$res[‘value‘];if($value>0){//如果大于0,则进行下面的逻辑

$this->pv->data(array(‘val‘=>$value))->add();//这个是用来记录访问的次数

M()->execute("UPDATE `yxt_test_concurrence` SET `value`=`value` - 1 WHERE `id` = 1");//商品数量减1

}//解锁

M()->execute("unlock tables");

}

采用锁机制,可以严格控制库存数量的变化,但是采用锁会增加数据库的开销.

选择2.版本控制(乐观锁)

乐观锁,是假定事务之间是互不干扰的,事务在访问数据的时候,并不会获取锁,但是,在提交前,每个事务都要确保其他事务并没有修改他读取到的数据.如果在更新数据时发现其他事务已经修改了数据,则回滚提交.乐观锁经常用于"低争用数据结构"的场景中.当冲突特别少的时候,事务可以在完成时,不需要管理锁的开销及等待其他事务释放锁,这可以带来更高的吞吐率.但是,如果对于数据的争用特别频繁,重新开启一个新事务的开销会明显影响性能.

通常认为,其他并发控制方法,在此情况下会有更好的表现,然而,基于悲观锁的方法,会导致较差的性能.因为即使死锁可以避免,"锁"仍会极大的影响并发性能.(我想应该是因为会话被阻塞,从而导致只能串行访问数据库)

以上定义摘自wiki:https://en.wikipedia.org/wiki/Optimistic_concurrency_control

这种情况下,如果并发访问,则修改失败的几率会较高,

举例:在热销产品场景下则容易出现购买失败的情况.这对用户的体验是不好的.因为这意味着又要重新尝试一次.

小结:应该采取哪一种锁,应根据实际场景来权衡利弊,如果更新的很频繁,那应该使用悲观锁.此刻需要考虑的问题是:如何解决并发问题.如果很少更新,则使用乐观锁更为方便省事.

标签：