函数式编程是一种历史悠久的编程范式。作为演算法，它的历史可以追溯到现代计算机诞生之前的λ演算，本文希望带大家快速了解函数式编程的历史、基础技术、重要特性和实践法则。在内容层面，主要使用JavaScript语言来描述函数式编程的特性，并以演算规则、语言特性、范式特性、副作用处理等方面作为切入点，通过大量演示示例来讲解这种编程范式。同时，文末列举比较一些此范式的优缺点，供读者参考。因为文章涵盖一些范畴论知识，可能需要其他参考资料一起辅助阅读。 ...继续阅读 (85)

函数式编程是一种历史悠久的编程范式。作为演算法，它的历史可以追溯到现代计算机诞生之前的λ演算，本文希望带大家快速了解函数式编程的历史、基础技术、重要特性和实践法则。在内容层面，主要使用JavaScript语言来描述函数式编程的特性，并以演算规则、语言特性、范式特性、副作用处理等方面作为切入点，通过大量演示示例来讲解这种编程范式。同时，文末列举比较一些此范式的优缺点，供读者参考。因为文章涵盖一些范畴论知识，可能需要其他参考资料一起辅助阅读。 ...继续阅读 (89)

Hyperloop 是什么？Hyperloop 是服务于美团点评客户端的组件发版、持续集成、App 打包构建、资源调度等各个环节的发布调度系统。名称起源于美国 Elon Musk 构想的Hyperloop 超级高铁，象征着现代、简洁、高效。Hyperloop 提供了一站式的平台，管理着美团点评 iOS 业务的超过 300 个组件和包括美团 iOS 客户端在内的4个App。接入 Hyperloop 系统后，开发同学可以通过 Hyperloop 来管理自己的项目，配置发版和打包所需要的步骤和检查项。开发完成时，用户只需要登录 Hyperloop 进行相关操作，Hyperloop 就会根据项目的配置去调用不同的步骤，上报每个步骤的状态，给出错误日志、状态通知等。为什么要有 Hyperloop？说到发布，我们首先想到的就是持续集成和交付，而说到持续集成和交付，我们又会自然而然地想到 Jenkins。没错，我们之前的所有和发布工程相关的流程都是与 Jenkins 密切相关，其任务的调度、自动化的构建等功能深受我们的喜爱。可是随着我们的业务爆发式的增长，加之对 Jenkins 的深入使用，一些问题逐渐暴露出来了：1. 使用和维护成本加大业务量的增多，导致参与到整个发布流程中的同学也越来越多，而因为 Jenkins 偏向于专业的配置和运维步骤，给我们普通的开发同学带来很多 Jenkins 的使用 ...继续阅读 (94)

在美团点评酒旅事业群内，业务由传统的团购形式转向预订、直连等更加丰富的产品形式，业务系统也在迅速的迭代变化，这些都对数据仓库的扩展性、稳定性、易用性提出了更高要求。对此，我们采取了分层次、分主题的方式，本文将分享这一过程中的一些经验。技术架构随着美团点评整体的系统架构调整，我们在分层次建设数据仓库的过程中，不断优化并调整我们的层次结构，下图展示了技术架构的变迁。我们把它们简称为三代数仓模型层次。在第一代数仓模型层次中，由于当时美团整体的业务系统所支持的产品形式比较单一（团购），业务系统中包含了所有业务品类的数据，所以由平台的角色来加工数据仓库基础层是非常合适的，平台统一建设，支持各个业务线使用，所以在本阶段中我们酒旅只是建立了一个相对比较简单的数据集市。但随着美团原本集中的业务系统不能快速响应各个业务线迅速的发展与业务变化时，酒旅中的酒店业务线开始有了自己的业务系统来支持预订、房惠、团购、直连等产品形式，境内度假业务线也开始有了自己的业务系统来支持门票预订、门票直连、跟团游等复杂业务。我们开始了第二代数仓模型层次的建设，由建设数据集市的形式转变成了直接建设酒旅数据仓库，成为了酒旅自身业务系统数据的唯一加工者。由于系统调整初期给我们带来的重构、修改以及新增等数据处理工作非常大，我们采用了比较短平快的Kimball所提的维度建模的方式建设了酒旅数据仓库。在第二代数仓模型层次运转一段时间 ...继续阅读 (83)

背景计算机硬件性能在过去十年间的发展普遍遵循摩尔定律，通用计算机的CPU主频早已超过3GHz，内存也进入了普及DDR4的时代。然而传统硬盘虽然在存储容量上增长迅速，但是在读写性能上并无明显提升，同时SSD硬盘价格高昂，不能在短时间内完全替代传统硬盘。传统磁盘的I/O读写速度成为了计算机系统性能提高的瓶颈，制约了计算机整体性能的发展。硬盘性能的制约因素是什么？如何根据磁盘I/O特性来进行系统设计？针对这些问题，本文将介绍硬盘的物理结构和性能指标，以及操作系统针对磁盘性能所做的优化，最后讨论下基于磁盘I/O特性设计的技巧。硬盘的物理结构硬盘内部主要部件为磁盘盘片、传动手臂、读写磁头和主轴马达。实际数据都是写在盘片上，读写主要是通过传动手臂上的读写磁头来完成。实际运行时，主轴让磁盘盘片转动，然后传动手臂可伸展让读取头在盘片上进行读写操作。磁盘物理结构如下图所示：由于单一盘片容量有限，一般硬盘都有两张以上的盘片，每个盘片有两面，都可记录信息，所以一张盘片对应着两个磁头。盘片被分为许多扇形的区域，每个区域叫一个扇区，硬盘中每个扇区的大小固定为512字节。盘片表面上以盘片中心为圆心，不同半径的同心圆称为磁道，不同盘片相同半径的磁道所组成的圆柱称为柱面。磁道与柱面都是表示不同半径的圆，在许多场合，磁道和柱面可以互换使用。磁盘盘片垂直视角如下图所示：早期的硬盘每磁道扇区数相同，此时由磁盘基本参数可 ...继续阅读 (88)

