我们来看两个商品标题的例子，这是分别来自淘宝网和京东商城的两条普通商品标题：

1. 冲三冠 腾龙AF 17-50mm VC F2.8（B005）送uv包顺丰8折 大陆行货

这条Title里包含了唯一确定商品的关键属性（品牌和型号）、商品性质（行货），商品促销信息（冲三冠折扣、赠品）

2. 能率（NORITZ）GQ-1680CAFE 天然气（12T）16升家用燃气快速热水器 白色

这条Title包含了商品的中英文品牌、型号、产品类型、容量、颜色等信息。

可以看到：作为用户了解商品信息的第一道入口，商品标题包含有丰富而优质的商品信息，能够在第一时间向用户传达商品最重要的特征。有鉴于此， 在一淘网对商品信息的处理过程中，我们对部分商品的标题进行分析分解，将其中包含的语义信息归类。然后提取出需要的语义信息，再进行进一步的产品逻辑处理。为此，我们开发了中文商品的标题信息分析（以下简称Title分析）程序。

1. Title中商品信息类别

要对Title信息分类，首先需要知道Title中都可能包含哪些类别的信息。我们把Title中的商品信息类别归纳如图1：



图1

2. Title分析的基本处理思路：
   1. 处理的基本单元是词，我们使用了阿里巴巴自己的分词工具AliWS将商品Title切词并获取词的长度、词性、属性等信息。
   2. 每一种语义类各自的识别方法包括两种基本类型：词典和特征模式。
      1. 词典：

      某些语义类并没有复杂的组成形式，当某个词在title中出现就可以认为这个词属于该语义类。以品牌词为例，无论在何种情况下，当title中出现了”阿迪达斯”这个词，就可以认为它代表品牌。（当然也有例外情形，如“苹果”有可能是品牌也可能是产品类型。这就需要一些消除歧义的逻辑来补充）。对于这种语义类，我们采用离线挖掘的方式整理出词典，然后在处理过程中按照词典匹配分析。

      2. 特征模式：

      语义类一般存在有特别的特征模式。包括组成词的词性，词形式，上下文等都满足一定的规则。利用这种模式就可以做基本的语义判断。例如

…

定制LoadBalancer插件需要两个步骤：

1. 继承org.apache.hadoop.hbase.master.LoadBalancer Interface，实现自己的LoadBalancer Class
2. 在hbase-site.xml中增加配置项，使得定制的LoadBalancer生效

<property>

<name>hbase.master.loadbalancer.class</name>

<value>{your custom loadbalancer class name}</value>

<description></description>

</property>

因此，开发LoadBalancer插件的前提准备工作便是清楚了解org.apache.hadoop.hbase.master.LoadBalancer这个Interface：

public interface LoadBalancer extends

…

分析：

我们当时使用的Hadoop CDH3 Beta4 的版本。通过ganglia图表分析，出问题的tasktracker会出现一些流量的凸起。但是离带宽限制还很远。通过仔细分析TaskTracker的日志发现，Child子进程启动过程中，存在等待的问题。经过分析源码，Child子进程在启动过程是在一个线程中串行完成，启动过程包括了distributedcache文件的获取。由于Hadoop集群同时可能有各种各样的任务提交，所以当某个task的启动时间长，主要是下载distributedcache文件时间长，会影响下一个task的启动，严重的时候会影响tasktracker发送心跳。

处理方案1：

找出这些比较大的distributedcache，通过命令hadoop dfs -setrep [-R] <path>  设置更多的备份块，让网络负载能更均匀一些，这样对于当台机器而言，可以减少网络的out 流量，但是不能减少in流量，这样修改可以加快下载distributedcache的下载速度，缓解启动慢的问题，但是不能根本解决这个问题，而且当再次出现大的distributedcache任务时，问题还会重现。

处理方案2：

