001- TMS：ERP的订单日志并发优化
001+ TMS：ERP的订单日志并发优化；称重是否启用体积重以及相关逻辑改动的优化

001- TMS：ERP的订单日志并发优化
001+ TMS：ERP的订单日志并发优化；称重是否启用体积重以及相关逻辑改动的优化

001- 背景：订单日志并发量大，日志数据增量很大，影响系统性能
001+ 一、ERP的订单日志并发优化
002-
002+ 背景：
003- 方案：用kafka发送消息，创建一个分区即可，发送消息和处理消费分开处理
003+ 订单日志并发量大，日志数据增量很大，影响系统性能
005- 具体方案：1、通过发KAFKA异步解耦（原先写sqlserver这里调整为发kafka消息）2、由于顺序要求，当前TOPIC仅设置一个partition（分区）3、如果ERP不支持kafka的SDK，则提供一个JAVA接口做为中转（java接口仅在open服务中直接发kafka消息则可，无其他业务）4、（选择1：推荐）可直接通过seatunnel CDC 直接把kafka消息写入ES或sqlserver（写频率不要过快，如1000条一批，10秒一次等）；（选择2）或在java的zhcxkj-bus-common服务中监听kafka消息，如：10分钟一次写一个csv文件，再发一个rabbitmq文件导入消息，把csv文件导入ES或sqlserver中（rabbitmq是为了保证文件一定导入成功，失败则重新进入队列）
005+ 方案：用kafka发送消息，创建一个分区即可，发送消息和处理消费分开处理
007- 涉及改造功能（第一批切换功能）：1、手工录入追踪号2、限重服务3、erp称重4、Java计算运费和税费
007+ 具体方案：1、通过发KAFKA异步解耦（原先写sqlserver这里调整为发kafka消息）2、由于顺序要求，当前TOPIC仅设置一个partition（分区）3、如果ERP不支持kafka的SDK，则提供一个JAVA接口做为中转（java接口仅在open服务中直接发kafka消息则可，无其他业务）4、（选择1：推荐）可直接通过seatunnel CDC 直接把kafka消息写入ES或sqlserver（写频率不要过快，如1000条一批，10秒一次等）；（选择2）或在java的zhcxkj-bus-common服务中监听kafka消息，如：10分钟一次写一个csv文件，再发一个rabbitmq文件导入消息，把csv文件导入ES或sqlserver中（rabbitmq是为了保证文件一定导入成功，失败则重新进入队列）
008+
009+ 涉及改造功能（第一批切换功能）：1、手工录入追踪号2、限重服务3、erp称重
010+ 4、Java计算运费和税费
011+
012+ 二、称重是否启用体积重以及相关逻辑改动的优化
013+ 问题： ERP称重从java获取运费规则数据判断是否使用体积重的逻辑有缺陷，目前只要是计费重取值类型是“按条件取值”或运费类型是海运体积就默认是启用体积重，但是按条件取值也有可能是用自定义公式取值
014+
015+ 方案： 1、直发：按条件取值，取值类型：体积重 2、备货：区间价格+按条件取值 3、备货：海运体积以上三种类型就是使用体积重的方案，备货+海运体积直接设置为使用体积重的原因是，物流java系统针对海运体积默认就是使用体积重，erp如果配置的是海运体积的话都开启了使用体积重
016+
017+ 影响功能： ERP称重（PC端，包裹列表界面，包裹称重界面）