本文已被USENIX'17年度技术大会录用，此处为中文简译版。阅读英文论文完整版请点击：Speculative Partial Writes in Erasure-Coded Systems前言多副本和纠删码（EC，Erasure Code）是存储系统中常见的两种数据可靠性方法。与多副本冗余不同，EC将m个原始数据块编码生成k个检验块，形成一个EC组，之后系统可最多容忍任意k个原始数据块或校验块损坏，都不会产生数据丢失。纠删码可将数据存储的冗余度降低50%以上，大大降低了存储成本，在许多大规模分布式存储系统中已得到实际应用。EC给写操作带来了很大的额外开销，包括编解码计算开销和流程性开销两部分。在向量指令集SSE、AVX等的帮助下，一个现代CPU核心的EC编解码能力就可以达到几GB到十几GB每秒，远远大于存储设备的I/O吞吐率。这使得流程性开销成为EC写入性能的最重要制约因素。若一次写操作的偏移和长度没有对齐EC组，就需要部分更新涉及的EC组，因而将此类操作称为部分写。部分写带来了大部分的流程性开销。处理部分写的最直接办法是将不被写的数据块读出来，跟新数据组合在一起，然后再整体编码并写入。目前Ceph、Sheepdog等系统都采用了这种办法。一种简单有效的改进是将被覆盖数据的原始值读出来，然后根据新旧数据的差值来进行增量编码，得到各个校验块的差值，并“加”到各个校验块上。这种方法可 ...继续阅读 (91)

本文是美团点评基础架构系列文章之一。这个系列将全面介绍支撑数亿用户、超千万日订单的美团点评平台诸多业务的公共基础架构相关技术。系列已经发布的文章包括：《分布式会话跟踪系统架构设计与实践》《Leaf——美团点评分布式ID生成系统》《深度剖析开源分布式监控CAT》背景美团点评作为国内最大的O2O平台，业务热度的高峰低谷非常显著且规律，如果遇到节假日或促销活动，流量还会在短时间内出现成倍的增长。过去传统虚拟机的服务运行及部署机制在应对服务快速扩容、缩容需求中存在诸多不足：资源实例创建慢，需要预先安装好运行所需的环境，比如JDK等。扩容后的实例，需要经过代码部署流程，一些情况下还需要修改配置后才能承接流量。资源申请容易回收难，促销活动后做相关资源的回收下线会比较漫长。由于业务存在典型的高峰低谷，为保障业务稳定，资源实例数要保障能抗高峰期容量峰值的1-2倍，从而导致非高峰期资源大量闲置，整体利用效率低。注意到上面这些问题后，我们经过调研与测试，结合业界的实践经验，决定基于Docker容器技术来实现服务的弹性伸缩，有效应对快速扩缩容需求、提升资源利用效率。Docker容器技术也是一类虚拟化技术，不同于虚拟机的硬件虚拟化，容器是基于操作系统内核的隔离机制实现。容器省去了模拟底层硬件、指令等操作，直接基于宿主机内核，并隔离出独立的系统环境、加以资源限制，能有效提升启动速度和性能。HULK容器平台简 ...继续阅读 (94)

前端技术体系的范围和作用随着科技的发展，终端种类越来越丰富，前端作为连接用户终端与后端服务、提供视觉体验的关键环节，发展迅速。相比十年前，前端的边界和范围变得更加广泛，甚至有点模糊，一名优秀的前端工程师不仅需要精通自己的专业领域，了解设备终端的特点、OS、运行环境，同时还需要具备良好的审美和对用户体验的感觉，以及了解服务部署、服务运维的知识。前端的知识领域也从最初的单点，扩展到了现在的网状结构；开发方式也从最初的页面级开发，发展到现在工程级的开发协作方式。技术体系归根结底是围绕业务发展、团队规模和团队特点量身打造的，主要目的是为了提升团队整体的研发效率，确保线上的质量和稳定性。结合前端研发的特点，一个完备的技术体系应当包括流程规范（涵盖开发、构建、部署、运行各个阶段），技术工具栈（技术选型和基础工具设施），构建工具栈，自动化测试，部署流程和部署平台，监控体系（错误监控、性能监控、业务监控、服务监控）。酒旅前端团队的技术体系以上是美团点评酒旅前端团队的技术体系结构图，我们有两种共存的项目类型（静态化项目和服务端项目），不同类型的项目技术工具栈和部署平台略有不同，静态化项目是通过CDN进行承载，前端使用轻量级的MVVM框架Vue进行功能开发，同时借助移动端样式组件库提升开发效率，通过离线包机制和KNB（Native Bridge）增强页面在容器内的表达能力，最后通过AWP（自建的静态化 ...继续阅读 (82)

