本文主要讨论商品复购推荐问题，提出一种商品复购推荐模型的实现过程。基于深度学习的商品推荐问题的研究有很多，复购推荐的区别在于更加关注用户购买时序行为信息，通过历史订单交易时间分布和商品分布情况，对用户的再次购买行为进行预测。

发现资损告警，然后第一时间执行对应的应急措施，将客户和平台的资损风险降到最低是资损防控建设的核心目标，也是检验成果的最要指标，保障交易业务更加安全、稳定的运行。

Module Federation：是模块联邦的意思，在Webpack 5中流行起来的，也属于一种微前端方案。

总体测试流程上，时间缩短了百分之50%以上，能够更加快速且精准的定位并发现问题，节省了测试时间。自动化测试带来的收益很明显，具体体现在效率上的提升，如：从前手工造数据（某些复杂的单据）会占用很大的的工作量，现在就很不一样。

得物客服目前有工单、呼叫、IM在线客服几个系统，因为客服技术团队成立不久，所以各个团队除了大部分时间在攻坚完善原有系统外，还要去实现精细化管理和创新。

之前，很长一段时间里，客服同学查看数据还需要跟开发提需求写 SQL 去查询，后来也有 BI 团队做离线 T+1 报表。

随着业务发展，各客服团队对现场精细化管理需求也越来越强烈，日常组内作业状态，需要实时感知并及时干预调度，提升处理时效。管理者也需对整体数据把控并以此决策。过去临时性的需求无法稳定准备及时的执行反馈，离线T+1的报表时效性也无法满足需求。因此由业务团队及产品整理，提出建设实时大屏的需求。

AI在目前互联网可以说早已渗入各个业务。搜索、预测、图像识别、语音识别等等早已应用较为成功。

得物被广大年轻消费者熟知的一个原因是其强大的质量与正品保障体系，而为此背后需要的是得物供应链体系艰辛的付出。

算法推出模型中台解决方案，来辅助人工做瑕疵检测与一致性识别。同时需要将部分AI的功能赋予端侧，让其能辅助模型中台更加准确高效的实现高效的瑕疵检测与一致性识别。所以我们思考在端侧部署AI标准化引擎去对拍摄的照片做初步的筛选和部位分类。

在分布式服务中，一个业务的单个节点性能不能满足需求，需要很多节点同时工作来满足性能和高可靠需求。例如：网络的SLB服务（负载均衡），即使是超大规格的ECS（虚拟机），单个ECS的吞吐量只有不到50G，整个公有云有成千上万的租户，加起来的吞吐量需求是以T为单位的，这就需要大量的ECS来满足超大吞吐量需求。

在实际的公有云运营中，公有云这样的多租户系统在租户之间共享资源，这意味着一个租户的活动可能会对另一个租户对系统的使用产生负面影响。这就是noisy neighbour（坏邻居）问题。

面对得物App现在日益增长的投放业务需求，我们对唤端成功率有了更高的追求，也明显感觉到第三方的解决方案越来越吃紧，于是我们也开始逐步搭建自己的唤端技术平台，通过不断积累经验、学习别人优秀的唤端方案，期待努力早日完成得物自研唤端平台能力。

随着深度学习和计算机硬件的快速发展，基于深度卷积神经网络的一系列算法都取得了显著的进展，其中人脸识别作为计算机视觉领域中时间最久远、应用最广泛的研究课题之一，近些年也在深度学习的加持下在性能方面获得了大幅提升，并在实际的生活场景中得到了广泛的应用。

随着得物App消息平台的推送越来越多，业务接入也越来越多。针对具体业务的兼容逻辑已经不能满足业务快速开发的需求。研发效率越来越差、稳定性、时效性指标逐步降低等。在推送容量确定的场景下各个业务指标数据相互影响。消息平台需要针对不同的业务不同处理、平台统一能力编排等进行平台化优化&改造。

大家都在做异地多活，得物基于自己的电商物流场景是怎么去设计架构的，又遇到哪些问题，让我们的研发同学来解答下。

管理学大师彼得 - 德鲁克曾说过：无数据不管理。数字是人们快速认知事物的一种有效方式。无论在生活还是工作，对事还是对人都息息相关。碰上难以用数字描述的事物或现象肯定是没有找对适用的指标和度量方式。尤其对于质量工程方面的工作，定量的呈现远比定性描述更有说服力。而“三级指标体系”就是质量平台在这一年的反复打磨中，逐渐清晰并成型的，能够将得物工程质量加以体系化度量的一种最佳工程实践。

在得物技术体系中，大量使用Redis作为缓存中间件，以应对高并发下的大流量场景。在使用缓存时，不得不考虑数据一致性问题，即保证缓存中的数据和DB始终可以保持一致。常规的解决缓存一致性的方案一般为先修改DB并提交事物，再操作缓存更新或者失效，为了应对极端场景往往会再采用延迟操作的方式进行缓存的二次处理。

但实际开发中，遇到很多代码不规范的场景，在JDBC事务中进行缓存删除或者更新等操作，带来的问题是当JDBC事务未提交就完成了Redis的操作，容易造成二者数据不一致。所以我们思考：既然Redis本身也提供了事务的解决方案，那能不能将Redis事务和DB的事务进行结合，来保证数据一致性的问题呢？接下来我们就带着这个问题看看看Redis事务的实现、使用，最终探索一下将Redis操作结合DB事务使用的可能性。

近几年，随着得物业务的快速发展，应用数目与实例规模在快速地增加。得物的注册中心也在不断的演进优化，以支撑业务的发展。从最初的 Nacos 到 Nacos Proxy 引进再到完全自研的 Sylas 替换 Nacos，期间遇到了哪些问题，如何解决这些问题，以及未来的演进方向，是本文主要探讨的内容。

本文通过对SidecarSet的源码按照SidecarSet CR的调谐过程、sidecar容器的注入过程和sidecar容器的升级过程 这三个模块做了分析，三个模块的处理流程有交叉，所以文中介绍时会有看到后面时又得回过头去看前面的现象。

IPv6 相对 IPv4 可以提供海量的网络地址，同时 IPv6 在协议上预留了广阔的创新空间，为互联网长期升级演进提供了新的基础平台，已成为全球下一代 互联网发展的核心方向，也是支撑我国互联网升级演进的唯一正确路径。

对于任何一家月活上亿用户的互联网公司来说，IPv6 升级改造都是一件很复杂的事情。很多同学可能好奇 IPv6 到底要怎么改造，本文将整体介绍下『得物 App 全场景 IPv6 改造』的项目经验，供大家参考。