过往项目经验整理（搜索&存储）

过往项目经验整理（搜索&存储）

1，防书籍重复入库，反作品抄袭；

   A，SimHash特征，计算海明距离，相对于标准向量计算余弦距离计算量小；

   B，基于Elastic Search的书库存量章节关键段落检索；

   C，基于Faiss的竞品章节向量检索；

   D，基于IP代理后的爬虫对百度搜索结果进行检索，并计算相似度；

2，资金结算平台沙箱环境，变更可回溯性追踪；

   背景：出现过这样的Case：在生产环境进行试算，并将试算数据发布出去；

   A，隔离环境细节。沙箱环境ECS服务器，ECS配置对DB的隔离访问策略，服务Init感知环境并判断链接正确性；

   B，数据同步？从线上全库同步数据；

   C，验证过程？沙箱环境部署代码，跑结算任务，并根据结果进行判定；

3，章节阅读故障问题闭环自动修复；

   背景：章节上架链路冗长，链路中数据冗余，领域模型定义不清晰，状态含义不明确，服务调用没考虑最终一致性，流程在链路中某些节点中断的情况；

   A，端上对章节阅读故障上报事情，Kafka原始日志—>Flink日志清洗—>Kafka阅读故障，监听消息并触发章节重新上架流程；客诉量下降95%+；

   B，服务领域拆分，领域模型重新定义，状态码含义定义，明确服务约定，服务调用重试机制；从长条形链路重构成中心化服务，消除数据冗余，减少数据同步；从面向业务过程升级到面向领域服务；

4，版权方合作对接外部API可配置化；

   背景：对接100+书籍供应版权方，需要调用对方提供的OpenAPI接口，拉取书籍入库。接入效率较低；

   A，抽象对接流程，书籍列表—书籍基本信息—章节列表—章节基本信息。OOP的方式抽象定义处理过程，并提供默认实现覆盖80%的情况，20%的情况在默认实现上覆盖扩展定制；

   B，Open API接口URL，验签方式，Response信息抽取方式，可通过后台配置的方式定制；接入耗时从2~3人日优化到4~8工时；

5，跨境平台商品发布成功率问题；

   一站卖全球的愿景，需要把国内商品发布到阿里旗下的海外所有站点；

   A，中文到英文以及其他小语种的翻译；B，人民币到当地货币的重新定价；C，淘系类目到海外类目的映射；D，可售库存的调拨；E，一站到十几个站点的商品发布，以及全部站点的订单回流；

   商品模型扩展支持多语言、多币种，集成AI翻译服务；集成算法的类目映射服务；

   定价计算公式可配置，动态计算当地定价；

   国际业务中台解决方案出海后，商品&订单服务中心化，统一服务接口和数据模型。打通HSF&metaQ基于站点标签自动路由的能力，替代原有的OpenAPI公网调用的方式；

   服务调用串行改并行，并加入metaQ延迟消息重试机制；

   图片&视频等媒体文件，预同步到海外站点，避免同步商品属性的时候需要重新同步；同时APP上图片空窗率也下降0.5%左右；

   打通库存中心与GSP的库存状态变更消息，通过GSP可以跨站点调拨库存；

7，商家侧商品搜索，对接多数据源后，面对大批量更新同步，以及写入性能瓶颈的优化；

    解决索引BUILD阶段写入放大的问题。

    商品管理的维度是SPU，下面挂N个SKU，SKU上有重要属性挂牌价和有无库存状态。为支持价格作为搜索条件，搜索引擎Elastic Search的存储设计成父子文档的格式；

    一个SPU document下挂N个SKU document，利用ES的Inner查询可以搜索商品的价格和库存。但子文档的SKU document不可以被单独更新，需要和SPU document一起被更新；

    商品中心一次新增或更新商品，BinLog会包含1个SPU+N个SKU的消息，这样基于BinLog驱动的索引Build会更新（1+N)*(1+N)次文档。

    除此之外，库存中心或营销中心的变更，也会触发索引更新。

    引入Blink，以一秒为时间窗口，聚合多方的SKU BinLog消息到SPU维度，降低索引更新频率为之前TPS的20%。

8，对章节上架及时性的端到端的监控。外部爬虫，内部运营流程；

9，离线圈人存储引擎选型、数据结构选型和数据同步问题；

    Aerospike VS Redis， ClickHouse VS Doris；

10，核心服务内容分发服务的重构上线；

12，书架数据从Redis迁移到DRDS过程的数据清洗，Rebalance过程；

    书架服务治理，存储在Redis中的List结构的数据，需要迁移到DRDS中。

    使用SCAN命令对线上实例的Key进行扫描，发现每次扫描出来的Key数量有一定偏差，超出正常业务增量范围；

    1，增量Redis&DB双写机制；

    2，存量导出RDB文件，对RDB文件进行扫描；

13，NSQD多channel消费，刚开始启动丢消息问题；

    NSQD是AP的架构。PUB消息的时候，如果Topic不存在，只会在当前NSQD 实例1创建Topic。NSQD的lookup机制，每15秒钟刷新一次NSQD的地址列表；

    此时Client端通过lookup接口，获取实例1的地址返回给Client端并建立连接；

    在下次刷新的之前，SLB机制将PUB消息路由到NSQD实例2，此时NSQD 实例2因为没有Client的Channel连接上来，消息会被丢失。