本文根据美团点评算法工程师胡淏4月22日在“携程技术沙龙”上的分享整理而成。文字综合了“携程技术中心”微信公众号的版本和胡淏本人在微博上发表的文章，并有少量编辑加工。图1 机器学习工程师的知识图谱图1列出了我认为一个成功的机器学习工程师需要关注和积累的点。机器学习实践中，我们平时都在积累自己的“弹药库”：分类、回归、无监督模型、Kaggle上面特征变换的黑魔法、样本失衡的处理方法、缺失值填充……这些大概可以归类成模型和特征两个点。我们需要参考成熟的做法、论文，并自己实现，此外还需要多反思自己方法上是否还可以改进。如果模型和特征这两个点都已经做得很好了，你就拥有了一张绿卡，能跨过在数据相关行业发挥模型技术价值的准入门槛。在这个时候，比较关键的一步，就是高效的技术变现能力。所谓高效，就是解决业务核心问题的专业能力。本文将描述这些专业能力，也就是模型优化的四个要素：模型、数据、特征、业务，还有更重要的，就是它们在模型项目中的优先级。模型项目推进的四要素项目推进过程中，四个要素相互之间的优先级大致是：业务>特征>数据>模型。图2 四要素解决问题细分+优先级业务一个模型项目有好的技术选型、完备的特征体系、高质量的数据一定是很加分的，不过真正决定项目好与坏还有一个大前提，就是这个项目的技术目标是否在解决当下核心业务问题。业务问题包含两个方面：业务KPI和deadline。举个例子，业务问题是在 ...继续阅读 (114)

前言近年来，在线广告在整个广告行业的比重越来越高。在线广告中实时竞价的广告由于其良好的转化效果，占有的比重逐年升高。DSP（Demand-Side Platform）[1]作为需求方平台，通过广告交易平台（AdExchange）[2]对每次曝光进行竞价尝试。对于AdExchange的每次竞价请求，DSP根据Cookie Mapping[3]或者设备信息，尝试把正在浏览媒体网站、App的用户映射到DSP能够识别的用户，然后根据DSP从用户历史行为中挖掘的用户画像，进行流量筛选、点击率/转化率预估等，致力于ROI[4]的最大化。美团点评的用户量越来越大，积累了大量的用户在站内的行为信息，我们基于这些行为构造了精准的用户画像，并在此基础上针对美团App和网站的用户搭建了美团DSP平台，致力于获取站外优质的流量，为公司带来效益。本文从策略角度描述一下在搭建DSP过程中的考虑、权衡及对未来的思考。在DSP实时竞价过程中，策略端都在哪些步骤起作用；对每一个步骤的尝试和优化方向做出详细介绍；总结DSP如何通过AB测试、用户行为反馈收集、模型迭代、指导出价/排序等步骤来打通整个DSP实时竞价广告闭环。竞价展示流程美团DSP在一次完整的竞价展示过程中可能涉及到两个大的步骤：对AdExchange的竞价请求实时竞价；竞价成功之后用户点击进入二跳页、浏览、点击、最后转化。我们分别看一下这两个步骤中策略的 ...继续阅读 (83)

背景犀牛云盘是美团点评内部一个基于美团云的文件协作平台，核心是文件的结构化云存储以及上传和下载的体验优化。文件同步是云盘功能的重要部分（包括文件内容的同步和文件增删的同步，应该有上传、下载、创建、删除等动作，但在本文的叙述中，主要关注文件内容的传输，即上传、下载），如何快速高效地进行文件同步，就成了云盘亟需解决的技术难题。本文阐述的方案就是在这种场景下提出来的，我们希望通过rsync增量传输算法，来提高文件同步速度。但原始rsync算法在高并发的服务上会存在性能问题，所以本方案也借鉴zsync的思路，做了优化。rsync增量传输算法rsync增量传输算法首度发表于1996年6月19日，原始作者为Andrew Tridgell与Paul Mackerras [1]。实现增量传输的主要过程，就是差异检测和差异数据组织及传输，前者是rsync增量传输算法的核心。rsync增量传输算法是一种滑动块差异检测算法。以检测文件A和B的差异为例，首先对A按固定长度L划分为若干块，并对每一块生成弱摘要（Adler-32：速度快）和强摘要（MD5：鉴别度高），然后对B从第一个字节开始，以长度为L的滑动窗口，遍历整个文件，计算每个窗口块的弱、强摘要，并与A中的摘要值进行比较，弱、强摘要都相同者，即视为相同数据块，否即为差异块。如下图所示：rsync增量传输算法主要有两个特点：固定块摘要和滑动块检测 ...继续阅读 (121)

Vuex是一个专为Vue服务，用于管理页面数据状态、提供统一数据操作的生态系统。它集中于MVC模式中的Model层，规定所有的数据操作必须通过action - mutation - state change的流程来进行，再结合Vue的数据视图双向绑定特性来实现页面的展示更新。统一的页面状态管理以及操作处理，可以让复杂的组件交互变得简单清晰，同时可在调试模式下进行时光机般的倒退前进操作，查看数据改变过程，使code debug更加方便。最近在开发的项目中用到了Vuex来管理整体页面状态，遇到了很多问题。决定研究下源码，在答疑解惑之外，能深入学习其实现原理。先将问题抛出来，使学习和研究更有针对性：使用Vuex只需执行Vue.use(Vuex)，并在Vue的配置中传入一个store对象的示例，store是如何实现注入的？state内部是如何实现支持模块配置和模块嵌套的？在执行dispatch触发action（commit同理）的时候，只需传入（type, payload），action执行函数中第一个参数store从哪里获取的？如何区分state是外部直接修改，还是通过mutation方法修改的？调试时的“时空穿梭”功能是如何实现的？注：本文对有Vuex有实际使用经验的同学帮助更大，能更清晰理解Vuex的工作流程和原理，使用起来更得心应手。初次接触的同学，可以先参考Vuex官方文档进行基 ...继续阅读 (104)

