MeiTuan

很多低延迟高可用Java服务的系统可用性经常受GC停顿的困扰，作为新一代的低延迟垃圾回收器，ZGC在大内存低延迟服务的内存管理和回收方面，有着非常不错的表现。 本文从GC之痛、ZGC原理、ZGC调优实践、升级ZGC效果等维度展开，详述了ZGC在美团低延时场景中的应用，以及在生产环境中取得的一些成果。希望这些实践对大家有所帮助或者启发。 ZGC （The Z Garbage Collector）是JDK 11中推出的一款低延迟垃圾回收器，它的设计目标包括： 停顿时间不超过10ms； 停顿时间不会随着堆的大小，或者活跃对象的大小而增加； 支持8MB~4TB级别的堆（未来支持16TB）。 从设计目标来看，我们知道ZGC适用于大内存低延迟服务的内存管理和回收。本文主要介绍ZGC在低延时场景中的应用和卓越表现，文章内容主要分为四部分： GC之痛 ：介绍实际业务中遇到的GC痛点，并分析CMS收集器和G1收集器停顿时间瓶颈； ZGC原理 ：分析ZGC停顿时间比G1或CMS更短的本质原因，以及背后的技术原理； ZGC调优实践 ：重点分享对ZGC调优的理解，并分析若干个实际调优案例； 升级ZGC效果 ：展示在生产环境应用ZGC取得的效果。 GC之痛 很多低延迟高可用Java服务的系统可用性经常受GC停顿的困扰。GC停顿指垃圾回收期间STW（Stop The World），当STW时

1. 背景 命名实体识别（Named Entity Recognition，简称NER），又称作“专名识别”，是指识别文本中具有特定意义的实体，主要包括人名、地名、机构名、专有名词等。NER是信息提取、问答系统、句法分析、机器翻译、面向Semantic Web的元数据标注等应用领域的重要基础工具，在自然语言处理技术走向实用化的过程中占有重要的地位。在美团搜索场景下，NER是深度查询理解（Deep Query Understanding，简称 DQU）的底层基础信号，主要应用于搜索召回、用户意图识别、实体链接等环节，NER信号的质量，直接影响到用户的搜索体验。 下面将简述一下实体识别在搜索召回中的应用。在O2O搜索中，对商家POI的描述是商家名称、地址、品类等多个互相之间相关性并不高的文本域。如果对O2O搜索引擎也采用全部文本域命中求交的方式，就可能会产生大量的误召回。我们的解决方法如下图1所示，让特定的查询只在特定的文本域做倒排检索，我们称之为“结构化召回”，可保证召回商家的强相关性。举例来说，对于“海底捞”这样的请求，有些商家地址会描述为“海底捞附近几百米”，若采用全文本域检索这些商家就会被召回，显然这并不是用户想要的。而结构化召回基于NER将“海底捞”识别为商家，然后只在商家名相关文本域检索，从而只召回海底捞品牌商家，精准地满足了用户需求。 有别于其他应用场景

KV 存储作为美团一项重要的在线存储服务，承载了在线服务每天万亿级的请求量。在 2019 年 QCon 全球软件开发大会（上海站）上，美团高级技术专家齐泽斌分享了《美团点评万亿级 KV 存储架构与实践》，本文系演讲内容的整理，主要分为四个部分：第一部分讲述了美团 KV 存储的发展历程；第二部分阐述了内存 KV Squirrel 架构和实践；第三部分介绍了持久化 KV Cellar 架构和实践；最后分享了未来的发展规划和业界新趋势。 美团点评 KV 存储发展历程 美团第一代的分布式 KV 存储如下图左侧的架构所示，相信很多公司都经历过这个阶段。在客户端内做一致性哈希，在后端部署很多的 Memcached 实例，这样就实现了最基本的 KV 存储分布式设计。但这样的设计存在很明显的问题：比如在宕机摘除节点时，会丢数据，缓存空间不够需要扩容，一致性哈希也会丢失一些数据等等，这样会给业务开发带来的很多困扰。 随着 Redis 项目的成熟，美团也引入了 Redis 来解决我们上面提到的问题，进而演进出来如上图右侧这样一个架构。大家可以看到，客户端还是一样，采用了一致性哈希算法，服务器端变成了 Redis 组成的主从结构。当任何一个节点宕机，我们可以通过 Redis 哨兵完成 Failover，实现高可用。但有一个问题还是没有解决，如果扩缩容的话，一致性哈希仍然会丢数据，那么这个问题该如何解决呢

