奇怪现象你是否遇到过服务内部即使设置了线程超时时间，上游依旧报超时异常？你是否遇到过下游服务快速响应，当前服务后续方法无耗时逻辑。但偏偏整体执行耗时极长？你是否遇到过gc耗时规律性增长？却与流量不成比例？你是否遇到过Eden空间突然降低且维持很久？背景那是一个平静的午后，突然的gc耗时告警惊扰了打工人专...

年轮依旧，时光匆匆，2024 甲辰龙年正悄然向我们走来。在新春到来之际，我们为大家盘点过去一年的精选文章，整理制作成一本近 300 页，6 万字的电子书。电子书的内容覆盖后端、前端、算法、运维、质量等不同领域，每一篇都干货满满，希望对各位同学拓展技术思路有所帮助。感谢各位同学一直以来的支持，也欢迎大家将「哈...

10 月 26 日，思码逸 DevData Talks 邀请到了哈啰出行研发效能团队负责人高明国。他多年来负责公司业产研协同平台建设、效能度量工具体系建设、测试效能工具建设、稳定性工具建设、质量流程规范管理等。他这次为我们带来的主题是《哈啰一站式业产研协同平台建设与实践》，分享如何通过一系列效能方案与最佳实践后，帮助...

最近发生了一个apollo带宽被打满的问题，因此看了一下apollo的部分设计和源码，本文针对发生的apollo带宽问题，聊聊apollo部分设计的理解。

我们有一个flink任务，消费的kafka的数据，写入到es，非常简单的逻辑，但是出现了数据丢失的情况，之前没遇到过，初步猜想是转换逻辑或脏数据的影响，排查了一圈，未发现Exception等相关信息。猜想是写入频率太快，es写入的时候，出现了version conflict，也没找到相关证据。

我们小组主要负责四轮场景下的司乘匹配工作，基于开源分布式搜索引擎ElasticSearch实现订单的召回。同时我们使用Flink实时消费kafka消息，将订单数据写入到对应的ES索引中。

随着人工智能的发展和技术进步，越来越多的企业开始使用人工智能技术做效率的提升和业务效果的提升，降低企业成本，增强企业竞争力。本文将基于哈啰AI平台的能力，以接入普惠工单系统自动转派为例，讲述如何通过算法能力赋能后端研发提效。

在一次全链路压测过程中，顺风车匹配ES集群出现了个别节点CPU几乎被打满的情况。第二轮压测，我们关闭了最近上线的H3召回匹配升级AB实验，在同样压力下集群cpu运行平稳，保持在35%左右，开启AB实验后之前异常节点cpu又急速增加，初步定位到节点异常应该和H3召回升级实验相关。

最近面试问过很多候选人Java锁有关的知识，可以感受到的是，大家的理解基本都停留在“八股文”的阶段，实质上对Java的锁以及多线程的同步机制这种底层原理，理解的不是很好。网上这类文章已经很多了，但是看了下有好多文章是过时的，典型的例如AQS里的addWaiter方法在JDK16里就没见到，或许代码进行了重构了。

近年来随着大数据时代的到来和计算能力的提升，人工智能在各个领域都取得了显著的进展。原先在云端进行特征的存储与处理、模型的训练、在线推理，在客户端进行数据的展示的架构展现出越来越多的缺点和局限性。本文将结合端智能的优势，结合哈啰一站式AI平台的现状，讲述一站式AI平台如何支持多端智能（服务端、flink端、...

一是运维复杂问题，AI平台有多种不同语言的模型推理服务， 如python、C++（tf-serving）、Java等，各自管理上百个不同类型的模型；架构也很复杂，存在大型单体应用、多container应用、小型GPU应用等多种服务组织方式；同时，手动运维有余，自动化工具不足。

本文介绍如何将机器学习预测能力迁移至es内部，增强排序能力, 构建一个高性能、分布式搜排一体系统，并通过落地更多复杂模型特征和更深的计算，为业务带来新的增长点，我们将LR->树模型完成全量排序，给核心业务带来1.2%的ab增长。

业界有很多大促活动，像618、双11、双12等等。每一次大促不只是给业务带来了新高，对于技术同样也有很重要的意义，纵观一些优秀的技术团队，都是跟着业务一起成长的。在高并发大流量的背景下，如何支撑好业务运营，是一件很有挑战性的事情，它可以从多方面检验我们的技术能力，对我们的系统架构和应急保障都提出了很高的...

过去的2022年，哈啰全面升级，焕新出发，不断推动技术更新迭代。哈啰技术人也做了大量的总结和思考，并以文字等形式沉淀下来，向各位同学分享哈啰的实践探索与经验心得。