背景在复杂分布式系统中，往往需要对大量的数据和消息进行唯一标识。如在美团点评的金融、支付、餐饮、酒店、猫眼电影等产品的系统中，数据日渐增长，对数据分库分表后需要有一个唯一ID来标识一条数据或消息，数据库的自增ID显然不能满足需求；特别一点的如订单、骑手、优惠券也都需要有唯一ID做标识。此时一个能够生成全局唯一ID的系统是非常必要的。概括下来，那业务系统对ID号的要求有哪些呢？全局唯一性：不能出现重复的ID号，既然是唯一标识，这是最基本的要求。趋势递增：在MySQL InnoDB引擎中使用的是聚集索引，由于多数RDBMS使用B-tree的数据结构来存储索引数据，在主键的选择上面我们应该尽量使用有序的主键保证写入性能。单调递增：保证下一个ID一定大于上一个ID，例如事务版本号、IM增量消息、排序等特殊需求。信息安全：如果ID是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定URL即可；如果是订单号就更危险了，竞对可以直接知道我们一天的单量。所以在一些应用场景下，会需要ID无规则、不规则。上述123对应三类不同的场景，3和4需求还是互斥的，无法使用同一个方案满足。同时除了对ID号码自身的要求，业务还对ID号生成系统的可用性要求极高，想象一下，如果ID生成系统瘫痪，整个美团点评支付、优惠券发券、骑手派单等关键动作都无法执行，这就会带来一场灾难。由此总结下一个ID生成系统应该做 ...继续阅读 (107)

一、前言外卖业务的快速发展对系统稳定性提出了更高的要求，每一次订单量大盘的异常波动，都需要做出及时的应对，以保证系统的整体稳定性。如何做出较为准确的波动预警，显得尤为重要。从时间上看，外卖订单量时间序列有两个明显的特征（如下图所示）：周期性。每天订单量的变化趋势都大致相同，午高峰和晚高峰订单量集中。实时性。当天的订单量可能会受天气等因素影响，呈现整体的上涨或下降。订单量波动预警，初期外卖订单中心使用的是当前时刻和前一时刻订单量比较，超过一定阈值就报警的方式，误报率和漏报率都比较大。后期将业务数据上传到美团点评的服务治理平台，使用该平台下的基线报警模型进行监控报警。基线数据模型考虑到了订单量时间序列的周期性特征，但是忽略了实时性特征，在实际使用中误报率依然很高，大量的误报漏报导致RD对于报警已经麻木，出现问题时不能及时响应，因此，急需一种新的异常检测模型，提高报警的准确率。图1.1 外卖订单大盘趋势图二、异常检测的定义异常，意为“异于正常”。异常检测，就是从一组数据中寻找那些和期望数据不同的数据。监控数据都是和时间相关的，每一个监控指标只有和时间组合一起才有其具体的含义。按照时间顺序，将监控指标组成一个序列，我们就得到了监控指标的时间序列。基于预测的异常检测模型如下图所示，xt是真实数据，通过预测器得到预测数据，然后xt和pt分别作为比较器的输入，最终得到输出yt。yt是一个二元值， ...继续阅读 (116)

一、背景2015年10月，经过一段时间的优化与改进，美团点评HDFS集群稳定性和性能有显著提升，保证了业务数据存储量和计算量爆发式增长下的存储服务质量；然而，随着集群规模的发展，单组NameNode组成的集群也产生了新的瓶颈：扩展性：根据HDFS NameNode内存全景和HDFS NameNode内存详解这两篇文章的说明可知，NameNode内存使用和元数据量正相关。180GB堆内存配置下，元数据量红线约为7亿，而随着集群规模和业务的发展，即使经过小文件合并与数据压缩，仍然无法阻止元数据量逐渐接近红线。可用性：随着元数据量越来越接近7亿，CMS GC频率也越来越高，期间也曾发生过一次在CMS GC过程中由于大文件getBlocklocation并发过高导致的promotion fail。性能：随着业务的发展，集群规模接近2000台，NameNode响应的RPC QPS也在逐渐提高。越来越高并发的读写，与NameNode的粗粒度元数据锁，使NameNode RPC响应延迟和平均RPC队列长度都在慢慢提高。隔离性：由于NameNode没有隔离性设计，单一对NameNode负载过高的应用，会影响到整个集群的服务能力。HDFS Federation是Hadoop-0.23.0中为解决HDFS单点故障而提出的NameNode水平扩展方案。该方案可以为HDFS服务创建多个namespace， ...继续阅读 (99)

