4 稳定性（安全生产）
涉及第三方交互，谁都无法确定对方如何调用己方系统。稳定性的重要性不言而喻。
4.1 流量控制
在数据同步时，将请求打入队列对于第三方的同步请求使用异步返回。打入队列的好处就是可以利用队列实现流量控制，削峰填谷。限流这部分依赖于阿里开源的Sentinel框架，网上对于Sentinel的分析很多这里不多加赘述。
数据一致性保证
由于存在重试操作，所以必然需要在重试过程中保证数据的正确性。
- 状态变更日志表：数据库采用的是nosql的数据库，这边会根据参数生成唯一id，进行覆盖插入保证数据的唯一性。
- 业务商品表：采用先查后插的方式，同时利用分布式锁+itemId唯一键冲突保证数据的唯一性。
拿兼职插入一致性举个栗子：ic表：底层商品表，包括一些商品的基本信息。岗位表：扩展信息的存储，工作地点、工作时间等。当一条兼职同步消息来了之后这边会涉及到两张表的维护。这里采用的方式是以下架的方式插入ic表，如果业务表成功后去更新上架ic表中状态（如下图）。
异常监控告警
攻击流量通常会伪装成正常流量进入。在这种情况下，系统会一直无法消费此异常消息，所以这边设置一个消费重试阈值，如果达到上限后对消息进行丢弃，同时进行系统告警（有的场景是需要强一致性保障，此时报警后需人工接入排查）。
兼职业务的告警场景包括：
- 限流触发报警（持续时间超过10分钟）：限流期间被限制的消息业务会主动进行重试，控制重试n次整体持续时间不会超过10分钟，如果限流超过10分钟认定为异常情况会进行告警。（通常来说是供应商大批量上下架岗位导致，未通知前提下认定为他们系统问题）
- 状态更新失败（持续时间超过5分钟，每分钟数量大于n）：小批量的更新失败可以理解为是垃圾数据，持续时间过于长可以理解为供应商系统异常。
5 总结
本章节主要介绍了闲鱼同城业务在“闲置时间”和"闲置空间“场景下针对与第三方系统对接的过程中开发资源和稳定性问题展开。通过上述方案也解决了在开篇提到的2个问题：
- 动态响应机制：商品同步时通过实时回调和异步回调的方式将商品的每个异常状态返回给供应商；提供了小时时间维度的统计播报，最后以钉钉消息通知至钉钉群中，如若发现异常也可根据开放接口去查询商品历史变更状态。这样就能很大程度上解放开发，不会因为对账的问题被频繁的打断。
- 稳定性治理：通过接口限流保证异常流量打满线程池进而影响系统；通过接口幂等保证数据的安全唯一性；通过监控（搭配合适的报警规则）去监控异常场景，如若出现问题人为介入。
随着业务越来越复杂，对应的独立业务域也将会越来越多，在独立业务域上的开发精力也会越来越多。能否根据大量复杂业务场景的输入找到共同点抽象出较为理想的架构将是努力的目标。
- 抽象出独立业务域中的共同点，推动业务完善路径：完善租房的订单和履约路径，统一抽取出订单域和履约域。
- 针对不同业务的不同商家统一商家管理平台，现阶段每个业务都有自己的一套接入方式。
