大概完成事项梳理（从10月10日~10月17日，共计7天，工时损耗51H）
一、获取SKU默认分类慢日志专项排查，发现是由于Redis调用频次过高，导致流量限制。跟系统部沟通解决方案（5H）
1、方案一，Redis直接升配置，从500M升级为1500M，费用从190元提升为1500元
2、方案二，Redis从单机升级为集群，带宽直接升级为2300M，费用从190元提升为260元，但是公司目前没有项目用过集群，存在一定风险。
二、其他慢日志排查（10H）
1、通过高频调用的维度、耗时最长的维度，拉取所有日志，排查日志所在代码功能，分析最损耗时间的4个模块。
1-1、资料组装,生成描述,合并过滤,重试次数:1,耗时:122（敏感词相关，组装标题亮点）
1-2、多套资料组装耗时,组装标题关键词亮点描述,耗时32（敏感词相关，循环所有SKU）
1-3、英语站重新组装多套资料,耗时60（组装资料并过滤敏感词 需求33868，细节流程多，得逐步调试分析）
1-4、多套资料耗时,获取查重资料(V1上架，表格刊登上架，新队列上架)（耗时20秒，根据站点、sku获取历史上架标题、关键词、亮点、描述）（连续调试无法复现，5秒以上的都是10个SKU一起查的）
三、通过对代码的分析，基本锁定敏感词优化方向，思考方案（5H）
优先针对敏感词进行优化，从对上面日志的分析，基本上目前最重要的卡点是敏感词查询效率，如果能解决这个问题，可以有较大的提升。
1、敏感词接口，本身性能需要优化（目前手动测试，5次请求，2次300毫秒，2次1~2秒，1次4秒），少军是否有方案。
2、调用敏感词的地方要优化。可参考人工刊登的思路，把原来 标题、5亮点、描述、关键词8个分开请求的，合并成一次请求，按原来平均一次2秒来算，2*8=16秒一个周期，合并后即便是按4秒来算，都提升了四分之三
四、对代码环境不了解，对代码全局研究熟悉，时间损耗（8H）
五、具体代码编写，共调整三个模块，及以下工作（21H）
1、AutoPublishService.OrderSourceAmazonAutoPublish
2、AmazonAutoPublishTranslateService.GetTranslateResultAsync
3、AutoPublishExtendService.GetMultiDatasNewAsync
4、通过代码评审会评审，把合并敏感词过滤功能，改造为公共方法：FilterSensitiveWordsHelper.ProcessFilteringWords
5、针对每一个场景在堡垒机进行调试。
六、针对Redis集群进行测试，单线程测试通过（2H）