在Android（Java）开发中，基本都会遇到java.lang.OutOfMemoryError（本文简称OOM），这种错误解决起来相对于一般的Exception或者Error都要难一些，主要是由于错误产生的root cause不是很显而易见。由于没有办法能够直接拿到用户的内存dump文件，如果错误发生在线上的版本，分析起来就会更加困难。本文从一个具体的案例切入，介绍OOM分析的思路及相关工具的使用。案例背景在美团App 7.4~7.7版本期间，美食业务的OOM数量居高不下，远高于历史水平，主要都是DECODE本地的资源出错。图中OOM数量为各版本发版后第一个月的统计量，包含新发版本及历史版本。对比了同时期其他业务的情况，也有类似OOM。由于美食业务的访问量占美团App的比重较大，因此，OOM的数量相对其他业务也多一些。思路方案在问题较为严重的7.6~7.7版本期间，团队对OOM频现的原因有过各种猜测。笔者怀疑过是否是业务上某些修改引起的，例如头图尺寸变大，或者是由页面模块加载方式引起的等等。但这些与OOM问题出现的时间并不吻合。其次也怀疑过是否由某些ROM的Bug导致，但此推断缺乏有力的证据支撑。因此，要找到OOM的root cause，根本途径还是找到谁占的内存最多，然后再根据具体case具体分析，为什么占了这么多。采集用户手机内存信息要分析内存的占用，需要内存的dump文 ...继续阅读 (123)

随着业务的快速迭代增长，美团App里不断引入新的业务逻辑代码、图片资源和第三方SDK，直接导致APK体积不断增长。包体积增长带来的问题越来越多，如CDN流量费用增加、用户安装成功率降低，甚至可能会影响用户的留存率。APK的瘦身已经是不得不考虑的事情。在尝试瘦身的过程中，我们借鉴了很多业界其他公司提供的方案，同时也针对自身特点，发现了一些新的技巧。本文将对其中的一些做详细介绍。在开始讲瘦身技巧之前，先来讲一下APK的构成。APK的构成可以用Zip工具打开APK查看。比如，美团App 7.8.6的线上版本的格式是这样的：可以看到APK由以下主要部分组成：文件/目录描述lib/存放so文件，可能会有armeabi、armeabi-v7a、arm64-v8a、x86、x86_64、mips，大多数情况下只需要支持armabi与x86的架构即可，如果非必需，可以考虑拿掉x86的部分res/存放编译后的资源文件，例如：drawable、layout等等assets/应用程序的资源，应用程序可以使用AssetManager来检索该资源META-INF/该文件夹一般存放于已经签名的APK中，它包含了APK中所有文件的签名摘要等信息classes(n).dexclasses文件是Java Class，被DEX编译后可供Dalvik/ART虚拟机所理解的文件格式resources.arsc编译后的二进 ...继续阅读 (95)

前不久Google发布了一份安全方面的白皮书Google Infrastructure Security Design Overview，直译的版本可以参考“网路冷眼”这版《Google基础设施安全设计概述》，直译+点评的版本可以参考“职业欠钱”的《Google基础设施安全设计概述翻译和导读》。此前Google在安全领域披露的信息一直很少，适逢其大力发展云计算业务，需要展示云安全方面的实力，才有了这份白皮书。它从系统的角度描述了自己安全体系的设计与实现，对广大互联网、云计算公司的安全小伙伴而言可谓一大福利。本文中，笔者将从一个企业安全建设者的角度，说说自己的感想，并做一些解读。几点感想国内很多公司的安全团队都是游离在产品研发、基础架构和SRE团队之外的，HIDS、WAF、大数据的SOC，说到底这些东西安全团队自己就可以搞定，基本不需要其他部门的支援和介入，这和乙方安全公司提供的一套外科手术般的解决方案的思路是一脉相承的。而Google的安全体系给人的感觉是跟基础设施深度融合，完全内置于产品设计和研发过程之中，从顶层设计的视角看完全是两种流派：内置的安全机制vs外挂的防护体系。没有业界安全大会上那些花俏的概念和名词，全都是正统的安全设计思路，以既有的简单的安全手段解决复杂的问题，有如教科书般的绅士风格。工程化大于单点技术突破。尽管Google有Project Zero、有不少牛人，不 ...继续阅读 (90)

背景度假业务在整个在线旅游市场中占据着非常重要的位置，如何做好做大这块蛋糕是行业内的焦点。与美食或酒店的用户兴趣点明确（比如找某个确定的餐厅或者找某个目的地附近的酒店）不同，旅游场景中的用户兴趣点（比如周末去哪儿好玩）很难确定，而且会随着季节、天气、用户属性等变化而变化。这些特点导致传统的信息检索并不能很好的满足用户需求，我们迫切需要建设旅游推荐系统（本文中度假=旅游）。旅游推荐系统主要面临以下几点挑战：本异地差异大。在本地生活场景中用户需求绝大部分集中在本地，而在旅游场景中超过30%的订单来自于异地请求，即常驻城市为A的用户购买了城市B的旅游订单。外地人浏览北京时推荐故宫、长城没有问题，北京人浏览时推荐北京欢乐谷、野生动物园更为合适。推荐形式多样。除了景点推荐外，还有跟团游、景酒套餐的推荐。景点下有大量重复相似的门票，不适合按Deal（团购单）样式展示；跟团游、景酒套餐一般会绑定多个景点，又不适合按POI（门店）样式展现。季节性明显。比如，冬季温泉、滑雪比较热销，夏季更多人选择水上乐园。需求个性化。比如，亲子类用户和情侣类用户的需求会不太一样，进一步细分，1~4岁、6岁以上亲子类用户的需求也会有所差别。针对上述问题我们定制了一套完整的推荐系统框架，包括基于机器学习的召回排序策略，以及从海量大数据的离线计算到高并发在线服务的推荐引擎。策略迭代推荐系统的策略主要分为召回和排序两类，召 ...继续阅读 (101)

