# distributed-order

**Repository Path**: tianai/distributed-order

## Basic Information

- **Project Name**: distributed-order
- **Description**: 致力打造一个高并发的、通用的订单管理项目
- **Primary Language**: Java
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 4
- **Forks**: 4
- **Created**: 2019-11-06
- **Last Updated**: 2023-03-21

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 这是一个基于多库的订单分布式的扩展性比较强的订单项目
## 1. mysql分库分表介绍
    订单分库伪8个库，每个库8张表，一共是分了64张表.
    每个库用主表8张和从表8张，
    
    商家库也是一样
    一共有16个库
## 2. 基于事件驱动的编写模式
    
       在一些比较敏感的地方都发送了对应的事件，大大提高了扩展性和维护性(想要对某些地方增强，只需要写对应的事件监听器即可)
## 3. 使用了RocketMQ 和 canal 来对用户库的集群和店铺库的集群进行实时同步

## 4. 使用了拦截器，方便来拦截一些恶意的订单，集成非常方便

## 5. 一些其它想说的事情

### 5.1. 订单号的生成规则
    1位版本ID + 19位雪花算法 +２位用户ID + 2位商家ID + 1位自增ID
    
    纯数字，速度快，可排序，就是有点长233(等以后想到更好的方案的话再替代)
### 5.2. 对于分库后事物的处理， 
    业务逻辑下单的时候，每个订单都会规定索引到一个库中，不会出现多库同时操作的现象，来避免分布式事物的问题
### 5.3. 对于分库分表的逻辑处理
    1. 通过用户维度分了八个库，每个库八张表。 这样分库后写的压力就会减少，理论上支持的并发写可以达到10w(看某架构文章说的233)   
    2. 通过用户维度分表后，店铺查询订单就比较麻烦了，借鉴某宝的方案，把数据沉冗一份，然后按照店铺的维度去分表，这样店铺查询订单就很方便了
        这里把店铺也分了8个库，每个库八章表
    3. 用户库集群和店铺库集群数据实时同步通过监听mysql的binaryLog日志发送消息到消息队列来实时同步数据
        (监听binLog的日志工具为阿里开源的canal -- 然后稍加改造，通过订单号实现分区顺序)
### 5.4. 对于分页查询有几点想说
    分页查询的话对于传统的mysql来说，越差到后面越慢，特别是单表数据量大的时候，体现的更加明显
    这里借鉴了elasticsearch是scroll查询方式，稍加改造，完美解决了这个问题，
    前端的话可以写成类似于百度的那种分页方式(可以体验一下百度的分页^_^) 
### 5.5. 对于订单迁移
    某宝的做法是只保留三个月内的订单，三个月后的订单迁移到别的地方去，这样保证了单表的订单量始终在一个点上， 后期加上去

# 当然这个项目只实现了初步的功能，不过比较核心的地方已经大部分都实现了，接下来就是写一些通用的逻辑，方便第三方集成
#  非常欢迎一些志同道合的朋友一起参与进来,(我好难啊...) 

# 2019年11月8日14:13:05 --> 将订单改造为多服务模式， 原先单一架构打到 beta1分支中， 需要单一架构的在这个分支看

# 说下为什么把单一架构改造为分布式， 
    单一架构一定程度上效率是必分布式架构快(相对于) ， 但是考虑到后面要做 订单同步、订单导出、订单分布式调度等等服务
    那么都写到一个项目中，这对于扩展无疑是非常难受的。由于现在改造微服务基本上都是可插拔式， 改造起来比较简单， 
    项目中真正部署使用相对简单， 
## 分布式架构技术选型
    1. 分布式架构对于现在来说还是springCloud比较火相对于java语言
        由于springCloud原生的一些组件，特别是netflux已经闭源，最终选型AlibbaSpringCloud
    2. 为什么用dubbo而不用feign
        我个人考虑如下，
            feign 跨平台性比较好， 因为它是基于resulful的http形式， 
            dubbo 基于netty的tcp方式远程调用， 使用相比json更快的序列化方式， 缺点是跨平台性差。使用相比feign组件更加简单
            
         那么、两者优缺点各有千秋， 考虑到这个项目基本上就是java定性，其它组件很少用其它语言编写（就算有，也可以单独写http接口来调用），
         且dubbo框架国人是使用的最多的，它的性能和稳定性也是毋庸置疑的。 
         并且对于订单相关项目追求速度， 那么dubbo 的 速度确实是必feign快的。
         
         考虑到简单、方便、效率， 最终选择了dubbo
    3. 目前只是使用微服务框架实现了远程rpc调用，其它组件等待后期需要再做处理

# 未来几天要做的事
    1. 完善相关业务逻辑， 完善后最好做一个ui界面做展示
    2. 构建分布式调度系统来实时迁移 “三个月” 后的订单到只读库中，减少主库压力，
       由于项目中有货到付款模式，防止恶意下单， 实时迁移“异常订单”到垃圾回收站中
    3. 构建高效的订单导出系统， 导出千万级订单量供用户下载浏览
    
                 
    
         


qq: 1282012654