给定二进制搜索树和目标数字，如果BST中存在两个元素，使得它们的和等于给定的目标，则返回true。

Example 1:

Input:

   5
   / \
  3   6
 / \   \
2   4   7

Target = 9

Output: True

Example 2:

Input:

   5
   / \
  3   6
 / \   \
2   4   7

Target = 28

Output: False

给定一个整型数组，以及一个目标数值V，要求返回两个能够相对等于V值的两个数字的索引序列。每个数字只能使用一次。

例子：
`
Given nums = [2, 7, 11, 15], target = 9,

Because nums[0] + nums[1] = 2 + 7 = 9,
return [0, 1].
`

原文地址：How to Write a Git Commit Message

介绍：为什么好的提交信息很重要

如果您随机浏览一个Git存储库的日志，您可能会发现其提交消息或多或少是一团糟。 例如，从早期的Spring提交日志来看这些问题点：

1
2
3
4
5
6
7

$ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009"

e5f4b49 Re-adding ConfigurationPostProcessorTests after its brief removal in r814. @Ignore-ing the testCglibClassesAreLoadedJustInTimeForEnhancement() method as it turns out this was one of the culprits in the recent build breakage. The classloader hacking causes subtle downstream effects, breaking unrelated tests. The test method is still useful, but should only be run on a manual basis to ensure CGLIB is not prematurely classloaded, and should not be run as part of the automated build.
2db0f12 fixed two build-breaking issues: + reverted ClassMetadataReadingVisitor to revision 794 + eliminated ConfigurationPostProcessorTests until further investigation determines why it causes downstream tests to fail (such as the seemingly unrelated ClassPathXmlApplicationContextTests)
147709f Tweaks to package-info.java files
22b25e0 Consolidated Util and MutableAnnotationUtils classes into existing AsmUtils
7f96f57 polishing

与同一存储库中的这些最近的提交进行比较：

1
2
3
4
5
6
7

$ git log --oneline -5 --author pwebb --before "Sat Aug 30 2014"

5ba3db6 Fix failing CompositePropertySourceTests
84564a0 Rework @PropertySource early parsing logic
e142fd1 Add tests for ImportSelector meta-data
887815f Update docbook dependency and generate epub
ac8326d Polish mockito usage

哪一个你更愿意去阅读呢？

前者在长度和形式上变化很大; 后者简洁而一致。 前者是默认情况; 后者不会偶然发生。

虽然许多Git存储库的日志看起来像前者，但也有例外。 Linux内核和Git本身就是很好的例子。 看看Spring Boot，或者由Tim Pope管理的任何存储库。

前言

前面两篇文章中描述了配置中心的基本架构与基本概念，本节将讲述如何实现配置存储与获取的高可用设计。

配置中心作为整个应用运维体系的基础组件，其重要性可见一斑。如果配置系统不具备高可用的特性，一旦发生配置中心服务不可用，那么影响到的将要成千上万的在线应用，由此带来的损失简直是无法估量。做到配置中心高可用架构可以从以下几个方面着手：

• 存储高可用
• API服务高可用
• 客户端容灾

整体架构

Operator    -------->        Web主控台               ------->     MySQL Master
                                |                                     |
                             (notify)                               (sync)
                                |                                     |
                                ----------|                           |
                                          |                         ---------------------
SDK Client ---（Load Banlancer）----> API Server Cluster               |        |      |
     |                                    |                         slave1   slave2  slave3 ...
  (cache)                            (dump file)                      ^       ^       ^
     |                                    |                           |       |       |
 Local Cache                              |---->Slave Proxy(HaProxy) ------------------------

前言

对于配置中心主控台的设计，其实我设计的原则是设计成一个统一管理元数据（应用接入、环境定义、版本定义、人员权限划分、配置管控等）功能的一个综合平台。对于一个应用接入配置中心来说，很自然想到需要一些实体来承担配置的管理载体。主控台是用户使用操作最为频繁的地方，良好的组织结构与交互设计能够给人带来办事效率上的提高，所以这块我也是经过了很多次版本的设计与修改，最终产出的是一个类似树型的结构体系。

配置中心从开发到线上接入运行已经过去快半年时间了，目前配置中心整体运行非常平稳，达到当初的设计目的，这里才敢有勇气拿出来分享设计，毕竟一样东西拿出来与人分享是需要勇气和底气的。同时对自己的实践过程进行一些总结，希望自己有时间回头瞭望时会有新的认识和发现。

前言