背景前端渲染有很多框架，而且形式和内容在不断发生变化。这些演变的背后是设计模式的变化，而归根到底是功能划分逻辑的演变：MVC—>MVP—>MVVM（忽略最早混在一起的写法，那不称为模式）。近几年兴起的React、Vue、Angular等框架都属于MVVM模式，能帮我们实现界面渲染、事件绑定、路由分发等复杂功能。但在一些只需完成数据和模板简单渲染的场合，它们就显得笨重而且学习成本较高了。例如，在美团外卖的开发实践中，前端经常从后端接口取得长串的数据，这些数据拥有相同的样式模板，前端需要将这些数据在同一个样式模板上做重复渲染操作。解决这个问题的模板引擎有很多，doT.js（出自女程序员Laura Doktorova之手）是其中非常优秀的一个。下表将doT.js与其他同类引擎做了对比：框架大小压缩版本大小迭代条件表达式自定义语法doT.js6KB4KB√√√mustache18.9 KB9.3 KB√×√Handlebars512KB62.3KB√√√artTemplate(腾讯)-5.2KB√√√BaiduTemplate(百度)9.45KB6KB√√√jQuery-tmpl18.6KB5.98KB√√√可以看出，doT.js表现突出。而且，它的性能也很优秀，本人在Mac Pro上的用Chrome浏览器（版本为：56.0.2924.87）上做100条数据10000次渲染性能测试，结果如 ...继续阅读 (101)

本文根据第16期美团点评技术沙龙“移动开发实践（上海站）”演讲内容整理而成。第18期沙龙：高可用系统背后的基础架构（3月25日）火热来袭！快快点击报名吧。为何要做网络优化网络优化对于App产品的用户体验至关重要，与公司的运营和营收息息相关。这里列举两个公开的数据：“页面加载超过3秒，57%的用户会离开。”“Amazon页面加载延长1秒，一年就会减少16亿美金营收。”在做网络优化前，我们首先要为网络通信质量设立一个标尺。在美团点评，监控团队开发了基于端到端的客户端监控平台。这里要先解释一下“端到端”的含义：是指请求从客户端发出到服务端响应返回的整个过程。它区别于后台服务监控，是一种从用户角度观察到的真实体验监控。监控页面如图所示：通过基于命令字的、多维度、实时的监控工具，可以及时发现线上问题。为了方便发现问题，我们在公司内统一了网络响应状态码的范围。通过状态码的分段范围，也可以迅速清晰地看到网络成败的原因和占比。有了监控工具后，我们来讨论：移动网络请求过程中，出现了哪些最常见的问题？首先是网络不可用的问题。主要由以下几种原因导致：GFW的拦截，原因你懂的。DNS的劫持，端口的意外封禁等。偏远地区网络基础设施比较差。其次是网络加载时间长。原因包括：移动设备出于省电的目的，发出网络请求前需要先预热通信芯片。网络请求需要跨网络运营商，物理路径长。HTTP请求是基于Socket设计的，请求发 ...继续阅读 (101)

我们在之前的博客文章中介绍了高兼容性、高稳定性的实时热更新解决方案Robust之后，业内反响强烈，不断有读者咨询我们什么时候开源。今天我们非常高兴地宣布，Robust已经开源啦！开源地址：https://github.com/Meituan-Dianping/Robust。Robust热更新系统借鉴Instant Run原理，实现了一个兼容性更强而且实时生效的热更新方案。其基本思路是，Robust热更新系统在一个方法的入口处插入一段跳转代码，当发现某个方法出现bug就跳转执行补丁中的代码，略过原有代码的执行，否则执行原有方法体逻辑。Robust凭借着自身的优势，已经在美团点评各个团队得到了快速普及。制作补丁的需求也随之越来越旺盛，人力手动制作补丁明显跟不上业务方的需求。虽然我们团队已经早早地开始自动化补丁的相关工作，但无奈自动化之路坑太多，一直都难以针对各种情况制作出可用的补丁。如何快速、稳定地生成补丁已经成为制约Robust热更新系统推广的瓶颈。在Robust推广的初期，补丁基本是手动生成，一个补丁的制作和测试经常需要一天的时间，大大降低了系统对线上问题的反应速度。如果能自动化补丁，补丁的生成就不再是瓶颈，只需要一次打包的时间就可以生成补丁。为此我们团队进行了不懈的努力，最终为Robust热更新系统提供了一个比较成熟的自动化生成补丁工具。最新的开源版本中，已经包含这部分工作。自动 ...继续阅读 (126)

本文已发表于InfoQ，下面的版本又经过少量修订。一、背景在Hadoop集群整个生命周期里，由于调整参数、Patch、升级等多种场景需要频繁操作NameNode重启，不论采用何种架构，重启期间集群整体存在可用性和可靠性的风险，所以优化NameNode重启非常关键。本文基于Hadoop-2.x和HA with QJM社区架构和系统设计（如图1所示），通过梳理NameNode重启流程，并在此基础上，阐述对NameNode重启优化实践。图1 HDFS HA with QJM架构图示二、NameNode重启流程在HDFS的整个运行期里，所有元数据均在NameNode的内存集中管理，但是由于内存易失特性，一旦出现进程退出、宕机等异常情况，所有元数据都会丢失，给整个系统的数据安全会造成不可恢复的灾难。为了更好的容错能力，NameNode会周期进行CheckPoint，将其中的一部分元数据（文件系统的目录树Namespace）刷到持久化设备上，即二进制文件FSImage，这样的话即使NameNode出现异常也能从持久化设备上恢复元数据，保证了数据的安全可靠。但是仅周期进行CheckPoint仍然无法保证所有数据的可靠，如前次CheckPoint之后写入的数据依然存在丢失的问题，所以将两次CheckPoint之间对Namespace写操作实时写入EditLog文件，通过这种方式可以保证HDFS元数 ...继续阅读 (97)

