存货核算
计算流程
从接入mq开始
1. 以实时计算流程开始
1.
2. 首先发送方会按照公司商品仓库进行hash后进行对队列数进行取余，此目的是为了将同一个商品分配到同一个队列中对后续的计算友善 -- 业务
3. 在队列数远超于节点数的情况下，每个节点，每次默认拉取20条数据可能来自于不同的队列，不同的商 --业务
4. 代码处理流程是每个mq消费节点都起了5个线程拉取数据，每次批量拉取10条，单次流程最多处理50条数据 --tps
5. 由于计算要顺序处理，线程池处理不同商品可能造成同一个商品的并发问题，创建本地队列对
1. 本地队列的作用
1. 将次批次数据根据商品hash分别投放到不同的队列
2. 保证同一时刻某一个商品只能有一个线程在执行，此处只能保证到此，因为计算需要严格的先后顺序而严格的先后顺序需要根据从数据库查询出来的数据为准
3. 首先生成执行器，将队列放入执行器，执行器用于放在线程池执行
4. 数据存入队列：push的时候不能进行快照的消费，禁止写入；获取快照的瞬间不能进行写入，也禁止写入
5. 本地队列进行push和await，push将数据推送到queue中，await使用线程池对所有执行器中对应自身的的queue进行执行
6. 后续统一抽象流程 -- 区分是只计算数量或者是计算成本或者是需要计算成本
7. 因为存在不同的周期，根据时间段区分，每个时间段落采用的模板(分仓计算/不分仓计算)可能不同
8. 后续采用模版方式根据，根据模板的不同使用不同的计算流程
1. 使用模板方式
1. 将业务调用，数据持久化，消息发送，异常处理抽象出来，由各个模板分别实现
9. 业务：判断是否出错，是否异常停止标志位，用于判断此消息是否需要继续执行
10. 业务：获取配置（计算方式，期初数量等）
11. 提问点：初始化漏桶
1. 限流的策略，相同的思想用在漏桶上，限流的集中方式
2. 业务：使用漏桶的原因，出现库存不足的时候进行超卖，此时超卖的商品价格会以当前的价格为主并不是真实的价格，后期出现采购入库新进的商品要和之前超卖的商品做价格低冲，重算新的商品价格，抵充的顺序要有严格的要求，按照先进先出，对最先进行超卖的销售订单进行抵充
12. 业务：以当前消息为截止，以offset记录为标志位开始节点，拉取中间所有的单据，按数量切分，逐条计算
13. 提问点（策略模式）：根据业务的不同（每日或是实时计算）以及（变化数量由变化之前的正变负数或者是由负数变为正数）注册策略模式，用不同的策略进行处理
14. 业务流程：计算流程分为：实时，重算，初始化，使用接口封装，每个策略实现接口并各自实现三种计算流程
1. 具体业务逻辑包含填充结余金额，结余数量，计算移动加权数据
2. 业务：加权成本的计算逻辑
3. 除以上区别具体实现看使用那种策略，比如实时计算时候不需要变更差异值记录，重算的时候则需要进行差异值记录的操作
15. 业务执行完成
16. 若业务处理未完成，出现异常，将会将缓存中已经处理过的数据进行持久化，并修改处理完成的标志位置
17. 将处理完的业务进行数据持久化，开启事务将内存中的数据存储完成
18. 发送消息推送计算完成的历史成本价
1. 因为是实时移动加权，尽量保证实时推送，但是由于某一时刻大量的移动加权变更，调用上游dubbo接口异常，为了肖峰将消息使用中间件进行投递
2. 根据中间件保证消息的先后顺序（mq的顺序消费）
2. 重算消息（初始化流程及成本补录流程类似）
1. //todo
同步数据流程
1. 同步补录单
2. 同样采用模板方式：
1. 循环批量查询数据，调用回掉
2. 进行数据填充；这里使用责任链模式对数据进行填充
1. 包含一些商品信息
2. 首先通过redis将商品信息存入缓存中
3. （**redis流程学习**）在责任链各个节点填充商品信心，获取不到从db总重新获取，更新存入redis缓存
3. 将数据入库
4. 发送数据通过mq方式，保证发送顺序
存在多数据源（同样可以作为技术方案）
1. 使用dynamic-datasource-spring-boot-starter 继承工具进行处理多数据源
2. 配置约定
3.
- 数据库导出冗余进去
- 分页工具
- mybatis优化多数据源的处理
- Log4j的MDC = threadlocal
- `111111