为进一步优化美团搜索排序结果的深度语义相关性，提升用户体验，搜索与NLP部算法团队从2019年底开始基于BERT优化美团搜索排序相关性，经过三个月的算法迭代优化，离线和线上效果均取得一定进展。本文主要介绍探索过程以及实践经验。 引言 美团搜索是美团App上最大的连接人和服务的入口，覆盖了团购、外卖、电影、酒店、买菜等各种生活服务。随着用户量快速增长，越来越多的用户在不同场景下都会通过搜索来获取自己想要的服务。理解用户Query，将用户最想要的结果排在靠前的位置，是搜索引擎最核心的两大步骤。但是，用户输入的Query多种多样，既有商户名称和服务品类的Query，也有商户别名和地址等长尾的Query，准确刻画Query与Doc之间的深度语义相关性至关重要。基于Term匹配的传统相关性特征可以较好地判断Query和候选Doc的字面相关性，但在字面相差较大时，则难以刻画出两者的相关性，比如Query和Doc分别为“英语辅导”和“新东方”时两者的语义是相关的，使用传统方法得到的Query-Doc相关性却不一致。 2018年底，以Google BERT[1]为代表的预训练语言模型刷新了多项NLP任务的最好水平，开创了NLP研究的新范式：即先基于大量无监督语料进行语言模型预训练（Pre-training），再使用少量标注语料进行微调（Fine-tuning）来完成下游的NLP任务（文本分类

| A consistent experience is a better experience.——Mark Eberman | 一致的体验是更好的体验。——Mark Eberman 《摘自设计师的16句名言》 背景 1.UI一致性项目 积木（Tangram）Sketch插件源于美团外卖UI的一致性项目，该项目自2019年5月份被提出，是UI设计团队与研发团队共建的项目，目的是改善用户端体验的一致性，提升多技术方案间组件的通用性和复用率，整体降低视觉改版的研发成本。 一直以来，外卖业务都处于高速发展阶段，人员规模在不断扩大，项目复杂度在持续增加。目前平台承载了美团餐饮、商超、闪购、跑腿、药品等多个业务品类，用户入口也覆盖了美团App外卖频道、外卖App、大众点评等多个独立应用。因为客户端一直比较侧重业务开发，为了满足业务快速上线的需求，UI组件并没有统一的实现，而是分散到各个业务场景中，在开发过程中因UI缺乏同一的标准而导致以下问题不断凸显： UI/UE层面 ① UI缺乏标准化的设计规范，在不同App及不同语言平台上设计风格不统一，用户体验不一致。 ② 设计资源与代码均缺乏统一的管理手段，无法实现积累沉淀，无法适应新业务的开发需求。 RD层面 ① 组件代码实现碎片化，存在多次开发的情况，质量难以得到保证。 ② 各端代码API不统一，维护拓展成本较高，变更主题、适配Dark

巡检工作是保障系统平稳有效运行必不可少的一个环节，目的是能及时发现系统中存在的隐患。我们生活中也随处可见各种巡检，比如电力巡检、消防检查等，正是这些巡检工作，我们才能在稳定的环境下进行工作、生活。巡检对于数据库或者其他IT系统来说也同样至关重要，特别是在降低风险、提高服务稳定性方面起到了非常关键作用。 本文介绍了美团MySQL数据库巡检系统的框架和巡检内容，希望能够帮助大家了解什么是数据库巡检，美团的巡检系统架构是如何设计的，以及巡检系统是如何保障MySQL服务稳定运行的。 一、背景 为了保障数据库的稳定运行，以下核心功能组件必不可少： 其中，数据库巡检作为运维保障体系最重要的环节之一，能够帮助我们发现数据库存在的隐患，提前治理，做到防患于未然。对于大规模集群而言，灵活健壮的自动化巡检能力，至关重要。 任何系统都会经历一个原始的阶段，最早的巡检是由中控机+定时巡检脚本+前端展示构成的。但是，随着时间的推移，老巡检方案逐渐暴露出了一些问题： 巡检定时任务执行依赖中控机，存在单点问题； 巡检结果分散在不同的库表，无法进行统计； 巡检脚本没有统一开发标准，不能保证执行的成功率； 每个巡检项都需要单独写接口取数据，并修改前端用于巡检结果展示，比较繁琐； 巡检发现的隐患需要DBA主动打开前端查看，再进行处理，影响整体隐患的治理速度； ...... 所以我们需要一个灵活