本文已发表于《程序员》杂志2017年第3期，下面的版本又经过进一步的修订。前言一般而言，现在互联网应用（网站或App）的整体流程，可以概括如图1所示，用户请求从界面（浏览器或App界面）到网络转发、应用服务再到存储（数据库或文件系统），然后返回到界面呈现内容。随着互联网的普及，内容信息越来越复杂，用户数和访问量越来越大，我们的应用需要支撑更多的并发量，同时我们的应用服务器和数据库服务器所做的计算也越来越多。但是往往我们的应用服务器资源是有限的，且技术变革是缓慢的，数据库每秒能接受的请求次数也是有限的（或者文件的读写也是有限的），如何能够有效利用有限的资源来提供尽可能大的吞吐量？一个有效的办法就是引入缓存，打破标准流程，每个环节中请求可以从缓存中直接获取目标数据并返回，从而减少计算量，有效提升响应速度，让有限的资源服务更多的用户。如图1所示，缓存的使用可以出现在1～4的各个环节中，每个环节的缓存方案与使用各有特点。图1 互联网应用一般流程缓存特征缓存也是一个数据模型对象，那么必然有它的一些特征：命中率命中率=返回正确结果数/请求缓存次数，命中率问题是缓存中的一个非常重要的问题，它是衡量缓存有效性的重要指标。命中率越高，表明缓存的使用率越高。最大元素（或最大空间）缓存中可以存放的最大元素的数量，一旦缓存中元素数量超过这个值（或者缓存数据所占空间超过其最大支持空间），那么将会触发缓存启动 ...继续阅读 (86)

1 简介乐高，是美团点评一个快速搭建后台系统页面的平台。名称来源于大家熟悉的丹麦知名玩具品牌，他们的玩具都是通过组合易拆卸、装配的零件，形成最终的作品。经过长期的发展，乐高品牌渐渐有了“快乐、想象、创意的未来”的寓意。随着外卖业务的高速发展，大量的业务开发需求接踵而来。像人手紧缺、重复开发、沟通效率低下等问题，暴露得愈发明显。于是，我们有了这么一个想法：能否基于现有大量业务系统的结构固定、需求紧急、交互样式要求不高等特点，搭建一个平台，它把已经成型的组件像乐高玩具的零件一样，使用拖拽的方式组装成最终的页面，同时能够让各个业务快速的接入。在美团点评一次黑客马拉松中，我们将这一想法付诸实践。在参赛的四十多支团队中，获得了第二名。这给了我们坚持下去的信心，也明确了后续努力的方向。经过一段时间的迭代，目前乐高形成了较完善的开发和生产流程：基于平台提供的标准，开发出独立的组件。组件经过不同形式的排列组合，形成最终的产品界面。2 用户使用乐高平台的应用可分为三大部分：面向用户的组装工厂、面向开发者的开发视图以及面向后端服务化的暴露接口。2.1 组装工厂2.1.1 视图布局页面组装如图一所示，主要包含五部分：组件树组件树是页面的骨架（①所示区域）部分，由内置的各个组件组装而成。乐高为组件树提供了丰富的操作（②右键弹框）选项。除了添加、拷贝粘贴、预览、删除等功能，还可以通过拖动组件在组件树中的位置 ...继续阅读 (101)

介绍在数据库运维过程中，优化 SQL 是 DBA 团队的日常任务。例行 SQL 优化，不仅可以提升程序性能，还能够降低线上故障的概率。目前常用的 SQL 优化方式包括但不限于：业务层优化、SQL逻辑优化、索引优化等。其中索引优化通常通过调整索引或新增索引从而达到 SQL 优化的目的。索引优化往往可以在短时间内产生非常巨大的效果。如果能够将索引优化转化成工具化、标准化的流程，减少人工介入的工作量，无疑会大大提高DBA的工作效率。SQLAdvisor 是由美团点评公司北京DBA团队开发维护的 SQL 优化工具：输入SQL，输出索引优化建议。 它基于 MySQL 原生词法解析，再结合 SQL 中的 where 条件以及字段选择度、聚合条件、多表 Join 关系等最终输出最优的索引优化建议。目前 SQLAdvisor 在公司内部大量使用，较为成熟、稳定。现在，我们非常高兴地将 SQLAdvisor 开源，项目 GitHub 地址：https://github.com/Meituan-Dianping/SQLAdvisor。我们已经把相关开发工作全面转到 GitHub 上，开源版本和内部使用版本保持完全一致。希望与业内有类似需求的团队，一起打造一款优秀的 SQL 优化产品。SQLAdvisor架构流程图：SQLAdvisor使用举例sql: SELECT id FROM crm_loan W ...继续阅读 (98)

