快速有效的AB实验是策略方案最优化、用户体验的强有力保证，而背后的黑科技来源于基础的统计理论。因此，要想更好地设计实验和解读实验结果，就需要理解基础的统计学知识和AB实验所涉及的统计学理论，以此更科学有效的做出决策。

在得物App的版本迭代中，为提升用户体验，产品侧提出订单详情页优化新需求，定义客户端模块组件，制定各个模块的信息展示规范，重新梳理订单详情页的全部文案，搭建文案配置后台，支持订单详情页头部文案支持可配置，方便用户清晰了解订单详细信息。

触达策略的核心是任务。首先配置任务，任务下有策略，策略下有行为，行为可以发送push推送，发放优惠券，发送消息盒子，发送短信等。然后等到任务执行时间，执行任务下所有行为。

面对互联网系统的三高（高可用，高性能，高并发），数据库方面我们多会采用分库分表策略，如此必然会面临另一个问题，分库分表策略下如何生成数据库主键？那么今天针对此问题，我们就聊聊如何设计一款“百万级”的分布式ID生成器。

业务监控平台是得物自研的一款用于数据和状态验证的平台。能快速便捷发现线上业务脏数据和错误逻辑 ，有效防止资产损失和保证系统稳定性。

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

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

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

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

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

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

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

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

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

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

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