浅谈电商系统中的一些骚点问题

之前就有网友给我说，电商系统其实并没有那么难，控制好库存就可以了。说到好像很有道理，但实际上他一定是没有细致且认真的思考过整个电商系统中存在哪些骚点问题。今天我就给大家扯一扯吧。

首先，我们来思考一个问题，电商系统中为什么要搞一个订单号？这个原因其实我前面也讨论过，具体可以在我的这篇文章《5 大分布式 ID 生成器优缺点简单对比》中查看。

除此之外，订单号还有一个好处就是方便搜索。如果不用订单号，你该不会用主键自增 ID 去查一个订单吧。你看光一个订单号就有这么多的讲究，现在你还会说电商很简单吗？

有时候，我们在刷微博的时候，当一个热点微博被打脸后，原博主会立马把它删掉。但这时，你在通过微博的搜索功能去搜索这条微博，有可能还能搜索到。这可能就是，微博从 db 删除后，缓存系统中也被删除，但是搜索系统中可能还存在索引和快照没有被删除，所以你通过搜索有时候还能搜索到。

延伸到电商系统中，当一个商品被下架后，你需要里面从 Redis 等缓存系统中删除，另外搜索系统中也需要把它删除掉。当一个商品被上架后，搜索中也要里面能搜索到。要不然用户体检就非常差，就会有人投诉你。如果是个热卖商品，还必须减少 DB 的压力。把它移到缓存中。

除了，上下架操作，常见的还有库存问题。当我一个商品库存卖完了，你在通过搜索搜到我的权重就要降低。比如，现在有多个商家都在卖小目标啤酒。其中我自己开的店铺卖的小目标啤酒的性价比，信用，评价等方面完胜其他商家。通过搜索我能自然的显示在搜索结果中的第一个。当我库存卖完后，搜索引擎能够自动的把我降权，因为没有人希望搜索出来的商品中，显示的都是没有库存的吧。

除此之外，还有一些分布式事务，服务降级熔断，自动化运维，监控等一个都不能少。可以说电商系统是一个非常浩大的工程。在小公司，你可以马上上线一个新功能。但是在我们的电商系统中，一个小小的需求，可能就要搞一个月，甚至更久。一个小功能能产生非常大的联动，影响非常多的系统。这就是目前我们团队面临的问题和困境，好的架构并不是天生的，而是爬了无数坑之后慢慢优化出来的！

电商系统中，没有一行代码是容易的！

： » 浅谈电商系统中的一些骚点问题