https://mp.weixin.qq.com/s/1AwHJ7CGxf8DQxSjYUeTvg
First of all, building an eCommerce website requires things like database design, system availability, concurrency consideration and so on so forth. All of them are extremely important in today’s distributed systems.
- （实现方案2）如果用户提交订单时进行库存预占，那么将也只能有1个用户将1000个商品提单成功，其它的人均提示“库存不足，提单失败”。
- （实现方案3）如果用户提交订单&支付成功时进行库存预占，那么这1000个人都能生成订单，但是只有1个人可以支付成功，其它的订单均会被自动取消。
京东到家目前采用的是方案2，理由：
- 用户可能只是暂时加入购物车，并不表示用户最终会提单并支付。
- 所以在购物车进行库存校验并预占，会造成其它真正想买的用户不能加入购物车的情况，但是之前加车的用户一直不付款，最终损失的是公司。
- 方案3会造成生成1000个订单，无论是在支付前校验库存还是在支付成功后再检验库存，都会造成用户准备好支付条件后却会出现99.9%的系统取消订单的概率，也就是说会给99.9%的用户体验到不爽的感觉。
- 数据表明用户提交订单不支付的占比是非常小的（相对于加入购物车不购买的行为），目前京东到家给用户预留的最长支付时间是30分钟，超过30分钟订单自动取消，预占的库存自动释放
综上所述，方案2也可能由于用户下单预占库存但最终未支付，造成库存30分钟后才能被其它用户使用的情况，但是相较于方案1，方案3无疑是折中的最好方案。
重复提交订单的问题？
重复提交订单造成的库存重复扣减的后果是比较严重的。比如商家设置有1000件商品，而实际情况可能卖了900件就提示用户无货了，给商家造成无形的损失
可能出现重复提交订单的情况：
- （1、用户善意行为）app上用户单击“提交订单”按钮后由于后端接口没有返回，用户以为没有操作成功会再次单击“提交订单”按钮
- （2、用户恶意行为）黑客直接刷提单接口，绕过App端防重提交功能
- （3、提单系统重试）比如提单系统为了提高系统的可用性，在第一次调用库存系统扣减接口超时后会重试再次提交扣减请求
好了，既然问题根源缕清楚了，我们一一对症下药
- （1、用户善意行为）app侧在用户第一次单击“提交订单”按钮后对按钮进行置灰，禁止再次提交订单
- （2、用户恶意行为）采用令牌机制，用户每次进入结算页，提单系统会颁发一个令牌ID（全局唯一），当用户点击“提交订单”按钮时发起的网络请求中会带上这个令牌ID,这个时候提单系统会优先进行令牌ID验证，令牌ID存在&令牌ID访问次数=1的话才会放行处理后续逻辑，否则直接返回
- （3、提单系统重试）这种情况则需要后端系统（比如库存系统）来保证接口的幂等性，每次调用库存系统时均带上订单号，库存系统会基于订单号增加一个分布式事务锁，伪代码如下：
- int ret=redis.incr(orderId);
- redis.expire(orderId,5,TimeUnit.MINUTES);
- if(ret==1){//添加成功，说明之前没有处理过这个订单号或者5分钟之前处理过了
- boolean alreadySuccess=alreadySuccessDoOrder(orderProductRequest);
- if(!alreadySuccess){
- doOrder(orderProductRequest);
- }else{
- return "操作失败，原因：重复提交";
- }
- }else{
- return "操作失败，原因：重复提交";
- }
库存数据的回滚机制如何做
需要库存回滚的场景也是比较多的，比如：
- （1、用户未支付）用户下单后后悔了
- （2、用户支付后取消）用户下单&支付后后悔了
- （3、风控取消）风控识别到异常行为，强制取消订单
- （4、耦合系统故障）比如提交订单时提单系统T1同时会调用积分扣减系统X1、库存扣减系统X2、优惠券系统X3，假如X1,X2成功后，调用X3失败，需要回滚用户积分与商家库存。
其中场景1，2，3比较类似，都会造成订单取消，订单中心取消后会发送mq出来，各个系统保证自己能够正确消费订单取消MQ即可。而场景4订单其实尚未生成，相对来说要复杂些，如上面提到的，提单系统T1需要主动发起库存系统X2、优惠券系统X3的回滚请求（入参必须带上订单号），X2、X3回滚接口需要支持幂等性。其实针对场景4，还存在一种极端情况，如果提单系统T1准备回滚时自身也宕机了，那么库存系统X2、优惠券系统X3就必须依靠自己为完成回滚操作了，也就是说具备自我数据健康检查的能力，具体来说怎么实现呢？可以利用当前订单号所属的订单尚未生成的特点，可以通过worker机制，每次捞取40分钟（这里的40一定要大于容忍用户的支付时间）前的订单，调用订单中心查询订单的状态，确保不是已取消的，否则进行自我数据的回滚。
多人同时购买1件商品，如何安全地库存扣减
现实中同一件商品可能会出现多人同时购买的情况，我们可以如何做到并发安全呢？
可能出现重复提交订单的情况：
- （1、用户善意行为）app上用户单击“提交订单”按钮后由于后端接口没有返回，用户以为没有操作成功会再次单击“提交订单”按钮
- （2、用户恶意行为）黑客直接刷提单接口，绕过App端防重提交功能
- （3、提单系统重试）比如提单系统为了提高系统的可用性，在第一次调用库存系统扣减接口超时后会重试再次提交扣减请求
好了，既然问题根源缕清楚了，我们一一对症下药
- （1、用户善意行为）app侧在用户第一次单击“提交订单”按钮后对按钮进行置灰，禁止再次提交订单
- （2、用户恶意行为）采用令牌机制，用户每次进入结算页，提单系统会颁发一个令牌ID（全局唯一），当用户点击“提交订单”按钮时发起的网络请求中会带上这个令牌ID,这个时候提单系统会优先进行令牌ID验证，令牌ID存在&令牌ID访问次数=1的话才会放行处理后续逻辑，否则直接返回
- （3、提单系统重试）这种情况则需要后端系统（比如库存系统）来保证接口的幂等性，每次调用库存系统时均带上订单号，库存系统会基于订单号增加一个分布式事务锁，伪代码如下：
- int ret=redis.incr(orderId);
- redis.expire(orderId,5,TimeUnit.MINUTES);
- if(ret==1){//添加成功，说明之前没有处理过这个订单号或者5分钟之前处理过了
- boolean alreadySuccess=alreadySuccessDoOrder(orderProductRequest);
- if(!alreadySuccess){
- doOrder(orderProductRequest);
- }else{
- return "操作失败，原因：重复提交";
- }
- }else{
- return "操作失败，原因：重复提交";
- }
库存数据的回滚机制如何做
需要库存回滚的场景也是比较多的，比如：
- （1、用户未支付）用户下单后后悔了
- （2、用户支付后取消）用户下单&支付后后悔了
- （3、风控取消）风控识别到异常行为，强制取消订单
- （4、耦合系统故障）比如提交订单时提单系统T1同时会调用积分扣减系统X1、库存扣减系统X2、优惠券系统X3，假如X1,X2成功后，调用X3失败，需要回滚用户积分与商家库存。
其中场景1，2，3比较类似，都会造成订单取消，订单中心取消后会发送mq出来，各个系统保证自己能够正确消费订单取消MQ即可。而场景4订单其实尚未生成，相对来说要复杂些，如上面提到的，提单系统T1需要主动发起库存系统X2、优惠券系统X3的回滚请求（入参必须带上订单号），X2、X3回滚接口需要支持幂等性。其实针对场景4，还存在一种极端情况，如果提单系统T1准备回滚时自身也宕机了，那么库存系统X2、优惠券系统X3就必须依靠自己为完成回滚操作了，也就是说具备自我数据健康检查的能力，具体来说怎么实现呢？可以利用当前订单号所属的订单尚未生成的特点，可以通过worker机制，每次捞取40分钟（这里的40一定要大于容忍用户的支付时间）前的订单，调用订单中心查询订单的状态，确保不是已取消的，否则进行自我数据的回滚。
多人同时购买1件商品，如何安全地库存扣减
现实中同一件商品可能会出现多人同时购买的情况，我们可以如何做到并发安全呢？
伪代码片段1：
伪代码片段1的设计思想是所有的请求过来之后首先加锁，强制其串行化处理，可见其效率一定不高，
伪代码片段2：
这段代码只是在where条件里增加了and stockNum>="+requestBuyNum即可防止超卖的行为，达到了与上述伪代码1的功能
如果商品是促销品（比如参与了秒杀的商品）并发扣减的机率会更高，那么数据库的压力会更高，这个时候还可以怎么做呢 海量的用户秒杀请求,本质上是一个排序,先到先得.但是如此之多的请求，注定了有些人是抢不到的，可以在进入上述伪代码Dao层之前增加一个计数器进行控制，比如有50%的流量将直接告诉其抢购失败，
另外同一个用户，不允许多次抢购同一件商品，我们又该如何做呢
http://blog.gainlo.co/index.php/2016/08/22/design-ecommerce-website-part/
First of all, building an eCommerce website requires things like database design, system availability, concurrency consideration and so on so forth. All of them are extremely important in today’s distributed systems.
a common strategy of system design interview is starting with simple and basic things instead of jumping into details directly. So how would you design the basic data structure of an eCommerce website? And what about the database schema?
I’ll skip the data structure for user models as it should be quite similar to other applications. Let’s focus on the product. In the simplest scenario, we need three major objects: Product, User and Order.
Product defines the basic model for a product in the shopping cart. Some important fields include price, the amount left, name, description, and the category. Category can be tricky here. Of course you can make it a string field in the SQL database, but a better approach is to have a Category table that contains category ID, name and maybe other information. So the each product can keep a category ID.
Order stores information about all the orders made by users. So each row contains the product ID, user ID, amount, timestamp, status and so on. So when a user proceeds to checkout, we aggregate all the entries associated with this user to display in the shopping cart (of course we should filter out items that were bought in the past).
NoSQL in eCommerce
In the above analysis, we are using a relational database like MySQL. In reality, NoSQL database can be a better choice for eCommerce website sometimes.
In case many people don’t know about NoSQL, in layman’s term, NoSQL database tries to store a bunch of things in a single row instead of multiple tables. For instance, instead of having a separate Order table, we can store all the items a user has bought in the same row of User table. As a result, when fetching a user, not only will we get all the personal information, but also his purchase history.
Why can NoSQL be (slightly) better in this case? Let’s use Product model as an example. Suppose we are selling books. A product has category book and tons of attributes like author, publish date, version, the number of pages etc. and this SQL table may have 20 columns. That’s fine.
And now, we also want to sell laptops. So a product should also store attributes of a laptop including brand name, size, color etc.. As you can imagine, with more categories introduced, the Product table can have tons of columns. If each category has 10 attributes in average, it’s gonna be 100 columns with only 10 categories supported!
However, for NoSQL database like MongoDB, a great advantage is that it supports huge number “columns” like this. Each row can have a large number columns but not all of them are set. It’s like storing JSON object as a row (in fact, MongoDB is using something very similar called BSON). As a result, we can just store all those attributes (columns) of a product in a single row, which is exactly what NoSQL database good at.
Concurrency
Take concurrency as an example. let’s say there’s only one book left in the store and two people buy it simultaneously. Without any concurrency mechanism, it’s absolutely possible that both have bought it successfully. How do you achieve concurrency in eCommerce websites?
Let’s analyze this step by step. From what we learned from OS classes, we know that lock is the most common technique to protect common resources. Suppose both user A and B want to buy the same book. What we can do is when A fetches the data about this book, place a lock on this row so that no one else can access it. Once A finishes the purchase (decrease the amount left), we release the lock so that B can access the data. The same approach should apply for all the resources and this can solve the problem totally.
The above solution is called pessimistic concurrency control. Although it prevents all the conflicts caused by concurrency, the downside is that it’s costly. Obviously, for every data access we need to create and release a lock, which may be unnecessary most of the time.
Can we solve the problem without a lock?
Although the approach can prevent two people accessing the same data simultaneously, placing locks is quite costly. How would you solve this problem more efficiently?
Optimistic concurrency control is another way to support concurrency. The idea is very simple – instead of using locks, each process/thread can access data freely. However, before committing changes, each transaction should check if the data has the same state as it did when you last read it. In other words, you check the data in the beginning of the transaction and check again before committing to see if they are still the same.
If the data hasn’t been modified, you can safely commit it. Otherwise, roll back and try again until there’s no conflict. It’s important to compare the two approaches here. For OCC (Optimistic concurrency control), apparently it’s more efficient to read/write data unless there are conflicts. With that in mind, for systems that are unlikely to have conflicts, OCC is a better option. However, when resources are frequently accessed by multiple clients, restarting transaction becomes costly in OCC and it’s better to place locks in each transaction (PCC).
In applications like Amazon, there are so many products that it’s not that frequent to have multiple people accessing the same product simultaneously. As a result, OCC is a better choice.
Availability in eCommerce
It’s a big loss if Amazon website is down for 1 minute. To achieve high availability in distributed systems, the best way is to have hundreds or thousands of replicas so that you can tolerate many failures. However, it’s worth to note here that availability and consistency go hand in hand.
If you have many replicas, it’s definitely harder to guarantee that each replica has the same data. On the flip side, if you want to achieve high consistency, you’d better have fewer replicas, thus the system is prone to failure.
The idea here is not trying to achieve both. Instead, based on the nature of the product, you should be able to make the trade-off. For an eCommerce website, latency and down time usually means losing revenue, which can be a big number sometimes. As a result, we might care more about availability than consistency. The latter can be improved through other approaches.
Strong consistency
One approach is to force all updates to happen in the same order atomically. More specifically, when someone is updating the resource, it’s locked across all servers until all of them share the same value (after the update). As a result, if an application is built upon a system with strong consistency, it’s exactly the same as working on a single machine. Apparently, this is the most costly approach as not only is placing locks expensive, but it also blocks the system for every update.
Weak consistency
Another extreme case is that we can provide minimum curation. Every replica will see every update, however, they may be in different orders. As a result, this approach makes the update operation extremely light-weighted, but the downside is providing a minimum guarantee of consistency.
Note: we are not explaining the accurate definition of consistency model. Instead, we’d like to illustrate ideas with examples, which are more helpful for preparing system design interviews.
Eventual consistency
As you can imagine, a more practical approach lies somewhere in between. In a nutshell, the system only guarantees that every replica will have the same value eventually. At a certain period of time, data might be inconsistent. But in the long term, the system will resolve the conflict.
Let’s take Amazon’s Dynamo as an example. Basically, it’s possible that each replica holds different versions of the data at a particular time. So when the client read the data, it may get multiple versions. At this point, the client (instead of the database) is responsible to resolve all the conflicts and update them back to the server.
You might wonder how does the client resolve those conflicts. It’s mostly a product decision. Take the shopping cart as an example, it’s very important to not lose any additions since losing additions means losing revenue. So when facing different values, the client can just choose the one with most items.
