云存储 NAS 产品是一个可共享访问、弹性扩展、高可靠、高性能的分布式文件系统。 NAS 兼容了 POSIX 文件接口，可支持数千台计算节点共享访问，可挂载到弹性计算 ECS、容器实例等计算业务上，提供高性能的共享存储服务。鉴于多主机间共享的便利性和高性能， NAS 在得物的算法训练、应用构建等场景中均成为了基础支撑。
目前得物ERP主要鉴别流程，是通过鉴别师鉴别提需到仓库，仓库库工去进行商品补图拍照，现有正品库59%的人力投入在线下商品借取/归还业务的操作端，目前，线下借取的方式会占用商品资源，同时在使用用途上，每借出10件会出现1次拍照留档，因此会有大量的线上阅图量在日常鉴别和学习中发生；正品库可通过图库搭建，提升图库质量，大大节约线下用工和物流成本支出。
随着互联网电商平台竞争的加剧，各平台的业务复杂度不断提升，线上环境的稳定性面临更大挑战。在汇金领域，由于其高资金属性，除了确保链路可用性达到99%以上，防止资损亦成为关键保障事项。得物汇金业务涉及复杂的资金流和大额资金敞口，因此实施资损防控尤为重要。
伴随着大模型的性能提升、成本下降，在Web在线对话场景以外，大模型也越来越多的被集成到传统业务场景。在大模型API交互模式、业务集成模式经百家争鸣现已趋于稳定的背景下，Spring作为Java生态里的OSS巨头也下场为LLM提供生态支持，于近期释出 spring-ai 正式版。需要说明的是，Spring-AI 所提供的能力并不神秘，业务上也并非必须用Spring-AI不可。但是，就像过去Spring对新的数据库、新的中间件提供生态支持一样，Spring-AI提供了一套和Spring全家桶兼容并且语义一致、良好设计、易拓展的大模型交互的Java API，可以极大的降低LLM集成和开发的成本。从大模型的工程化、实用化角度来说，当你厘清Spring-AI这一套API设施的逻辑后，事情最后还是会回归到业务开发人最熟悉的CRUD领域。就像使用Mybatis操作MySQL一样，我们会用 spring-ai 来操作大模型。
随着AI辅助编程工具的普及，Cursor IDE已经成为越来越多开发者的选择。然而，在实际使用过程中，我们发现了一个关键问题：如何让AI真正理解项目需求并生成高质量、一致性的代码？
在当今微服务架构盛行的时代，分布式系统已经成为企业级应用的标准模式。然而，随之而来的分布式事务问题也成为了开发人员的一大挑战。在复杂的供应链系统中，各个业务模块之间的数据一致性一直是一个重要且棘手的问题。物流、库存、订单等系统相互协作，如何在保证业务高效运转的同时，确保跨系统操作的数据一致性？ 今天，我们将深入探讨一个专为解决供应链分布式事务问题而设计的框架——「一致性框架」。
使用过Redis的同学肯定都了解过一个说法，说Redis是单线程模型，那么实际情况是怎样的呢？其实，我们常说Redis是单线程模型，是指Redis采用单线程的事件驱动模型，只有并且只会在一个主线程中执行Redis命令操作，这意味着它在处理请求时不使用复杂的上下文切换或锁机制。尽管只是单线程的架构，但Redis通过非阻塞的I/O操作和高效的事件循环来处理大量的并发连接，性能仍然非常高。然而在Redis4.0开始也引入了一些后台线程执行异步淘汰、异步删除过期key、异步执行大key删除等任务，然后，在Redis6.0中引入了多线程IO特性，将Redis单节点访问请求从10W提升到20W。而在去年Valkey社区发布的Valkey8.0版本，在I/O线程系统上进行了重大升级，特别是异步I/O线程的引入，使主线程和I/O线程能够并行工作，可实现最大化服务吞吐量并减少瓶颈，使得Valkey单节点访问请求可以提升到100W。
“得物平台上的大量商品都具有文化与精神属性，用户往往通过社区来进行了解和分享。”得物平台作为潮流文化与电商融合的前沿阵地，其社区活动业务的演进备受瞩目。得物平台的很多商品蕴含深厚的文化与精神内涵，这吸引用户在社区进行深度的了解与分享。潮流以品牌和带有潮流元素的产品为载体，以社区和内容作为传播媒介。从业务视角审视，种草激励、MCN 入驻、达人签约以及各类活动玩法，本质上皆是内容与品牌之间的博弈。通过活动业务，能够获取更为丰富、优质的内容，而这些内容又能进一步强化品牌文化与形象，进而筑牢得物社区的潮流心智根基。
在得物技术团队双周迭代模式下，前端自动化测试体系的建设已成为提升研发效能的关键突破口。当前技术部门推行研发自测的核心诉求，其核心诉求在于通过建立可信的质量保障机制释放测试资源，以此承接更多的业务需求，提升需求吞吐率。双周迭代的机制对研发流程提出了双重挑战：既要保障两周内完成需求开发、测试验证到交付上线的完整闭环，又需保障研发交付的代码质量稳定可靠且经过充分的测试验证。服务端已通过流量回放、代码覆盖率检测等成熟方案构建质量护城河。我们统计了各个前端业务域在2025 年Q1中的自测率，服务端实际自测率为：24.45%，而前端的实际自测率仅有：15.35% 。因此，在完成技术部研发自测率25% 的目标的情况下，前端是一个较大的短板。而制约前端实际自测率提升的一个重要的因素就是缺乏像服务端流量回放和代码覆盖率检测技术这样的自动化代码质量保障技术，导致测试同学对于前端自测质量的置信度存疑，无法检测和衡量负责该需求的前端是否已经完成了足够详尽的自测。因此，如果需要提升前端的研发自测率，我们首先需要从这些质量保障技术出发，夯实地基，构建属于前端的质量保障护城河。
在算法工程中，大家一般关注四大核心维度：稳定、成本、效果、性能。其中，性能尤为关键——它既能提升系统稳定性，又能降低成本、优化效果。因此，工程团队将微秒级的性能优化作为核心攻坚方向。本文将结合具体案例，分享算法SRE在日常性能优化中的宝贵经验，助力更多同学在实践中优化系统性能、实现业务价值最大化。
