负载均衡是分布式系统里最常用的能力，实现方式有很多，今天要讲的是遇到的一个真实的生产问题。

哈啰好物商城中，存在大量的长列表数据，我们可以采用虚拟列表来做优化。

本次跟大家分享的是智能创意在哈啰的应用实践，包括以下几个部分：什么是创意、如何进行创意生成与创意优选、哈啰智能创意系统展示。

diff 算法是一种通过同层的树节点进行比较的高效算法，避免了对树进行逐层搜索遍历。diff 算法的在很多场景下都有应用，例如在 vue 虚拟 dom 渲染成真实 dom 的新旧 VNode 节点比较更新时。

本次跟大家分享的是基于出行领域全场景的mock提效探索与实践，包括以下几大部分：哈啰业务数据场景痛点、哈啰HiMock和传统Mock的对比、Mock技术支撑全场景业务域的实践、规划&探讨。

本次跟大家分享的是哈啰调度算法评测与仿真系统，包括以下几大部分：哈啰两轮车调度算法介绍、调度算法在效果评测上的挑战、调度算法仿真系统介绍、收益和展望。

在前文中我们介绍了哈啰研发团队的组织情况，以及在日常工作中碰到的四大挑战：

• 挑战1：团队急剧扩张，跨团队协同越来越困难
• 挑战2：不同业务发展诉求不同：成熟业务求稳，创新业务求快
• 挑战3：在业务和团队协同复杂度上升的同时，仍需做到快速响应，适应变化
• 挑战4：如何确保大型组织持续保持高效能并不断提升

同时，我们也抛出了哈啰的“3+X”应对方案：

严格统一的迭代节奏；拉毛线；SOS；+ X

那么其具体含义和做法到底是什么呢？今天我们结合一些实际的案例来深入探讨一下。

前面我们花了两篇文章的篇幅，跟大家详细分析了哈啰在大规模敏捷组织中所面临的4大挑战，究其核心是需要解决以下两个问题：

挑战1~3是需要在大型组织中建立一个高效的沟通及决策机制；

挑战4是需要建立一个合理的评价体系。

在中篇中我们介绍了，挑战1~3是通过运用敏捷模式本身的特点做了补强来处理，那么很自然的“X”就是应对挑战4的办法。

我们今天单独来聊聊这个“X”。

随着“敏捷”逐渐被国内越来越多的从业者接受，自然而然的，越来越多的大规模的敏捷模式也逐渐的映入到了大家的眼帘：LeSS，SAFe，Spotify......于是我们跟当年不知道如何选择单个团队的敏捷实践模式一样，又陷入了不知如何开展大规模敏捷实践的困境当中。

本次跟大家分享的是哈啰搜索推荐一体化建设，包括以下几大部分：搜推算法介绍和模型沉淀、搜推一体化引擎和算法组件设计和搜推一体化算法在哈啰的应用。

哈啰的业务的多样性体现到APP页面上，我们会发现整个APP的页面设计呈现的方式发生了很大的变化。早些年哈啰APP页面的功能较为单一，上图是近几年哈啰APP的页面，可以看出页面更加多样化，很多业务的功能和信息都在这些页面上展示出来，也有很多交互的能力。

这样的业务发展趋势及APP的页面设计方式，给我们的技术团队带来了两个痛点和挑战。一是交付效率，复合型的页面往往会涉及到多个业务团队的需求，也会涉及到多个技术团队去合作开发，效率就会下降。同时，这些页面都属于流量曝光型页面，产品侧需要做产品的AB测试，尽快地去上线并回收数据。如果发现功能需要调整，产品就希望尽快变更，所以用户触达效率及交付速度都对产品的迭代有很高的要求。二是用户体验，哈啰的首页及各个业务的一级频道页，都是一个业务最核心的流量页面，对用户的体验要求很高，如多端一致性、稳定性和交互流畅度这些指标，相对于其他三四级页面来说，对稳定性的要求也会更高。

7月22日，2022年GIAC全球互联网架构大会在深圳顺利举行。哈啰高级算法专家王凡老师做了《哈啰顺风车智能交易体系建设》的主题分享。包括以下几大部分：业务背景介绍、智能应用和方法总结。

上期，我们详细介绍了 Redis 的3种底层数据结构。下面我们介绍其余的数据结构，来看看它们是如何实现的。

Redis 这么优秀的原因是什么呢？我们可能会想到它基于内存的存储介质，多路复用的IO方式，以及主模块的单线程模型等等，但往往忽视了一点，就是 Redis 在底层数据结构上的实现。

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

AIoT团队在搜索平台上维护了一个较大的索引，其写入平均有2k到3k的tps，查询也有数百QPS。由于该索引较重要且占用资源较多，因此使用Elasticsearch的template功能将之单独部署在专用的机器上。

从5月底开始，写入此索引的flink实时任务就会偶现失败重启的情况，经排查，发现是写入Elasticsearch的请求超时导致的，结合当时机器的cpu占用等指标判定是写入tps过高导致Elasticsearch无法承受，因此，将该索引所占的机器从2台升级到3台，并使用业务数据进行了一轮写入压测，发现能支撑业务方的写入速率，扩完后较长一段时间内，该索引也一直没有出现问题，因此认为问题已经被解决了。

本篇文章以理论+线上实践的方式详细介绍下哈啰基于水位自定义调度器的落地过程。