订单模块
作为电商系统，首入眼帘的就是订单模块，也是电商基础的模块之一。订单流程包含了订单从下单到完成的整个流程，订单的状态如下:
-
这里迎来了第一个问题，可以看到订单状态有非常多种，如果用if else去做判断，逻辑会非常多，这时候就需要用到状态机模式了，状态机如何使用我这里不细讲，可以自行去百度。
-
作为订单系统，订单的幂等性当然也非常重要，那么怎么做到订单的幂等性呢？
- 首先，前端向后端会申请一个订单号
- 后端同时把订单号放入redis缓存
- 用户提交订单，这里前端先把提交按钮置灰，减少一些不必要的麻烦。后端接收到请求，先去redis查询订单号是否存在，如果存在，说明是首次下单，那么删除redis中的订单号，继续往下走下单流程，如果不存在，说明是重复下单，可以友好提示用户
- 订单号的生成规则是怎么样的呢？
订单号当然也是越短越好，我们可以用下单渠道+业务类型+时间信息+用户ID的组合来设计，当然如果想加密一下也是可以的。
支付模块
作为电商系统的重要模块之一，支付的设计也尤为重要，但是目前我们的支付大多数都是去对接支付宝，微信和银联，所以不需要考虑他们的安全性问题，我们只要做好我们的支付系统即可。
这里也会涉及到支付幂等性的问题
- 一种方式是采用上面解决订单幂等性的方式
- 还有一种方式是在数据库里加唯一索引，用户ID+订单号+支付状态建立唯一索引，保证当前用户一个订单只能支付一次
商品模块
商品模块无非就是查询，所以我们的目的就是要提供快速的低延迟查询。这里用到的技术可以很多，利用缓存，ES，请求合并等技术，后续如果还不够，做集群扩容，你能想到的增加TPS的手段都可以用上，但是技术是一步步迭代的，我不建议一开始就过多的设计，还是要以当前用户量来考虑和设计。
可优化点
在进行关键业务处理的时候（比如订单数据，交易金额），保证select数据是当前最新数据，且你执行完，再执行其他update类型sql，可以在select for update语句(但是不要滥用，只对单条数据使用，且需要有索引，不然行锁会变表锁)。这样做的好处是，让公共表的多方修改事务排队，一个事务查询执行完了，再执行下一个事务的查询更新;
写在最后
我这里写的不是很全，肯定无法包含电商所有的技术点，后续我想到一点会补一点。类似于秒杀活动这些我后期会专门出一期来讲解。