上篇博客《Android自定义Lint实践》中我们介绍了美团App如何使用自定义Lint进行代码检查。在使用Lint的过程中，我们陆续又发现原生Lint的一些问题和缺陷，本文将介绍我们在实践中提出的解决方案。完善JDK 7泛型新写法下的HashMap检测上一篇博客中我们提到了对于HashMap检测的改进，但当时我们也在文章中提到：代码很简单，总体就是获取变量定义的地方，将泛型值传入原先的检测逻辑。当然这里的增强也是有局限的，比如这个变量是成员变量，向前的推断就会有问题，这点我们还在持续的优化中。即：当时的检测解决了变量声明和变量赋值在一起的HashMap检测问题。但对于两者不在一起的情况，我们仍然无法检测到。示例代码如下：publicstaticvoidtestHashMap(){//这种情况可以用上篇博客的检查搞定Mapmap1 =newHashMap(); map1.put(1,"name");//这种找不到map2的变量声明，所以用上篇博客的检查是无法判断的map2 =newHashMap(); map2.put(2,"name2"); }通过我们的探索，目前已经解决了这个问题。下面我们来详细介绍下：我们需要解决的情况在同一个类中publicMapmap;publicstaticMapmap2;publicvoidtest(){// 1: 成员变量map =n ...继续阅读 (103)

构建一个数据平台大体上包括数据采集、数据上报、数据存储、数据计算，以及数据的可视化展示等几个重要的环节。前端数据采集与上报是整个流程中最重要的一环，只有确保前端数据生产的全面、准确、及时，最终产生的数据结果才是可靠的、有价值的。为了解决前端埋点的准确性、及时性、开发效率等问题，业内各家公司从不同角度，提出了多种技术方案，这些方案大体上可以归为三类：第一类是代码埋点，即在需要埋点的节点调用接口直接上传埋点数据，友盟、百度统计等第三方数据统计服务商大都采用这种方案；第二类是可视化埋点，即通过可视化工具配置采集节点，在前端自动解析配置并上报埋点数据，从而实现所谓的“无痕埋点”， 代表方案是已经开源的Mixpanel；第三类是“无埋点”，它并不是真正的不需要埋点，而是前端自动采集全部事件并上报埋点数据，在后端数据计算时过滤出有用数据，代表方案是国内的GrowingIO。美团点评对于前端埋点的要求很高，总结起来主要有三点需求：第一是数据的准确性和及时性，数据质量的好坏将直接影响依赖埋点数据的后端策略服务、与合作伙伴结算、以及运营数据报表等等。第二是埋点的效率，埋点的复杂度往往与业务需求相关，埋点效率会影响版本迭代的速度。第三是动态部署与修复埋点的能力，本质上这也是提升埋点效率的一种手段，并且使埋点不再依赖于客户端发版。公司原有埋点主要采用手动代码埋点的方案，代码埋点虽然使用起来灵活，但是开发 ...继续阅读 (94)

应用背景及现状美团外卖业务自2013年9月启动至今已运营三年时间。截至2016年12月，美团点评整个外卖平台的日订单超过900万。从发展速度和体量上看，外卖业务仍处在迅猛发展的上升期。与早期飞速增长的状态相比，随着规模的不断扩大，业务的发展需要更健康、高效，这就对业务对象、业务环节的整体业务运营管理提出更高的要求。特征档案平台向各业务提供了用户/商户筛选和档案管理服务，同时提供了数据查询、存储、生成、导出等数据管理功能，能够提高运营工作效率。当前用户特征档案平台覆盖全部的外卖用户，有特征标签近200个，商户特征档案平台覆盖全部的外卖商户，有特征标签400多个。特征档案的用户希望通过平台及时获取到满足筛选条件的结果集，并保存固定的筛选逻辑，实现定制化筛选。抽象出来，主要有以下几个核心诉求：便捷的筛选方式。通过点击页面可视化的标签，进行便捷查询。即时自助查询。不同的使用者可随时执行各种各样的标签查询。查询结果全量获取。对满足查询条件的结果全集进行全量获取。面对上面的需求，开发人员需要解决以下几个核心问题：将海量数据处理加工成标签，并实现完善的标签体系。使用合适的存储查询引擎实现即时查询海量数据。使用合适的存储查询引擎实现查询结果的全量获取，并提供接口服务。特征档案的标签生产，在外卖数据仓库中完成。针对主题加工出需要的标签，围绕用户以及商户建立完善的标签体系，支撑上层应用。我们使用了ES ...继续阅读 (85)

客户端布局是客户端开发最为基础也是最为重要的编程实践之一，对于一个有着良好技术架构的客户端开发团队来说，布局编码工作占业务开发工作量的80%。显然，对于布局编码进行深入的思考、总结统一最佳实践、提供有力的基础架构支撑，对于提升客户端开发团队的生产力非常关键。同时，客户端动态化是当前移动开发领域的技术热点，也是移动开发未来最为重要的发展方向之一。当前业界涌现出了React Native和Weex等解决方案，但是这里就存在迷一样的事实：所有框架的指导思想都是保持Web基本布局实践的前提下，通过原生渲染来提高性能。但是，在移动互联网时代，开发者应该扩展一下问题解决思路：Web及其Web的布局实践不是唯一的道路，甚至不可能是最好的思路。本文从点评App iOS团队的布局实践——匠心布局开始说起，向大家展示一种反常规甚至反直觉的布局方案，和点评移动团队按照匠心布局全新设计的跨平台动态化布局框架毕加索（picasso）。匠心布局匠心布局原本是点评iOS布局逻辑开发最佳实践的总结，随着跨平台动态化布局框架毕加索（picasso）的推出，使匠心布局成为跨平台的标准实践。布局逻辑的本质在对比布局方案和思路之前，我们先思考一下布局需求的本质是什么？布局的本质就是:1. 指定视图的大小和位置 2. 响应变化，在产生变化的时候重新指定大小和位置变化的来源我们可以将变化的来源划分为两个方面，内部来源和外部来 ...继续阅读 (94)