业务复杂、数据量大、并发量大的业务场景下，典型的互联网架构，一般会分为这么几层：
调用层，一般是处于端上的浏览器或者App；
站点层，一般是拼装html或者json返回的web-server层；
服务器，一般是提供RPC调用接口的service层；
数据层，提供固化数据存储的db
对于库存业务，一般有个库存服务(stock-service)提供库存的查询get stock、扣减reduce stock、设置set stock等RPC接口。
库存查询，stock-service本质上执行的是：
select num from stock where id=$id;
库存扣减，stock-service本质上执行的是：
update stock set num = num - $reduce where id=$id;
库存设置，stock-service本质上执行的是：
update stock set num = $new_num where id=$id;
用户下单前，一般会对库存进行查询，有足够的存量才允许扣减。
但是在并发量很大的情况下，会有问题：比如2个并发操作，查询库存，得到的值都是5。接下来用户发生了并发的购买动作(秒杀类业务特别容易出现)：
用户1购买了3个，于是库存修改为2；
用户2购买了2个，于是库存要修改为3。
这2个修改库存的接口并发执行，库存会先变成2，再变成3，导致数据不一致，（实际卖出了5件商品，但是库存只扣减了2）。
其根本原因是，修改库存操作发生的时候，没有检查库存和查询出来的库存有没有变化。
升级库存设置接口也很容易：
update stock set num = $new_new where id=$id and num = $old_num;
这就是大家常说的Compare And Set（CAS），是一种常见的降低读写锁冲突、保证数据一致性的方法。