文章通过MySQL官方文档和MySQL源码两个方面，分析了MySQL主从复制延迟参数Seconds_Behind_Master是如何计算的。

近年来，人工智能逐渐在安防，教育，医疗和旅游等工业和生活场景中落地开花。在携程旅游业务上，AI技术同样广泛覆盖了多个旅游产品和旅游服务领域，携程度假AI研发根据旅游的特定场景和业务需求，将自然语言处理，机器翻译，计算机视觉，搜索排序等主流AI技术成功应用于旅游度假的多个业务线，例如自由行，跟团游，签证，玩乐和租车等。

从技术角度，为了适应不同的业务场景需求，涉及到多种AI技术，包括传统机器学习，卷积神经网络，Transformer等深度学习模型结构，以及知识图谱和图神经网络等技术领域。同时，为了充分挖掘AI技术的优势，模型设计复杂度日渐提升，包括模型深度，宽度以及结构复杂度等各个维度，计算量的增大使得AI推理性能瓶颈日益凸显，尤其是实时性的业务需求对推理速度要求更高。为了追求最佳推理性能，往往需要手动进行逐个优化，涉及的开发，部署和沟通成本都很高。主要问题集中在：

• 模型结构种类多，性能瓶颈差异较大，适用的优化方法各有不同，手动优化成本高；
• 优化方法众多，自上而下，涉及多种模型压缩方式，系统级，运行时优化等，手动优化门槛高；
• 逐个手动优化，可推广性差，技术覆盖面有限；
• 硬件平台的差异，需要针对性调优，导致优化的人力成本和部署成本都很高；
• 新模型的发布和迭代，需要应用优化方法，涉及较高的沟通和接入成本，同时带来了性能的不稳定性；
• 模型压缩技术对不同模型的优化效果有所差异，可能需要进行模型的再训练，训练和数据准备流程较长，效率低下；

因此，为了降低优化，部署和迭代成本，提高工作效率，并保证性能稳定，我们尝试搭建模型自动化优化平台，旨在为算法模型提供更全面易用，稳定性更好，使用和维护成本更低的优化解决方案。

用量化的思维解决慢查询。

聊聊大数据元数据管理重要的一环字段血缘。

最近组内同学遇到一个问题，说数据库被业务打死了，无响应，只好用 kill -9 pid 杀掉，然后重启，幸好此时的数据库角色是从库，影响不大。同学自述，在杀掉重启的时候，心里默念，千万别启不来啊，这个库的数据量有点大，快要达到 4T 了。做运维的人都知道，事情就不能念叨，一念叨，这事儿就准发生。这次也不例外，确实是出现了。现象是长时间启动不了，基本卡死状态。

一道 Sequence 的“开水白菜”，敬请“享用”。

随着携程海外酒店业务的发展，遍布全球的海外供应商与携程总部IDC之间的数据传输量快速增长。技术上，这种日益增长的数据量对跨境网络专线的带宽、延迟等提出了更高的要求；业务上，由于当前有限的跨境网络专线资源对业务处理效率及用户体验也造成了一定的影响；成本上，跨境网络专线作为一种昂贵的资源，通过单纯的专线扩容又会给IT成本造成巨大压力。所以我们开始思考是否可以通过公有云结合酒店直连的业务特性来解决日益增长的带宽压力和供应商接口延迟的问题。

酒店直连系统主要是使用自动化接口实现供应商或集团与携程之间的系统对接，实现静态信息、动态信息、订单功能等都通过系统的方式流转交互。目前携程大量海外酒店业务是通过酒店直连系统对接。

本文将主要从携程酒店直连服务迁移部署至AWS过程中所进行的应用架构调整及云原生改造，使用AWS后取得的技术和业务收益，在部署过程中对EKS（Amazon Elastic Kubernates Service）、DNS查询延时和跨AZ流量降低所做的成本优化等几方面进行详细介绍。

一个表的数据量达到一定程度后，稳定性和性能就会出现瓶颈，"化整为零"对DBA 来说无疑是一个很好的选择，此时如何分表就成为摆在业务线开发同学和 DBA 面前的一道不可回避的课题。

相对于传统的开发同学自己根据业务及自己在应用代码中实现分表的方案，本文介绍一下 PostgreSQL 中如何实现对业务相对透明的分区方案。

Qunar 机票作为 Qunar 的核心业务之一，每天都有成千上万用户在 Qunar 的平台上完成搜索预定生单等操作， Qunar 也一如既往地为用户提供优质的出行体验和保证。

探索采用非人工标注文本数据的方式来建立训练数据集的可行性。

Google Play 商店在 2021 年第 3、4 季度正式加强对应用 targetSdkVersion 的限制，要求应用必须以 API 级别 30 (Android 11) 或更高版本为目标运行环境。

作为第一个强制要求分区存储的 API 级别，Android 11无疑是近几年适配工作较为复杂的版本，各个 APP 的适配进度也被寄予期盼。Trip.com APP 在 2021 年第一季度进行了 Android 11 的适配，本文将从方案设计和技术改造等⻆度，聊一聊我们的实践与感想。

随着公司业务的不断扩张，无论是后端、前端抑或是客户端，都面临着应用越来越复杂，越来越庞大以至于难以维护和治理的问题，为了解决这个问题，后端的微服务架构就应运而生了；同理，前端的业务也遇到了类似的问题，自然而然的微服务架构的思想照搬到前端，于是前端的微前端架构应用而生：

一种由独立交付的多个前端应用组成整体的架构风格。具体来说就是将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的小块，而在用户看来仍然是内聚的单个产品。

在进入页面的过程中，用户不可避免地会看到一个加载动画。但加载动画往往比较古板，如果加载耗时稍微长一点，用户就会失去耐心离开页面。为了让用户有更好的浏览体验，骨架屏是一种较好的渐进式加载方案。

骨架屏的实现，也是视觉稿直出代码实现方案的 MVP (Minimum Viable Product)。本文会探讨骨架屏方案的优劣，以及一种前端智能化的骨架屏代码自动生成方案实践。

随着国际火车票业务的高速发展，订单量快速增长，单数据库瓶颈层面的问题逐渐显露，常规的数据库优化已无法达到期望的效果。同时，原先的底层数据库设计，也存在一些历史遗留问题，比如存在部分无用字段、表通过自增主键关联和各个应用直连数据库等问题。

为此，经过讨论后，我们决定对订单库进行分库分表，同时对订单表进行重构，进而从根本上解决这些问题。

去哪儿机票售后为用户提供退票、改签、航班变动、行程服务、疫情政策等服务的业务。为解决复杂查询场景，我们设计了一套将数据从一个数据源聚合导入到另一个数据源，提供同构或者异构、低延时的、最终一致性的数据同步系统。

从2017年开始，携程用户搜索时使用的关键词发生了一些有趣的变化：虽然传统的热门目的地词如“上海、北京”依然占比很高，但是大量长尾词如冷门景点、新兴景点也开始在搜索热词榜上占据一席之地。

对此团队进行了相应的数据分析，发现这些长尾词的急剧上升与一些外部热点如微博热搜，抖音网红，小红书热门文章等呈现正相关关系。对这个问题深入研究后发现，随着互联网用户的年轻化，网民们探索问题的热情明显变高，认知闭合（cognitive closure）度高的用户数量开始快速上升，他们在外部媒体获取到了目的地的热点和信息后，有意愿来专业旅游网站获取更多的目的地资讯，减少不确定性。因此大量用户会搜索长尾词。