有需要的可以关注公众号（微信公众号、小红书同名）！后续会继续出更多内容！

1. "无忧闪赔"计划：构建高效的自动化赔付流程

1.1 项目背景与职责

项目背景：“无忧闪赔”计划是为电商平台的售后服务提供支持的自动化流程系统。在这个系统中，当客户投诉或出现异常时，需要进行赔付处理。为了提高效率，平台希望实现自动化的赔付流程，减少人工干预，缩短赔付处理时间。项目职责：负责自动化流水的开发与场景聚合根设计。

1.2 项目难点与解决方案

1.2.1 场景聚合根设计

“无忧闪赔”计划中的一个重要模块是异常处理机制。在异常赔付中，不同的业务场景会触发不同的异常处理规则。为了提高系统的灵活性和扩展性，需要设计场景聚合根。这个模块的核心是能够根据不同的异常场景，提报异常并进行相应的处理。难点：如何保证场景的扩展性

1. 公共属性与特殊方法：通过抽象场景的公共属性（如货物属性、异常状态等）和特殊方法（如异常处理逻辑），我们实现了对异常处理的灵活应对。不同场景下，异常的处理方法可能不同，而我们通过这种设计确保了后续新增业务场景时，可以轻松扩展。
2. 异常提报机制：通过对异常的提报机制进行设计，我们确保了无论是哪种类型的异常，都能及时、准确地提报至系统中，并触发后续的自动处理或人工干预。这个设计使得整个系统的异常处理更加高效、可靠。

1.2.2 自动化流水开发

自动化流水设计难度不大，你可以认为他是一个链表，访问链表的每一个节点的方式是递归。难点：流程抽象与状态流转解决方案：

1. 自动化流水设计：我们采用递归方法来实现状态流转，每个状态都按照预设的逻辑自动流转。通过这种自动化处理，我们将单个异常的赔付处理时间从一天缩短到1秒。
2. 扩展性设计：为了保证未来能够轻松添加新业务流程，我们参考了Spring的BeanPostProcessor设计，抽象出了一套可扩展的流程处理机制。每个状态流转阶段都采用了模板方法模式，这样新的异常流程可以直接继承并扩展已有的状态处理逻辑。
3. 状态流转失败的处理机制：在一些特殊情况下，状态流转失败无法继续进行。我们设计了一个定时机制，每隔一定时间检查状态是否成功流转，超过3次失败后，系统会自动将任务交由客服处理，确保了自动化流程的高效性。

2. "货链畅流"计划：提升物流数据处理的性能与稳定性

2.1 项目背景与职责

项目背景：“货链畅流”计划是平台的物流系统升级项目，目标是优化包裹处理和分拣系统。随着电商订单量激增，系统的处理性能和稳定性面临严峻挑战，尤其是在高并发和大数据量情况下，如何高效地进行包裹数据处理，成了关键问题。项目职责：使用线程池提高接口性能。

2.2 项目难点与解决方案

难点：线程池设计与死锁问题解决方案：

1. 线程池类型选择：考虑到分拣逻辑的高并发特性，我们使用了专用的线程池。CPU密集型任务（如包裹数据计算）使用了CPU线程池，而IO密集型任务（如从数据库读取数据）则使用了IO线程池。在设计线程池时，考虑到高并发和大数据处理的特点，我们设定了CPU线程池的核心线程数为核心数+2，最大线程数为2倍核心数，而IO线程池的核心线程数则依据阻塞系数进行调整，为核心数 / (1 - 阻塞系数)，最大线程数限制为250。
2. 死锁问题的解决：在高并发的场景下，原本设计的CPU线程池核心线程数为100，导致在高峰期出现了死锁问题。当2万单的包裹数据涌入时，线程池的核心线程被占满，而子线程池的线程又不足，导致了线程死锁。为此，我们将CPU线程池的核心线程数调整为150，并为子线程设置了独立的线程池，最终成功避免了死锁。
3. 数据库死锁问题：在处理包裹数据时，使用了selectForUpdate进行唯一标识查询，但由于默认的隔离级别（RR），间隙锁引发了死锁。为了避免这一问题，我们将数据库的隔离级别调整为RC，消除了间隙锁的影响，确保了系统的稳定性。