001- <span>背景：<br /></span><span>订单日志并发量大，日志数据增量很大，影响系统性能</span>
001+ <p><span>一、ERP的订单日志并发优化</span></p>
002- <p><br /></p>
002+ <p><span>背景：</span></p>
003- <span>方案：<br /></span><span>用kafka发送消息，创建一个分区即可，发送消息和处理消费分开处理</span>
003+ <span>订单日志并发量大，日志数据增量很大，影响系统性能</span>
005- <span>具体方案：<br /></span><span>1、通过发KAFKA异步解耦（原先写sqlserver这里调整为发kafka消息）<br /></span><span>2、由于顺序要求，当前TOPIC仅设置一个partition（分区）<br /></span><span>3、如果ERP不支持kafka的SDK，则提供一个JAVA接口做为中转（java接口仅在open服务中直接发kafka消息则可，无其他业务）<br /></span><span>4、（选择1：推荐）可直接通过seatunnel CDC 直接把kafka消息写入ES或sqlserver（写频率不要过快，如1000条一批，10秒一次等）；（选择2）或在java的zhcxkj-bus-common服务中监听kafka消息，如：10分钟一次写一个csv文件，再发一个rabbitmq文件导入消息，把csv文件导入ES或sqlserver中（rabbitmq是为了保证文件一定导入成功，失败则重新进入队列）</span>
005+ <span>方案：<br /></span><span>用kafka发送消息，创建一个分区即可，发送消息和处理消费分开处理</span>
007- <span>涉及改造功能（第一批切换功能）：<br /></span><span>1、手工录入追踪号<br /></span><span>2、限重服务<br /></span><span>3、erp称重<br /></span><span>4、Java计算运费和税费</span>
007+ <span>具体方案：<br /></span><span>1、通过发KAFKA异步解耦（原先写sqlserver这里调整为发kafka消息）<br /></span><span>2、由于顺序要求，当前TOPIC仅设置一个partition（分区）<br /></span><span>3、如果ERP不支持kafka的SDK，则提供一个JAVA接口做为中转（java接口仅在open服务中直接发kafka消息则可，无其他业务）<br /></span><span>4、（选择1：推荐）可直接通过seatunnel CDC 直接把kafka消息写入ES或sqlserver（写频率不要过快，如1000条一批，10秒一次等）；（选择2）或在java的zhcxkj-bus-common服务中监听kafka消息，如：10分钟一次写一个csv文件，再发一个rabbitmq文件导入消息，把csv文件导入ES或sqlserver中（rabbitmq是为了保证文件一定导入成功，失败则重新进入队列）</span>
008+ <p><br /></p>
009+ <span>涉及改造功能（第一批切换功能）：<br /></span><span>1、手工录入追踪号<br /></span><span>2、限重服务<br /></span><span>3、erp称重<br /></span>
010+ <p><span>4、Java计算运费和税费</span></p>
011+ <p><span><br /></span></p>
012+ <p><span>二、<span>称重是否启用体积重以及相关逻辑改动的优化</span></span></p>
013+ <p><span><span>问题：<br /></span><span> ERP称重从java获取运费规则数据判断是否使用体积重的逻辑有缺陷，目前只要是计费重取值类型是“按条件取值”或运费类型是海运体积就默认是启用体积重，但是按条件取值也有可能是用自定义公式取值</span>
014+ </span></p><p><br /></p>
015+ <span>方案：<br /></span><span> 1、直发：按条件取值，取值类型：体积重<br /></span><span> 2、备货：区间价格+按条件取值<br /></span><span> 3、备货：海运体积<br /></span><span>以上三种类型就是使用体积重的方案，备货+海运体积直接设置为使用体积重的原因是，物流java系统针对海运体积默认就是使用体积重，erp如果配置的是海运体积的话都开启了使用体积重</span>
016+ <p><br /></p>
017+ <span>影响功能：<br /></span><span> ERP称重（PC端，包裹列表界面，包裹称重界面）</span><br />

001- TMS：ERP的订单日志并发优化；称重是否启用体积重以及相关逻辑改动的优化
001+ TMS：ERP的订单日志并发优化；称重是否启用体积重以及相关逻辑改动的优化；客户订单预报报错重复下单优化

001- TMS：ERP的订单日志并发优化；称重是否启用体积重以及相关逻辑改动的优化
001+ TMS：ERP的订单日志并发优化；称重是否启用体积重以及相关逻辑改动的优化；客户订单预报报错重复下单优化