背景 某天晚上，美团到店事业群某项系统服务正在进行常规需求的上线。因为在内部的Plus系统发布时，提示inf-bom版本需要升级，于是我们就将inf-bom版本从1.3.9.6 升级至1.4.2.1，如下图1所示： 不过，当服务上线后，开始陆续出现了一些更新系统交互日志方面的报警，这属于系统的辅助流程，报警如下方代码所示。我们发现都是跟MyBatis相关的报警，说明在进行类型转换的时候，系统产生了强转错误。 更新开票请求返回日志, id:{#######}, response:{{"code":XXX,"data":{"callType":3,"code":XXX,"msg":"XXXX","shopId":XXXXX,"taxPlateDockType":"XXXXXXX"},"msg":"XXXXX","success":XXXX}} nested execption is org.apache.ibatis.type.TypeException: Could not set parameters for mapping: ParameterMapping{property='updateTime', mode=IN, javaType=class java.lang.String, jdbcTyp=null,resultMapId='null',jdbcTypeName=

前言 本文的文字及图片来源于网络,仅供学习、交流使用,不具有任何商业用途,版权归原作者所有,如有问题请及时联系我们以作处理。 作者：Britain_King 1.分析美团美食网页的url参数构成 1）搜索要点 美团美食，地址：北京，搜索关键词：火锅 2）爬取的url https://bj.meituan.com/s/%E7%81%AB%E9%94%85/ 3）说明 url会有自动编码中文功能。所以火锅二字指的就是这一串我们不认识的代码%E7%81%AB%E9%94%85。 通过关键词城市的url构造，解析当前url中的bj=北京，/s/后面跟搜索关键词。 这样我们就可以了解到当前url的构造。 2.分析页面数据来源(F12开发者工具) 开启F12开发者工具，并且刷新当前页面：可以看到切换到第二页时候，我们的url没有变化，网站也没有自动进行刷新跳转操作。(web中ajax技术就是在保证页面不刷新，url不变化情况下进行数据加载的技术) 此时我们需要在开发者工具中，找到xhr里面对应当前数据的响应文件。 分析到这里可以得知：我们的数据是以json格式交互。分析第二页的json文件请求地址与第三页json文件的请求地址。 第二页：https://apimobile.meituan.com/group/v4/poi/pcsearch/1?uuid=xxx&userid=-1&limit

引言 Kafka中的Message是以topic为基本单位组织的，不同的topic之间是相互独立的。每个topic又可以分成几个不同的partition(每个topic有几个partition是在创建topic时指定的)，每个partition存储一部分Message。借用官方的一张图，可以直观地看到topic和partition的关系。 partition是以文件的形式存储在文件系统中，比如，创建了一个名为page_visits的topic，其有5个partition，那么在Kafka的数据目录中(由配置文件中的log.dirs指定的)中就有这样5个目录: page_visits-0， page_visits-1，page_visits-2，page_visits-3，page_visits-4，其命名规则为<topic_name>-<partition_id>，里面存储的分别就是这5个partition的数据。 接下来，本文将分析partition目录中的文件的存储格式和相关的代码所在的位置。 Partition的数据文件 Partition中的每条Message由offset来表示它在这个partition中的偏移量，这个offset不是该Message在partition数据文件中的实际存储位置，而是逻辑上一个值，它唯一确定了partition中的一条Message。因此

主要内容： 　　一、基础爬虫框架的三大模块 　　二、完整代码解析及效果展示 1️⃣ 基础爬虫框架的三大模块 　　1、HTML下载器：利用requests模块下载HTML网页。 　　2、HTML解析器：利用re正则表达式解析出有效的数据。 　　3、数据存储器：将有效数据通过文件或者数据库的形式存储起来。 2️⃣ 完整代码解析和效果展示 　　一、声明编码并导入需要用到的模块 # ！/user/bin/env python3 # -*- coding:utf-8-*- # write by congcong import requests from requests.exceptions import RequestException import re #正则表达式 import json from multiprocessing import Pool # 多线程 　　二、构造HTML下载器 # 通过设置User Agent的来达到隐藏身份的目的，User-Agent的中文名为用户代理，简称UA。 User Agent存放于Headers中，服务器就是通过查看Headers中的User Agent来判断是谁在访问。在Python中，如果不设置User Agent，程序将使用默认的参数，那么这个User Agent就会有Python的字样，如果服务器检查User Agent