公司内部的ES访问架构一般是，Java应用--->SLB(域名)---->ES ingest node (no data) --> ES data node，其中ingest节点是对外暴露的，供Java应用访问，承担了一个纯client角色，不提供数据存储和倒排索引检索服务。这其中SLB是为了方便起到一个域名和负载均衡的功能，绑定后端的n个client节点，并且做到对业务...

压缩列表是 Redis 为了节约内存而开发的，是由一系列特殊编码的连续内存块组成的顺序性数据结构，我们可以从源码的注释中看到官方对它的定义。

提到 Redis，我想大家并不陌生，基本上每个项目中都会有它的身影出现。作为一款性能卓越的中间件，其功能强大，在系统中经常扮演着十分重要的角色，像缓存、分布式锁和消息队列等，都是我们所熟知的功能。Redis 在我们的项目中频繁出现的原因，主要是它可以提升系统的性能，支撑起系统的高并发。那么 Redis 这么优秀的原...

我们团队基于Elasticsearch开发了一款将数据从数据库实时同步至Elasticsearch的工具——搜索平台，其实现方式主要是通过flink将数据库中已有的存量数据导入Elasticsearch，并订阅数据表的binlog，将实时改动也同步至Elasticsearch。

k8s原生调度器默认资源平衡是根据Node节点的空闲request来实现的，但是我们配置Pod request预设值时基本是虚拟机的思想，会比实际程序使用值偏大并且和实际偏差较大，造成Node的request已分配比和资源实际利用率(水位)偏差较大，如下图所示。如果集群规模较大或集群运行时间较长，每个节点中request分配虽然接近，但是节...

概述：为提升系统稳定性，和线上故障的触达、定位、恢复的速度，以及建立一套可执行、便于操作的特色的演练规范，并沉淀通用、可移植的演练规范，故发起了故障演练。

本文主要讲述异地双活方案redis的热备、双写、双向同步的区别和优劣势。并且说明了双写同步方案中redis集群主从数据同步的过程，以及中间件方案遇到的部分问题点，说明最终方案的实现思路和方案。

sharding_id即route_code，双活根据路由规则会转换为route_code（四轮出行为地域）。每个route_code会对应中心机房或者单元机房。网关、soa、redis、db等都会根据route_code路由到正确的机房。

搜索平台的公共集群，由于业务众多，对业务的es查询语法缺少约束，导致问题频发。业务可能写了一个巨大的查询直接把集群打挂掉，但是我们平台人力投入有限，也不可能一条条去审核业务的es查询语法，只能通过后置的手段去保证整个集群的稳定性，通过slowlog分析等，下图中cpu已经100%了。

随着哈啰用户体量的不断增大，业务场景越发复杂化，尤其在目前已变成群众出行必不可少的基础设施的背景下，如何识别线上系统瓶颈、风险，保证系统的高可用已经变得尤为重要，让技术更好的服务业务，创造更多的价值。 聊到全链路压测，对很多同学来说更关注它的技术实现细节，这没错。但全链路压测想要成功的在生产环境实...

使用Sentinel集群限流的，如果使用嵌入模式，在异地多活专线抖动情况下会出现服务调用超时的情况，本文从限流概念和集群限流的实现方式出发整理了该知识点，特别是网络抖动情况下，对服务造成影响情况进行详细说明。

随着公司业务不断的发展，系统也在变得越来越复杂。系统的复杂度体现在：前端对后端的依赖，后端服务之间的依赖。在没有明确强弱依赖的前提下，我们很难进行熔断、降级、限流的相关操作，也不能有效的对系统进行相关优化改造、持续推进系统稳定性提升。

哈啰作为一家以出行起家的公司，尤其是两轮业务已经逐渐成为影响民生的基础设施，在如此大体量业务的今天，任何一个小故障都可能影响成千上万的人，因此有必要对稳定性做重点保障。

因为业务需求，接触了ws协议以及在实时语音识别中的运用，总体的感觉还是挺有意思，并且了解到很多人其实是没有用过这个协议的，所以还是值得分享记录一下。

随着公司业务快速发展，数据库中数据量猛增，访问性能变慢。关系型数据库本身比较容易成为系统瓶颈、单机存储容量、连接数、处理能力有限。当单表的数据量达到1000W或100G以后，由于查询纬度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。

中台化建设不是简单的技术建设，整个运营、产品、技术团队的组织架构划分都会影响中台化建设。中台化建设最重要的是实现能力的灵活复用和扩展的成本最小化。由此会带来的中台臃肿导致的稳定性问题，环境资源竞争问题会在中台化建设中凸显。