009- 涉及改造功能（第一批切换功能）：1、手工录入追踪号2、限重服务3、erp称重
009+ 涉及改造功能（第一批切换功能）：1、手工录入追踪号2、限重服务3、erp称重
013- 问题： ERP称重从java获取运费规则数据判断是否使用体积重的逻辑有缺陷，目前只要是计费重取值类型是“按条件取值”或运费类型是海运体积就默认是启用体积重，但是按条件取值也有可能是用自定义公式取值
013+ 问题： ERP称重从java获取运费规则数据判断是否使用体积重的逻辑有缺陷，目前只要是计费重取值类型是“按条件取值”或运费类型是海运体积就默认是启用体积重，但是按条件取值也有可能是用自定义公式取值
014-
014+
015- 方案： 1、直发：按条件取值，取值类型：体积重 2、备货：区间价格+按条件取值 3、备货：海运体积以上三种类型就是使用体积重的方案，备货+海运体积直接设置为使用体积重的原因是，物流java系统针对海运体积默认就是使用体积重，erp如果配置的是海运体积的话都开启了使用体积重
015+ 方案： 1、直发：按条件取值，取值类型：体积重 2、备货：区间价格+按条件取值 3、备货：海运体积以上三种类型就是使用体积重的方案，备货+海运体积直接设置为使用体积重的原因是，物流java系统针对海运体积默认就是使用体积重，erp如果配置的是海运体积的话都开启了使用体积重
017- 影响功能： ERP称重（PC端，包裹列表界面，包裹称重界面）
017+ 影响功能：
018+ ERP称重（PC端，包裹列表界面，包裹称重界面）
019+
020+ 三、客户订单预报报错重复下单的场景优化
021+ 背景：
022+ 近期比较多订单提示重复下单，导致获取追踪号失败。
023+
024+ 分析：JAVA物流子系统调用物流商平台的预报接口成功后，但是系统数据库超时导致保存追踪号失败了，再次预报就会提示重复下单。
025+
026+ 方案：
027+ 如果接口提示重复下单，则自动重新生成一个新的自定义单号，重新调用一次物流商的预报接口。
028+ 每个物流商接口预报重复下单的场景，接口给出的错误提示都不一样，有的提示自定义单号重复，有的提示已存在，有的还会提示一个因为单词。所以加个配置表，针对每个物流，配置类似重复下单失败的关键词，一个物流支持配置多个关键词。
029+ 匹配配置表的关键词成功后，自动生成新的自定义单号重新预报一次。
030+
031+
032+