修改tasktracker的工作方式，最简单的办法，是让每个task各自通过一个task线程来启动，避免各个task之间的竞争，从根本上解决这个问题。代码如下：

  class StartNewTask extends Thread {
    TaskInProgress tip = null;

    public StartNewTask(TaskInProgress tip) {
      this.tip = tip;
    }

    public void

…

如何看待程序和代码呢？

那就让我们从程序定义来谈起，

如果从业务最终呈现来看，一个程序可以看成是一个真实业务需求的逻辑代码映射。

如果从程序逻辑结构看，程序就是数据结构加算法的结合。

这样看，为满足更多的业务需求，更好的满足这些需求，就需要更多的程序代码，

当程序代码堆积达到一定数量后，如何管理好，整理好已有的代码将会成为一个只管重要的问题。这个也是一个程序员编程3~5后，从中级向更高级别探索的一个瓶颈。

满足需要可工作的代码是好的，可被多个需求不断复用的代码，就是更好的了。

随着软件设计的发展，代码的集合，功能逻辑不断向下沉淀封装的趋势越来越明确。

使用好一个工具很快，掌握好一种设计思想就要不断的尝试和改进了。

有专门处理数据的代码，有专门处理呈现的代码，如何在业务流程中管理配置他们？这些逻辑如何更好的被封装，被复用。

其实对于PHPer来说，这些思想在处理具体业务来说有些麻烦，这也是PHP的最大优势非常的自由方便，自由简单随意的基本语法，方便的连内存资源都不用考虑，很快就可以hello一个,

但这也正是PHP一个先天的重大劣势，没有一个系统的成脉络的设计体系，

PHP出生时就是一个单一的满足业务的语言，并没有像JAVA一样有很系统设计体系和原则。在JAVA有三个最基础的设计原则：1，不支持全局变量。2，不写万能类。3，代码必须是类封装。

JAVA的第一个，第三个原则是在语法上就限制了，第二个原则是评判一个JAVA程序员是否入门的标准。PHP相对来说就没什么这样的语法上的设计原则限制，可接触了一些big company真没有体系原则呀，哎，

但在我们设计思想里可不能真的没有原则呀！

PHP程序其实是怎么方便怎么来，解释器很强大，可以屏蔽包容各种思路的程序代码，只要语法OK，不在乎代码设计。

正因早期的PHP太随意了，入门很容易，不用很好的对代码进行有效的管理和方便的复用。

随着PHP的发展，PHP已经告别在PHP3~PHP4时代动态标记语言，但因为向上兼容原则，PHP还是一个语法宽松的语言，

系统化的程序设计原则还没有强制融入到语言核心中来。

这样并不代表我们不需要使用成熟的设计思想来完善和编写我们的程序代码。

JAVA的程序设计原理和代码积累，是JAVA的精髓，随着时间的积累越发明显。

将JAVA的程序设计思想，引入到PHP的编程过程中来。是一个完善PHP代码的很好的方法。

1,代码分级封装

2,文件灵活调用加载，资源随用随创建

3,平整抗老化的目录结构

解决这些能为程序编写过程，带来非常多的益处。

如何解决呢？
可以通过对于MVC设计思想进行的拆解封装，来实现清晰，有效，一致性的程序设计思想。
一个程序从逻辑结构上可看做是模型(Model),视图(View)和控制Controller)三个逻辑块。
在JAVA中Model层实现系统中的业务逻辑，通常可以用JavaBean或EJB来实现。 View层用于与用户的交互，通常用JSP来实现。Controller层是Model与View之间沟通的桥梁，通常是router servlet向应用端的扩展。
可 PHP 没有这样清晰的划分，所以需要将设计思想揉入到程序代码中去。…

漏洞主要是由mixed preg_replace ( mixed pattern, mixed replacement, mixed subject [, int limit]) 这个函数引起的，我们先看官方说明：

/e 修 正符使 preg_replace() 将 replacement 参数当作 PHP 代码(在适当的逆向引用替换完之后)。提示：要确保 replacement 构成一个合法的 PHP 代码字符串，否则 PHP 会在报告在包含 preg_replace() 的行中出现语法解析错 误。

我们不妨先看一下这个示例

如果我们提交?h=phpinfo()，phpinfo()将会被执行（使用/e修饰符，preg_replace会将 replacement 参数当作 PHP 代码执行）。这个正则被正确的匹配到，在进行替换的过程中，需要将$_GET["h"]传入的String当作函数来运行，因此phpinfo()被成功执行。

代码如下：

<?php
preg_replace("/test/e",$_GET["h"],"jutst test");
?>

访问的url ： ?h=phpinfo()

进而，我们进入ThinkPHP的源码，下载2.1版（2.1以后已经被修复）。在/ThinikPHP/Lib/ThinkPHP/Util/Dispatcher.class.php的dispatch函数中，找到这句话：

在ThinkPHP的路由功能中，很多地方用到了preg_replace函数的/e参数,然而最严重的是这个文件中的这句话，因为几乎影响了所有使用Thinkphp的项目。

显然，这个使用了/e函数，会导致第二个参数当作函数使用。我们来分析一下这句话：

正则匹配的是 ：字母开头，加上“/”分隔符，后面跟一个非”/”的元素，被替换成$var["分隔符前的字母"]=分隔符后的值；作者的本意是要将这么一对一对的参数/值的形式的url写入到…

应用APP（电信）-> memcache ->电信custom接口 ->master-db

应用APP（网通）-> 网通custom接口 -> slave-db

接口环境是php（cgi） + nginx，接口已经运行很久，未出过异常

应用访问custom接口，然后接口去查数据库（数据库是主从复制，数据同步，各自机房读各自的数据库，写的话都写master-db）

有一点，就是电信机房是有memcache层的，而网通机房一直没有（考虑到网通机房流量不高，并且机房cache不同步，从上线起就网通机房一直未使用cache）

有一次上线，这个上线的版本有个改动就是把电信机房的memcache也取消了，然后 电信机房流量暴增

看pv统计：

$ “find /path -name ‘access*’|xargs wc -l|awk ‘END{print$1}’” fe

cmd :find /path ‘access*’|xargs wc -l|awk…