在目前互联网飞速发展的今天，企业对用人的要求越来越高，尤其是后端的开发同学大部分精力都要投入在对复杂需求的处理，以及代码架构，稳定性的工作中，在对比下，简单且重复的CRUD就显得更加浪费开发资源。目前scm供应链管理页面中，存在约77%的标准页面，这些标准页面里，还存在着很多类似的参数配置页面，就是对某一个模型进行增、删、改、查、导入、导出进行类似的操作，这种开发工作技术含量较低，而且相对耗费人力。
在移动互联网蓬勃发展的今天，用户的选择日益多元化，App市场的竞争也愈发白热化。为了在激烈的市场竞争中脱颖而出，提升用户获取效率并增强用户粘性，越来越多的应用开始采用积分兑换、抽奖等互动玩法。这些精心设计的运营策略不仅能够满足用户的参与感和成就感需求，更能有效促进社交传播，提升品牌忠诚度。通过持续优化和迭代，开发者能够在竞争激烈的市场中占据优势地位，实现用户的可持续增长和长期留存。 基于提升系统复用性和稳定性的考量，我们构建了一个统一的兑换商城中台系统。该中台旨在为各上游业务线提供标准化的积分兑换和奖励机制，使各类应用和服务能够快速接入并享受便捷的服务支持。通过这一中台架构，我们不仅实现了核心业务逻辑的集中化管理与维护，更为后续的功能扩展（如抽奖、彩票等多样化玩法）奠定了坚实基础，从而显著提升了开发效率和用户体验。
DGraph是得物自主研发的新一代推荐系统核心引擎，基于C++语言构建，自2021年启动以来，经过持续迭代已全面支撑得物社区内容分发、电商交易等核心业务的推荐场景。DGraph在推荐链路中主要承担数据海选和粗排序功能，为上层精排提供高质量候选集。
在模型轻量化领域，量化是一种用于减少神经网络模型大小和计算量的技术，将模型参数（权重）或中间变量（激励）从高精度类型（FP32, FP16, BF16等）转换为低精度类型（int8, int4, fp8等）。 而近年来随着Transformer，MoE等架构的提出和大模型的兴起，使得神经网络模型能轻松突破几十亿甚至上万亿的规模参数，因此，我们需要一些适应于大模型的压缩技术，来降低模型的部署成本，并提升模型的推理效率。 从最初的GPTQ、AWQ等weight-only的量化算法开始，到现在LLM从训练、推理、轻量化、Agent等所有赛道都卷到飞起的时代，基于大模型的特性，在两年多时间里业内已有很多新的量化算法。
随着ES在业务场景中的使用逐渐增多，平台对ES集群的稳定性、管理、运维的压力逐渐增大，通过日常的运维情况来看，发现用户对ES的了解熟悉程度参差不齐，经常性的遇到索引创建不规范，或者参考别人索引的创建脚本进行创建索引，对索引没有一个比较清晰的认知，对索引结构的规划也寥寥无几，为此，平台使用了一些列手段来帮助用户提前合理规划模板，比如索引、模板的创建接入飞书审批流，平台侧会逐一结合业务场景和ES集群情况详细沟通确定索引或者模板结构；又比如ES内核增加业务不停服的动态扩分片能力，旨在进行不合理索引的治理提升ES集群稳定性（索引一旦创建分片是不能修改的），我们内部改动ES源码实现了不停服动态扩分片。 因此有必要从ES的索引讲起，让大家对ES的索引从概念、原理到使用有一个清晰的认知，希望日常业务场景中用到ES的同学能够抽时间读一下。当然文章避免不了存在主观的分析，大家可以在文章底部进行评论或者私聊我们，一起探讨。好了废话不多说了，现在开始介绍。
DPP依赖于算法平台的引擎服务（FeatureServer，召回引擎, 精排打分），提供“开箱即用”的召回，粗排，精排服务。采用“热加载技术”解决算法平台的工程和算法同学策略迭代效率问题，支持策略随时发布，让他们可以专注于业务逻辑，即可拥有稳定的推荐在线服务。
很高兴与大家分享现阶段 Cursor 在我的工作中的使用体验。首先是预期管理，本篇文章不会分享 x 个你可能不知道的小技巧，也不会让你拥有无需自行编码的能力，同时不涉及 Cursor 工程化方面内容。仅仅是围绕个人开发流程中的已有问题，分享如何使用 Cursor 来提升这部分的开发体验，在工作中持续保持好的节奏和状态。
得物一直重视用户体验，尤其是启动时长这一重要指标。在近期的启动时长跟进中，我们发现了在BuildingClosure 阶段的一个优化方式，成功的帮助我们降低了 1/5 的 BuildingClosure 阶段的启动耗时。Building Closure 并非工程的编译阶段（虽然它有一个building），Building Closure 是应用初次启动时会经历的阶段，因此它会影响应用的启动时长。 单就BuildingClosure阶段而言，我们观察到该阶段其中一个函数从 480ms 暴增到 1200ms 左右（PC 电脑端运行 dyld 调试统计耗时数据），我们通过优化，将耗时从1200ms降低到110ms。即使相比最开始的情况，也相当于从480ms降低到了110ms，由此可见Building Closure 优化是应用进行启动优化必不可少的一个重要手段。因此在这里我们也和各位读者进行分享，期望能够对各自项目有所帮助。
在经典的CAP理论中一致性是指分布式或多副本系统中数据在任一时刻均保持逻辑与物理状态的统一，这是确保业务逻辑正确性和系统可靠性的核心要素。在单体应用单一数据库中可以直接通过本地事务(ACID)保证数据的强一致性。 然而随着微服务架构的普及和业务场景的复杂化，原来的原子性操作会随着系统拆分而无法保障原子性从而产生一致性问题，但业务实际又需要保障一致性，为此BASE理论提出了最终一致性来解决这类问题。那么如何在跨服务、跨数据库的事务中保证数据最终一致性。