对于一个可运行的程序来说，配置可以说是驱动它运行的灵魂。良好的配置能指导程序正确的运行，并产出符合期望的结果。对于现有的软件来说，配置可以是多种多样的，配置可以写在配置文件中由程序运行时读取，也可以在启动程序时通过命令行方式传入，配置也可以是各种环境参数由程序在运行时进行读取，甚至有些参数直接写死在程序代码中。

对于程序开发来说，程序中某个参数的值在各种部署环境下或者在某种情况下需要更改，那这种值就可以抽象成配置项。在没有引入配置文件之前，要对各种部署进行适应的方式就是修改源代码中相应值然后重新打包并部署，而如果将该值抽象成配置后独立于配置文件中，这样就能够独立于程序之外单独进行修改而不用重新编译整体程序。

前言

在几天前我的一篇文章中，提到了需要升级公司的Presto数据查询引擎，而我们的Presto引擎是由Ambari管理的，升级Presto并没有任何文档可以参考，都是自己不断摸索出来的路子。所以写下本文用于记录摸索过程，并留待以后方便追溯和查看。

对于Ambari管理的组件，对于HDP发行版来说，单个组件的升级可能导致HDP发行版其它组件间的冲突，所以Ambari并没有提供单个组件的升级。而Ambari提供的升级方式是Ambari主控台先进行升级，升级后的Ambari可以在WEB界面上完成各个组件的升级，这样所有组件的统一升级的结果是：拥有最新的比较稳定的版本，且各组件间可以很好的配合使用，不会出现冲突，这个是Hortonworks公司帮我已经解决的依赖及冲突问题，这也是使用类似CDH或者HDP这样的Hadoop发行版的原因，省事！

当然值得一提的是，升级大数据平台组件是一件需要非常谨慎又小心的事情，不到万不得已请不要贸然升级，升级前还要做好万全的准备，比如数据备份，升级计划梳理，灾难预案等等。

我这里升级的是Presto，是一个比较独立的组件，所以我打算单独升级它，并不使用整体升级Ambari来更新所有的组件，而且当前Presto并没有提供更新的Ambari插件，所以这里需要我自己进行一些Hack。

前言

随着商业数据的不断累积与爆发式增长，传统的数据存储已经不能很好的满足日益增长的数据系统需要，传统的通过关系型数据进行数据获取的方式正在随着数据量的快速增长而出现了瓶颈，随着以Hadoop为代表的大数据平台的出现，有效解决了数据高速增长带来的数据存储和管理问题。现在大数据平台基本上每家公司都发展中长期必备的基础设施，公司基础数据平台使用的Hortonworks提供的大数据平台发行版，使用ambari进行数据平台的管理工作。前段时间大数据平台引入的Presto数据查询引擎作为即席查询工具，并使用ambari对presto的插件支持进行管理。

Ambari是由Hortonworks公司出品一款大数据平台管理软件，它将大数据平台所需要的各种组件进行统一管理，并提供大数据平台主机管理及各组件的安装制定、配置、启停、监控等一系列非常方便的功能。同时它也支持用户自定义组件插件，提供了良好的扩展能力。

问题

最近公司大数据查询引擎Presto运行非常不稳定，容易出现掉节点的问题（一些Presto节点会在莫名其妙的情况出现宕机），从日志上看到是内存溢出了。公司线上的Presto集群JVM使用的垃圾回收器是G1，这也是Presto引擎推荐的一款GC收集器，G1对于超大内存（6G+）的垃圾收集有着良好的效率，能够高效的进行垃圾收集，并控制垃圾收集导致的停顿时间。

最近在做一款大数据查询系统，该系统提供给数据分析人员一个用户交互界面，让用户提供SQL语言进行交互查询，前台应用提供一些辅助功能，这样的数据查询系统要优于通过纯console的方式进行查询，查询平台提供了用户管理，权限管理，交互易用性扩展，多引擎框架支持等。

最近出现的一个问题是用户提交的SQL很大部分时间上并没有携带Limit限制返回条数，导致产生了大量的数据查询浪费，因为在界面上是不会展示所有的结果数据，一般我们在前台页面上只展现少量数据，比如只展现前面100条，而这100条在很大部分情况下已经满足了分析师同学的数据分析需求，然而不太规范的SQL编写可能导致无limit关键字而导致大量的查询，所以当前的一个需求是对用户提交的SQL进行改写，将SQL中存在limit限制的地方进行判断，如果没有设置limit数或者limit大于最大限制，设置成最大限制，限制数据的查询量和返回量。