得物 Redis 管理平台目前管理着几百个集群、数万个 Redis-server 节点、几千台 server 宿主机，而且通过精细化运维管理，目前 Redis-server 宿主机平均内存使用率和内存分配率均达到一个合理且较高的水位，资源管理处于业内第一梯队，使用最低的成本做到最大的支撑业务缓存需求。 同时，随着业务使用量的持续增长，单台宿主机上的内存使用率越来越高，为了保证宿主机上所有节点的业务日常增长需求或者突发的业务内存上涨，以便能够做到秒级快速垂直扩容，以及添加节点、RDB 离线分析等功能需要的资源，单台宿主机的内存使用率都需要动态的控制在一个合理水位线以下，于是，Redis 管理平台会每天定期自动巡检所有宿主机内存使用率，对于超过合理阈值的宿主机，会选择一部分 server节点进行打散，迁移到其他宿主机上。
对于水印，相信大家都不陌生。在很多内部平台、对数据信息较为敏感的中后台系统当中，我们基本上都会在系统关键数据展示区域中，加上一个半透明的文字水印（通常是用户名或用户id等能够唯一识别用户的标识），以防止使用者通过截图、拍照等方式将目标页面的数据泄露出去。即使是泄露出去之后，也可以根据水印中的用户标识能够迅速定位到“始作俑者”，并采取一些必要的手段将泄密损失降到最低。 上述场景是水印最为常用的一个场景，但不代表水印只能用于这种场景，今天我们从水印技术的前世今生，一步步展开暗水印显隐术的神秘面纱，揭秘暗水印显隐术与 OCR的邂逅，如何提升测试、生产排障效率的。
随着浏览器版本的持续更新，浏览器对JavaScript的支持越来越强大，Babel的重要性显得较低了。但Babel的设计思路、背后依赖的ECMAScript标准化思想仍然值得借鉴。 本文涉及的Babel版本主要是V7.16及以下，截至发文时，Babel最新发布的版本是V7.25.6，未出现大版本更新，近2年也进入了稳定迭代期，本文的分析思路基本适用目前的Babel设计。
本系列前面两篇文章已经分别在图片库和网络库的角度介绍了诸多白屏问题的定位和解决方案，但都是相对独立的问题，并且像OSCP，CDN节点异常之类的第三方问题无法彻底根治，因此为了长治白屏并发掘更多问题，就需要一套相对完善的白屏检测+问题归因体系。 本文将介绍从用户视角出发的白屏检测方案以及线上白屏问题的大致归因思路。
图片加载作为重中之重的App体验指标，端侧的白屏问题则是其中最为严重的问题之一。想象一下如果你在浏览交易商品、社区帖子等核心场景下，图片无法完成加载是多么糟糕的体验。 网络作为图片资源加载的最主要来源途径，如果不能够快速的响应请求，那对上层图片库而言，就是巧妇难为无米之炊了。 而且，通过线上白屏问题归因，我们看到网络问题导致比例最高，占比达81.97%。除去常见的弱网/无网等问题外，还有很多各种各样的网络环境问题我们是可以进行优化的，例如设备不支持IPv6，CDN节点异常，证书超时等。
近期，我们在大模型集群的部署过程中遇到了一些挑战。公司有多个业务场景，每个场景都基于自身的数据进行微调，训练出相应的大模型并上线。然而，这些场景的调用量并不高，同时大模型的部署成本较为昂贵，这造成了资源的浪费。 本文将介绍我们如何利用多Lora技术，将多个场景合并部署，从而有效解决这一问题。同时，我们也将探讨大模型训练与推理过程中Lora技术的应用。
图片加载作为重中之重的App体验指标，端侧的白屏问题则是其中最为严重的问题之一。想象一下如果你在浏览交易商品、社区帖子等核心场景下，图片无法完成加载是多么糟糕的体验，线上过往也陆续有一些白屏的用户反馈。 客户端架构侧从用户白屏问题反馈出发，深入分析每一个用户的实际情况，从0到1完成了白屏体系监控建设，借助独立搭建的白屏分析平台能力，从图片库、网络库、CDN质量等3个维度进行了专项治理优化。本文重点带你了解得物图片库是如何完成白屏精细化监控的基础能力、问题定位、治理优化，实现线上用户白屏问图片库相关Issue反馈基本清零。
随着近几年得物的业务和技术的快速发展，我们不管是在面向C端场景还是B端供应链；业务版本的迭代更新，技术架构的不断升级；不管是业务稳定性还是架构稳定性，业务灰度的能力对我们来说都是一项重要的技术保障，越来越受到我们业务研发的关注。然而，传统的灰度发布服务往往过于定制化，缺乏灵活性和通用性，无法满足不断变化的业务需求，往往灰度的场景可能通过代码硬编码或者简单的配置中心配置。在这样的背景下，本文将介绍一种全新的、轻量级的灰度平台，它将为大家的业务带来全新的灰度体验。
