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

哈啰的业务的多样性体现到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台，并使用业务数据进行了一轮写入压测，发现能支撑业务方的写入速率，扩完后较长一段时间内，该索引也一直没有出现问题，因此认为问题已经被解决了。

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

逛逛是哈啰APP推出的内容社区，旨在为用户提供优质的生活攻略。本次分享以逛逛为例，介绍一下逛逛业务的推荐升级之路。

本文详细介绍互联网广告拍卖机制的发展及应用，包括互联网广告拍卖机制的诞生、经济学视角的拍卖、二价拍卖在哈啰的应用与二价拍卖的前景。

本次分享的主题是哈啰打造自动化增长算法闭环的实践，本篇主要介绍哈啰被动增长算法和哈啰增长引擎的实践。

本次分享的主题是哈啰打造自动化增长算法闭环的实践，上篇主要介绍哈啰C端算法场景和挑战及哈啰主动增长算法。

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

本文将从理论上阐述双活一些基本概念和异地双活项目在哈啰四轮出行的落地。

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

公司采购了XX作为资金平台，并计划将所有的资金划拨操作转移到XX；当前每刻报销也依赖用友进行付款；所以需要将每刻和用友的交互逻辑以及支付逻辑迁移到业财进行管理。

随着公司业务快速发展，数据库中数据量猛增，访问性能变慢。关系型数据库本身比较容易成为系统瓶颈、单机存储容量、连接数、处理能力有限。所以要使用分库分表。