第一级别
- 使用HTTP协议，来进行交互，对失败的请求进行内存重试3次，3次后丢弃
第二级别
- 对失败的数据进行持久化重试，存放于数据库中，用定时任务来对失败的数据进行重新处理，重试3次以后丢弃，3次的间隔时间固定
第三级别
- 优化重试策略，考虑到如果重试时间间隔设置得太短，第三方宕机短时间内无法恢复，会跳过3次重试时间隔离。
- 如果重试次数太多，比如设置10次，1是耗资源（对方服务短时间内能恢复的就已经恢复了，恢复不了的，短时间内重试这么多次也没有意义），2是定时任务不能很快的处理到新产生的数据
- 如果重试时间间隔太长，第三方系统恢复后，又需要很长时间才能接收到。
- 折中的方案是优化策略为指数级别的重试方式，第1次失败1分钟，第2次失败2分钟后重试，第3次失败4分钟后重试，以此累加
第四级别
- 重试是由定时任务发起，为了不重复执行，所以执行线程只有1个，数据量过大，可能会显得力不从心
- 这时候可能考虑多开几个线程并行跑，来加快数据的传输
- 想要多开线程，就需要考虑线程之间的任务分配，可以通过取模，范围等方式来做任务分配，来达到加快同步效率的目的
第五级别
- 单机情况下的线程任务，存在线程中断，阻塞与单机瓶颈问题，
- 线程中断是指，程序业务逻辑出现未知异常导致线程中断，中断后该线程所负责的任务不能得到执行（比如该线程负责的1-100条之间的记录）
- 线程阻塞是指，HTTP网络阻塞（比如 restTemplate的超时时间会导致此问题），或者CPU未分配到执行此任务的片短，CPU在忙着搞其他具有更高优先级的事情，或者有其他线程一直占用着CPU使用权导致该任务线程一直挂起
- 单机瓶颈是指该服务一台机器处理能力有限 或者 由于异常问题导致宕机，假死，等不可控因素时任务得不到执行
- 考虑到以上问题，可能需求使用到分布式任务系统，当一个线程死掉后，有其他线程来完成他的工作，当一台机器死掉后，有其他机器来完成这台机器的工作
第六级别
- 与第三方同步发生异常时研发团队得不到通知，发生问题不能得到及时处理，等到用户发现，或者第三方研发发现，再返馈到我方，就太晚了，所以需要一套完整的业务监控系统，通过先于用户，先于第三方发现问题，并解决问题
第七级别
- 公司团队的业务很多，只要不是孤岛，很多业务都需要与第三方对接，每一次的对接成本都做到这种程度，是一件即废人力，又废物力，又浪费时间的做法
- 如果能将这一套流程平台化，抽象为一个与第三方对接的公共平台，那业务团队只需要做一件事，那就是将“需要同步的数据存在自己业务的数据库里"，后面的事情交给专门的系统来做专业的事情
- 来达到每一次对接都是最高级别的对接，每一次对接的成本都是最低
第八级别
- 既然做了平台化，那似乎还可以做更多的事情
- 任务可以实现动态分配，线程数，任务数，频次，重试策略，延迟投放，去重 等，来满足不停变化的需求与数据
- 每一条数据的来往，三方的处理结果都清晰的存在平台数据库中，能够实现后期排查定位和分析
- 第三方团队研发能力或需求理解能力不一，常常程序运行一段时间后，希望我们重新推送，以往是遇到这种情况，可能需求手动刷库，一是不安全，二是不方便。平台可以通过可视化操作，对指定数据来重放，实现重新推送
- 能够监控到每一个与第三方的同步情况，同步了多少数据，还剩多少，有多少成功的，有多少失败的，同步的性能怎么样，第三方的处理能力怎么样，等等执行情况
第九级别 - 待完善
欢迎补充