实现一个标准电商平台的一个下单功能
- 完整实现一个下单功能，包含以下功能：查询SKU价格(模拟，不需要实现)，扣减库存(只在缓存实现)，支付(模拟,不需要实现,但要处理结果回调), 生成订单
- 围绕下单功能，设计订单相关业务库表结构，并生成mybatis代码, 库存、商品等无需建表。
基础设施层限制使用mybatis\spring data redis实现（不考虑事务及分布式事务）。
请勾选
- 初级
- 中级
- 高级
- 【10分】基于基础代码实现，要求理解DDD**, 按示例要求(注意看代码注释和TODO)分层实现下单业务。
领域服务已定义, 不允许新增领域层接口, 请注意看代码注释, 并在APP层进行调用。 - 【20分】支付回调只处理支付成功场景。
- 【30分】resources/sql中给出订单表建表语句。 (库存、商品等无需建表)。
- 【40分】库存扣减只在缓存实现。
- 【10分】基于基础代码实现，要求理解DDD**, 按示例要求(注意看代码注释和TODO)分层实现下单业务。
领域服务已定义, 不允许新增领域层接口, 请注意看代码注释, 并在APP层进行调用。 - 【20分】支付回调使用策略模式(支付成功、支付失败、重复支付), 实现越优雅越好。
- 【30分】resources/sql中给出订单相关表mysql建表语句。 (库存、商品等无需建表)
背景: 近期订单量级2000W, 不考虑增长。
主查询场景如下:
1. 买家频繁查询我的订单,实时性要求高。
2. 卖家频繁查询我的订单,允许秒级延迟。
使用mysql分库分表技术, 建表语句文件内使用注释方式描述设计方案。
如：表、索引、分库键、分表键的设计思路及具体结论、同时满足买卖双方查询需求方案等。 - 【40分】库存扣减只在缓存实现, 需要考虑并发，避免超卖。
- 【10分】基于基础代码实现，要求理解DDD**, 按示例要求(注意看代码注释和TODO)分层实现下单业务。
领域服务已定义, 不允许新增领域层接口, 请注意看代码注释, 并在APP层进行调用。
领域层需要体现充血模型的实现, 在任意业务上体现即可。 - 【20分】支付回调需要优雅的使用策略模式(支付成功、支付失败、重复支付)。
- 【30分】围绕订单，给出相关存储设计。 (库存、商品等无需考虑)
背景: 存量订单10亿, 日订单增长百万量级。
主查询场景如下: \- 买家频繁查询我的订单, 高峰期并发100左右。实时性要求高。 \
- 卖家频繁查询我的订单, 高峰期并发30左右。允许秒级延迟。 \
- 平台客服频繁搜索客诉订单(半年之内订单, 订单尾号，买家姓名搜索)，高峰期并发10左右。允许分钟级延迟。 \
- 平台运营进行订单数据分析，如买家订单排行榜, 卖家订单排行榜。
resources/sql中给出整体设计方案。包含存储基础设施选型, DDL（基础字段即可）, 满足上述场景设计思路。
方案可描述大体方向，面试时可补充交流。
- 【40分】库存扣减只在缓存实现, 假设业务为秒杀场景，需要考虑高并发(100每秒)，避免超卖。要求无锁设计。
- 订单量达到10亿级别建议用 es+hbase，利用es的索引能力和hbase的海量存储快速取出能力。
- 如果非要只用mysql实现建议使用分库分表，并且做读写分离，根据业务情况，尽量保证每表的数据量在2000万级别，以取得较好的性能。
- 可以考虑以下分库分表方案，用户订单库，商家订单库，投诉订单库，数据分析库
- 下单时按用户hash分表，保证同用户的订单在同一个表内，同时防止热点瓶颈的出现。
- 下单同时发起消息，写入商家订单库，商家订单按商家hash，保证同商家订单在同一个表内。
- 投诉率按20%考虑，日增长投诉20万，可以按冷热数据分表，半年以内存入一个表，半年以外按周期分表。订单尾号，买家姓名单独保存，以利用索引，避免模糊查询。
- 平台数据分析使用定时任务统计结果存入单独表，比如下单时统计用户订单数订单金额，商家订单数订单金额，这样分析做排行时只是简单的sql查询。