009- <span>涉及改造功能（第一批切换功能）：<br /></span><span>1、手工录入追踪号<br /></span><span>2、限重服务<br /></span><span>3、erp称重<br /></span>
009+ <span>涉及改造功能（第一批切换功能）：<br /></span><span>1、手工录入追踪号<br /></span><span>2、限重服务<br /></span><span>3、erp称重<br /></span>
013- <p><span><span>问题：<br /></span><span> ERP称重从java获取运费规则数据判断是否使用体积重的逻辑有缺陷，目前只要是计费重取值类型是“按条件取值”或运费类型是海运体积就默认是启用体积重，但是按条件取值也有可能是用自定义公式取值</span>
013+ <p><span><span>问题：<br /></span><span> ERP称重从java获取运费规则数据判断是否使用体积重的逻辑有缺陷，目前只要是计费重取值类型是“按条件取值”或运费类型是海运体积就默认是启用体积重，但是按条件取值也有可能是用自定义公式取值</span> </span></p>
014- </span></p><p><br /></p>
014+ <p><br /></p>
015- <span>方案：<br /></span><span> 1、直发：按条件取值，取值类型：体积重<br /></span><span> 2、备货：区间价格+按条件取值<br /></span><span> 3、备货：海运体积<br /></span><span>以上三种类型就是使用体积重的方案，备货+海运体积直接设置为使用体积重的原因是，物流java系统针对海运体积默认就是使用体积重，erp如果配置的是海运体积的话都开启了使用体积重</span>
015+ <span>方案：<br /></span><span> 1、直发：按条件取值，取值类型：体积重<br /></span><span> 2、备货：区间价格+按条件取值<br /></span><span> 3、备货：海运体积<br /></span><span>以上三种类型就是使用体积重的方案，备货+海运体积直接设置为使用体积重的原因是，物流java系统针对海运体积默认就是使用体积重，erp如果配置的是海运体积的话都开启了使用体积重</span>
017- <span>影响功能：<br /></span><span> ERP称重（PC端，包裹列表界面，包裹称重界面）</span><br />
017+ <span>影响功能：<br /></span>
018+ <p><span> ERP称重（PC端，包裹列表界面，包裹称重界面）</span></p>
019+ <p><span><br /></span></p>
020+ <p><span>三、客户订单预报报错重复下单的场景优化</span></p>
021+ <p><span><span>背景：</span></span></p>
022+ <p>近期比较多订单提示重复下单，导致获取追踪号失败。</p>
023+ <p><br /></p>
024+ <span>分析：<br /></span><span>JAVA物流子系统调用物流商平台的预报接口成功后，但是系统数据库超时导致保存追踪号失败了，再次预报就会提示重复下单。</span>
025+ <p><br /></p>
026+ <span>方案：</span>
027+ <ol><li><span>如果接口提示重复下单，则自动重新生成一个新的自定义单号，重新调用一次物流商的预报接口。</span></li>
028+ <li><span>每个物流商接口预报重复下单的场景，接口给出的错误提示都不一样，有的提示自定义单号重复，有的提示已存在，有的还会提示一个因为单词。所以加个配置表，针对每个物流，配置类似重复下单失败的关键词，一个物流支持配置多个关键词。</span></li>
029+ <li><span>匹配配置表的关键词成功后，自动生成新的自定义单号重新预报一次。</span>
030+ <p><br /></p>
031+ </li>
032+ </ol><p><br /></p>

017- 影响功能：
017+ 影响功能：
024- 分析：JAVA物流子系统调用物流商平台的预报接口成功后，但是系统数据库超时导致保存追踪号失败了，再次预报就会提示重复下单。
024+ 分析：JAVA物流子系统调用物流商平台的预报接口成功后，但是系统数据库超时导致保存追踪号失败了，再次预报就会提示重复下单。
026- 方案：
026+ 方案：
029- 匹配配置表的关键词成功后，自动生成新的自定义单号重新预报一次。
029+ 匹配配置表的关键词成功后，自动生成新的自定义单号重新预报一次。
030-
030+
031-
031+ 四、订单日志页面对接测试环境的ES订单日接口（含客户订单和备库订单）
032-
032+ 五、seatunnel CDC配置
033+
034+
035+
036+
037+
038+

017- <span>影响功能：<br /></span>
017+ <span>影响功能：<br /></span>
024- <span>分析：<br /></span><span>JAVA物流子系统调用物流商平台的预报接口成功后，但是系统数据库超时导致保存追踪号失败了，再次预报就会提示重复下单。</span>
024+ <span>分析：<br /></span><span>JAVA物流子系统调用物流商平台的预报接口成功后，但是系统数据库超时导致保存追踪号失败了，再次预报就会提示重复下单。</span>
026- <span>方案：</span>
026+ <span>方案：</span>
029- <li><span>匹配配置表的关键词成功后，自动生成新的自定义单号重新预报一次。</span>
029+ <li><span>匹配配置表的关键词成功后，自动生成新的自定义单号重新预报一次。</span></li>
030- <p><br /></p>
030+ </ol><p><br /></p>
031- </li>
031+ <p>四、订单日志页面对接测试环境的ES订单日接口（含客户订单和备库订单）</p>
032- </ol><p><br /></p>
032+ <p>五、seatunnel CDC配置</p>
033+ <p>
034+ </p><p><br /></p>
035+
036+ <p><br /></p>
037+ <p><br /></p>
038+ <p><br /></p>