搜索引擎在数据量逐步扩大之后，分布式搜索是必须之路。搜索引擎的分布式除了要考虑数据分片之外，更重要还需要考虑数据的有状态以及各组件的状态流转。

在当下盛行的微服务架构下，服务数量多导致的依赖问题经常会成为开发过程中的绊脚石。也经常会在各种技术交流会上听到类似的话题，大家都在积极的讨论这种问题如何去解决。于是决定给大家介绍下流量染色的原理以及能解决微服务架构下开发过程中的哪些问题。

众所周知，redis是一款性能强悍的中间件。那么它的性能到底多强，大家也是只拿到的是官方给到的数据，那么真实情况是否真的是这样? 带着这个疑问，挑选了redis单机与集群做压测，得到性能数据，并分析两者性能的关系是否是线性的。

跟普通的文本传输相比，富媒体可以直观的让用户了解到消息内容，但是在传输过程中也面临着文件大、内存消耗大、传输过程漫长等问题。

随着深度学习的发展和普及，很多非结构数据被表示为高维向量，并通过近邻搜索来查找，实现了多种场景的检索需求，如人脸识别、图片搜索、商品的推荐搜索等。另一方面随着互联网技术的发展及5G技术的普及，产生的数据呈爆发式增长，如何在海量数据中精准高效的完成搜索成为一个研究热点，各路前辈专家提出了不同的算法，今天我们就简单聊下当前比较常见的近邻搜索算法。

社区收藏业务是一个典型的读多写少的场景，社区各种核心Feeds流都需要依赖用户是否收藏的数据判断，早期缓存设计时由于流量不是很大，未体现出明显的问题，近期通过监控平台等相关手段发现了相关的一些问题。

随着公司业务的快速发展，客服对IM聊天的性能和体验都有了更高的要求，第三方SDK消息通信逐渐遇到了瓶颈，为解决第三方SDK接入带来的潜在隐患、提升IM的稳定性和高扩展性，自研一套可控、稳定、灵活的IM系统已是无法避开的一条道路了。

内容点赞业务在得物社区中是一个非常高频的业务场景，功能本身复杂度不高，但是业务场景多、qps高、而且由于社区的用户体量，整体点赞的数据量非常大。其中最核心、对响应性能要求最高的主要是“用户是否点赞内容”和“内容点赞数”场景。

SCA（Software Composition Analysis）软件成分分析，通俗的理解就是通过分析软件包含的一些信息和特征来实现对该软件的识别、管理、追踪的技术。

作为CMS替代品的G1，一直吸引着众多Java开发者的目光。G1的目标是在满足期望的停顿时间的同时保存高吞吐量，适用于多核、大内存的系统。

Db层治理工作一直在路上，完成全面梳理改造只是迈出的第一步，一个好的规范如何进行推进下去，让大家保持统一的规范，随着时间的推移，这种规范能够继续保持不走样，是我们需要思考的问题。

随着得物App和商品体量的快速发展,圈选场景的商品集也在迅速膨胀,这些海量数据如何在不拖垮服务内存的前提下进行内存diff,一直是困扰在我们的难题,最终通过引入RoadingBitMap很好的解决了海量数据内存diff的问题。

当前我们微服务容器化部署JVM 实例很多,常常需要进行JVM heap dump analysis,为了提升JVM 问题排查效率,得物技术保障团队研究了JVM内存Dump 原理与设计开发了JVM 内存在线分析。

随着客服域章鱼工作台的独立孵化，热线作为重要的一部分，从工单迁移至章鱼工作台，这个时候的章鱼只能接打电话，查询基本信息，因为从工单迁移出来失去了和工单的绑定，因此与工单的重新结合，成为热线的一个里程碑式升级。

分类TAB商品流是得物app购买页面内除“推荐”页外的所有TAB内的商品推荐流，如“鞋类”、“箱包”等。当用户进入分类TAB中，我们可以简化为给定<userId, tabId, itemId> 三元组的商品流推荐，可以看出，分类TAB的推荐场景跟其他“开放式”推荐场景的最大差异在于，是限定条件下（品类）的推荐，与搜索场景有一点相似度，分类TAB代表着用户的品类意图。以我们目前的迭代进度，现阶段主要聚焦于<userId, ItemId>的二元建模，实际上<userId, tabId>，即用户的行为与TAB的相关性，以及<tabId, itemId>，即TAB与商品的相关性，是我们后续进行差异化建模需要着重考虑的；以下的相关进展主要讲述较为通用的商品推荐模型的落地迭代。我们以多目标排序模型作为精排策略。

客服的演进从开始的初始的平台到现在的成熟系统，在整个得物客服组成员的共同努力下，一步步的不断完善优化才有了在巨多会话量压力下，仍然稳定好用的系统。