4.1 使用悲观锁的理念，实际就是在并发的关键地方，强制将“类似并行”改为串行，相关的一些处理方式：
4.1.1 数据库锁，利用数据库的自身的事务隔离机制（Isolation），进行排他操作。
4.1.1.1
极端的在查询时，直接开启事务设置行锁（rowlock）。串行目的是达到了，但即时在单机系统中，也无法承受巨大的性能损耗。并且最终的超卖问题也没有解决，非常不推荐。
4.1.1.2
仅利用数据库在update时造成的排他锁，使真实更新时串行，并增加库存判断，若库存发生变动，则更新无效，超卖问题也不会发生。譬如（以SQL SERVER 举例）：
update PT set qty = qty - N where id = pid and qty >= N;
严格来讲，这依然是一个较粗的粒度，但不得不说，在单机环境下有一定的可行性。同时，需要考虑高并发情况下（例如商户举办活动，同时参与用户过多）存在一定性能瓶颈，数据库IO负载过大。此时需要结合其他方案，包括增加上层缓存层等。甚至部分场景需要单独设计一套流程（例如秒杀抢购场景，首先就是应用到队列，否则网站可能没崩溃在并发请求数上，而是直接挂在了DB上，后面会有相关阐述）
4.1.2 使用程序锁（单机线程锁和分布式调度锁），使部分关键代码串行。
4.1.2.1
极端的直接使用程序自带的全局线程锁，以.NET Framewok 举例，里面有各级粒度的锁，常用的轻量锁有lock（Mointor语法糖）、SpinLock（自旋锁）。使用它们，最早大概是应用在“单例模式”的构建，原理本身不复杂，使用也方便，并且也达到了串行的目的。
然而，放在下单库存管控这里，串行的却是所有用户进行任意商品下单操作，打击面太大（甚至直接上升到全面打击），对性能造成极大影响，不可行，不过多延伸，也不推荐。（曾经优化一个旧项目里的模块，初步Review代码时就发现了几处不经意的地方竟直接使用了这种写法，而开发人员还是两名老员工）。
4.1.2.2
构建一个本地的线程锁管理器（这里称为LockerManage），统一分配锁对象（等待对象）。其本质是针对上面4.1.2.1方式的包装处理，实现类似“工厂模式”的机制。主要是通过它来生产具有唯一特征的Object对象，这个对象将会作为锁对象资源返回给Monitor等调用，并具有一定的使用时效，每次生成后保存在内部的线程安全的集合里，同时具有自动销毁机制（运行一个独立线程，定时检查清理）。其中有个小细节，为了优化管理器内部的并发问题，开始使用的是.NET Framewok 里自带的线程安全的字典集合（ConcurrentDictionary），后来经测试，发现并发处理并不理想，后面便换了其他方案（读写分离）。回归到下单这里，这里依然以商品P为例，首先调用LockerManage，获取一个以当前商品主键为标识的Object对象，然后在库存的预扣核对时，使用Mointor加锁处理。（当然，这里是本机锁，后续有说明）。这种方式对比数据库锁，则是降低数据库的操作，而将压力大部分转移到了程序上，但相对可以更灵活的去操控。
4.1.2.3
使用分布式锁。上面的普通程序锁作为单机的存在，决定了其在分布式架构上的不可控性，而这时就有了分布式调度锁。它主要是为了方便解决分布式情况下，在多个Web程序内实现并发线程的一个管控。值得一提的是，这个“轮子”并不需要手动重新创造，目前市面上已经有相对成熟的解决方案，如利用Z ookeeper和Redis。在AutumnBing项目中，当时选择的是Redis，使用的驱动库是StackExchange.Redis。（后续听到朋友提到Z ookeeper 更适合充当这样的角色，但由于目前自己还没有太多涉猎研究，暂时持保留态度）。当然，纯粹采用分布式锁，自然调用性能会有更多损耗。而相对更合理的做法，是结合单机锁搭配应用（试讨论，分布式锁放置外层，单机锁放置内部，每个站点各自维护）。
4.2 遵循乐观锁的理念，则是默许不会有太大的并发问题（聚焦在小粒度的商品P上，则是认为大多数情况下P不会被同时消费），“放任”线程的执行，不做管控。但是会在关键地方进行版本核对，假如失败，则内部重试或抛出失败信号。
4.2.1 数据库层面上，增加显式的版本号字段（ver）。
购买商品P，下单这里需要获取到当前时刻对应的库存qty01，当前记录是版本ver01，然后在真实更新时，再次查询商品P的库存，以及对应的当前的版本ver02，如果 ver01 == ver02，那么可以更新。否则，当前数据已因并发被修改，无法更新。这更像是数据库的“不可重复读”，而出现这种情况后（高并发情况下，出现概率直线上升），必须附有关联的内部尝试机制（注意保证幂等性）。 这是一种实现并发管控的方案，但只适合存在并发，但并发量不太大的情况，否则，一是违背乐观锁的理念初衷，二是整体性能以及体验会大打折扣。
4.2.2 程序控制上，采取队列（queue）方式，进行相对集中化预受理，然后分发逐个处理。
需要声明，这里本身执行原理，其实质依然离不开类似悲观锁的管控性质，一是入队时需要有个小粒度的锁机制保证串行（当然也可以是其他方式，这是队列内部的管控机制之一），二是出队，例如分发到不同服务上去处理，最终也是一个一个在操作更新（依然是某种程度上的串行）。但是，作为用户下单的提交，本身是保证了乐观的态度，一股脑“同时”或者“快速”接收，然后再考虑如何告知处理。
由于单机队列的应用，会出现更多类似上面单机锁的一些额外问题，这里不推荐（当然你可以结合），也不做扩展说明。下面仅就分布式队列在大方向上举例阐述。
如何采用分布式队列来实现下单以及库存管控呢？依然以商品P为例，用户同时购买商品P，本身是一个并发操作，但是我们可以将一系列的请求商品扣减数据Push到一个队列中（生产者开始生产），然后由专门的线程进行订阅消费（消费者开始消费）。暂且假定为一个线程在消费，那么该线程具体消费时，逐个将商品数据出队，进行库存扣减，这里必然不会出现并发。消费完毕，无论扣除库存逻辑上是成功还是失败，均给出一个应答（ACK）。注意这里并没有过多的拆分逻辑，而是将下单的一些操作扔进一个队列中，使用专门的程序去逐个或者逐几个（分批）处理。实际使用往往是根据业务，做更小粒度的拆分和调整。另外，关于技术框架选型，目前各类开源成熟的MQ项目比比皆是，个人圈子里了解到最多的还是 RabbitMQ，对于多个生产者以及与之配合的多个消费者，还有应答处理机制，包括本身的性能和高可用性，均极其出色。额外的，关于web前端，很多时候则是需要配合一些轮询机制来检查订单状态（当然，轮询这里也有一些具体细节，比如异步体验、轮询时长和状态重置等考虑）
五、涉及到分布式SOA架构体系（包括如今基于SOA开始流行的微服务架构）情况下的一些额外考虑。
首先声明，个人认为SOA只是一种架构上的抽离设计，本身与论述的库存管控没有直接关系。但这里以库存管控为例，也有需要额外考虑的地方。
我们假定在一个下单API中，包含了3个独立的API接口：A-积分扣减API，B-优惠券扣减API，C-库存扣减API。考虑一种情况：假定库存本身可以被合法扣除，并且执行C成功了，但是发生了其他问题，A或者B执行失败了，那库存该如何回滚。
必须纠正的是，在这样一个耦合性系统场景里（而上例仅是其中一种案例），需要解决的问题本质和库存如何扣减没有丝毫直接关系，其暴露的实质问题是如何实现一个分布式事务机制。这是一个比较大的专题，实现相对复杂，开发成本也足够高。基于单一RPC接口，到如今流行的更小粒度的微服务，都足够写一本书了。截止目前个人的了解，如早期的2PC （两阶段）、3PC（三阶段）、TCC（补偿事务），以及后来的纯消息列表式方案等等，均是一些无法达到完美的理论（性能、时效、复杂度等）。至于实践上，自然就没有绝对OK的方案，只能根据项目规模和实际业务做些取舍，最终得到一个尽量满足的“高可用”方案。以后待到经验足够，有机会尝试一下单独开篇讨论。（对于分布式事务，写过一些demo，却应用不深，以后会考虑抽个专门的时间在续篇中尝试撰写探讨）。
六、结合高并发场景（如：秒杀活动），简单聊聊如何关联各类技术手段，进行下单及库存管控的应用。
在电商系统里，并发简直无处不在，目前较为突出的一个场景，则是秒杀活动。所谓秒杀，最简单直观的场景如下：在某个时刻，商品P开放购买（P的实际库存仅为1个或者几个），大批量的用户同时进行下单抢购。
秒杀时并发量之大远远超过一般情况下的并发（你要考虑到不止一个商品），甚至还会影响到商城里现有其他业务（这里讨论非独立部署）。需要考虑诸多细节，以及大量技术手段来进行有效管控。以下简单聊聊后台下单相关问题，不讨论其他前端处理技术，包括定时查询，页面静态化，网络带宽优化等。
6.1 明确业务本质需求，脱离业务，当然谈不了任何技术架构和实现方案。
秒杀的业务场景，宏观上来说，就是一个典型的排序模型。谁先来，谁先得到。这里我们尽量简化举例：假定商品P库存为10，同时参与下单的用户数为100000。那么，最终只有开始的（理论上的）10个用户购买成功，其余99990个用户购买失败。商品库存被成功消费为0。
6.2 防作弊等安全监测，从RPC的第一个接口开始，就进行过滤。
例如，在杂记上一篇中提到的（见第一篇主题三），做好基础的安全监测机制。如相同IP的僵尸账号，做限制IP的访问，并增加验证码等。同时，包括但不限于一些额外的业务辅助手段，如限制仅满足一定注册时间的用户可下单等。
6.3 限流机制，在外层计数，达到一个下单阈值，直接抛弃。
从6.1中就可以发现，秒杀业务本身就注定了大部分人是抢不到的，那么针对大部分人的下单请求，完全就可以不做处理（直接抛弃）。在进行真正的下单操作之前，可在具体操作接口上，增加一个拦截计数器来统计，比如当计数超过3000时，后续下单直接返回抢购失败的信息。这样就将数据处理由大化小了，实现了限流（仅针对下单）。当然，具体实现时，这个3000名额推荐是筛选后的。比如，先过滤8000，从中随机抽取3000（这里不扩展）。
6.4 从数据库角度，首先就是要增加单独的临时缓存层。
即使是3000的量，在这个环节也肯定是不能直接操作数据库的（你要明白，实际秒杀的商品，不只一个），直接读库写库对数据库压力太大，甚至直接负载过大导致数据库挂掉。那么，针对这种情况，推荐的一种方案就是结合缓存来操作。譬如：把商品P * 10 这条数据提前Push到专门的缓存中，然后每次读取和更新，均是走的该缓存。这里额外提到一点，如果用户下单成功，预扣库存 -1，但又未进行安全时间内的支付，那么系统将自动回滚商品P的库存，进行 +1（当然，回滚同样需要协调处理并发）。
6.5 从程序角度，修改库存依然需要保证一定串行。
首先，如果保证DAL的串行，可以是数据库上锁，也可以是程序上锁（或者队列）。但如果直接数据库上锁，诸多并发请求（依然考虑到，单时间内的多个商品被多用户抢购），即使前面削减了部分下单处理，数据库的I/O负载依然会很严重。那么，首先就是推荐乐观进队列，然后悲观进分布式程序锁，混合处理（即是对主题四的结合应用）。
结语
电商项目里，几乎处处是并发，无论是单机还是分布式架构。结合下单库存管控相关，我们可以深刻理解解决这些并发性能问题和并发安全顾虑，即使是同一类型的业务，也有诸多方案，每种方案都有一些细粒度的问题需要尝试克服，更需结合实际项目（具体业务性质和规模），做一些实现上的各种优化与权衡等。