当用户在一个网站浏览或者搜索商品时，在大多数时间他所面对的都是商品标题+商品图片的商品信息形式。只有当这种简要的信息抓住了用户的眼球时或者达到用户的心理预期时才能引导用户进入更详细的商品详情页。这就对其中唯一的文本信息载体：商品标题包含的信息内容质量提出了要求。

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

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. 特征模式：

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

…

HBase 中的LoadBalancer策略控制了如何在集群启动时Assign所有用户Region到各个RegionServer上，以及如何定期检查Region分布情况并重新调整Region位置的。这些工作在0.92之前的版本中都是在HBase Master内核中实现的，开发人员如果希望扩展自己的LoadBalancer插件，只能Hack源码，但这随着社区版本的升级，Hack工作必须移植到新的版本中。幸好在0.92版本中，HBase将LoadBalancer策略从Master内核中抽取了出来，开放了LoadBalancer Interface，允许开发者根据自己的业务特定扩展自己的LoadBalancer插件。

定制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 Configurable { /** * Set

…

在增量DUMP过程中，我们的job比较小，但是启动非常频繁，每个job的执行时间短，通过执行的日志发现，有时会出现一个job的启动时间很长，需要几十秒。由于我们很看重增量的速度，所以几十秒的等待是不可接受的。

分析：

我们当时使用的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 run() { try { LOG.debug("(StartNewTask

…

coding多年，各种代码日夜相伴，如何跟代码友好的相处，不光成为职业生涯的一种回应，也是编写者功力的直接显露。

如何看待程序和代码呢？

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

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

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

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

当程序代码堆积达到一定数量后，如何管理好，整理好已有的代码将会成为一个只管重要的问题。这个也是一个程序员编程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 没有这样清晰的划分，所以需要将设计思想揉入到程序代码中去。…

PHP以其易用性和可移植性正被广泛应用于WEB开发。然而，在我们使用的过程中，也要十分小心，从随处可见的XSS（新浪微博发送大量垃圾信息事件）到前段时间爆出来的Hash冲突的DDOS攻击，最近，wooyun上面发布了一个关于ThinkPHP框架的漏洞（最新版已经修复），以前也是我用过的第一个框架，昨晚花时间重现了一下，查阅了下程序的原理。本文主要来重现该漏洞，然后分析代码，给出漏洞的原因，用这个漏洞去检验可能对系统造成的破坏，最后总结，防范的方法。

漏洞主要是由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写入到 $var[$key] = $value的数组中。

例如：URL，index.php?s=/model/action/par1/value1…

有个应用就是每次都会去查一个接口，接口返回用户的信息数据，从而展现不同的页面效果。大致流程如下

应用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…

编码问题的例子

在windows自带的notepad（记事本）程序中输入“联通”两个字，保存后再次打开，会发现“联通”不见了，代之以“��ͨ”的乱码。这是windows平台上典型的中文编码问题。即文件保存的时候是按照ANSI编码（其实就是GB2312，后面会详细介绍）保存，打开的时候程序按照UTF-8方式对内容解释，于是就出现了乱码。避免乱码的方式很简单，在“文件”菜单中选择“打开”命令，选择保存的文件，然后选择“ANSI”编码，此时就能看到久违的“联通”两个字了。

在Linux平台上如果使用cat等命令查看文件中的中文内容时，可能出现乱码。这也是编码的问题。简单的说是文件时按照A编码保存，但是cat命令按照当前Locale设定的B编码去查看，在B和A不兼容的时候就出现了乱码。

为什么写这篇文章

中文编码由于历史原因牵扯到不少标准，在不了解的时候感觉一头雾水；但其实理解编码问题并不需要你深入了解各个编码标准，只要你明白了来龙去脉，了解了关键的知识点，就能分析和解决日常开发工作中碰到的大部分编码问题。有感于我看过的资料和文章要么不够全面，要么略显枯燥，所以通过这篇文章记录下笔者在日常工作中碰到的中文编码原理相关问题，目的主要是自我总结，如果能给读者提供一些帮助那就算是意外之喜了。由于严谨的编码标准对我来说是无趣的，枯燥的，难以记忆的，本文尝试用浅显易懂的生活语言解释中文编码相关的（也可能不相关的）一些问题，这也是为什么取名杂谈的原因。本文肯定存在不规范不全面的地方，我会在参考资料里给出官方文档的链接，也欢迎读者在评论中提出更好的表达方式&指出错误，不胜感激。

对编码问题的理解我认为分为三个层次，第一个层次：概念，知道各个编码标准的应用场景，了解之间的差异，能分析和解决常见的一些编码问题。第二个层次：标准，掌握编码的细节，如编码范围，编码转换规则，知道这些就能自行开发编码转换工具。第三个层次，使用，了解中文的编码2进制存储，在程序开发过程中选择合理的编码并处理中文。为了避免让读者陷入编码标准的黑洞无法脱身（不相信？看看unicode的规范就明白我的意思了），同时由于编码查询&转换工具等都有现成工具可以使用，本文只涉及第一个层次，不涉及第二层次，在第三层次上会做一些尝试。在本文的最后提供了相关链接供对标准细节感兴趣的同学继续学习。最后，本文不涉及具体软件的乱码问题解决，如ssh，shell，vim，screen等，这些话题留给剑豪同学专文阐述。

一切都是因为电脑不识字

电脑很聪明，可以帮我们做很多事情，最开始主要是科学计算，这也是为什么电脑别名计算机。电脑又很笨，在她的脑子里只有数字，即所有的数据在存储和运算时都要使用二进制数表示。这在最初电脑主要用来处理大量复杂的科学计算时不是什么大问题但是当电脑逐步走入普通人的生活时，情况开始变遭了。办公自动化等领域最主要的需求就是文字处理，电脑如何来表示文字呢？这个问题当然难不倒聪明的计算机科学家们，用数字来代表字符呗。这就是“编码”。

英文的终极解决方案：ASCII

每个人都可以约定自己的一套编码，只要使用方之间了解就ok了。比如说咱俩约定0×10表示a，0×11表示b。在一开始也的确是这样的，出现了各式各样的编码。这样有两个问题：1.各个编码的字符集不一样，有的多，有的少。2.相同字符的编码也不一样。你这里a是0×10.他那里a可能是0×30。于是你保存的文件他就不能直接用，必须要转换编码。随着沟通范围的扩大，采用不同编码的人们互相通信就乱套了，这就是我们常说的：鸡同鸭讲。如果要避免这种混乱，那么大家就必须使用相同的编码规则，于是美国有关的标准化组织就出台了ASCII（American Standard Code for Information Interchange）编码，统一规定了英文常用符号用哪些二进制数来表示。ASCII是标准的单字节字符编码方案，用于基于文本的数据。

ASCII最初是美国国家标准，供不同计算机在相互通信时用作共同遵守的西文字符编码标准，已被国际标准化组织（International Organization for Standardization, ISO）定为国际标准，称为ISO 646标准。适用于所有拉丁文字字母。ASCII 码使用指定的7 位或8 位二进制数组合来表示128 或256 种可能的字符。标准ASCII 码也叫基础ASCII码，使用7 位二进制数来表示所有的大写和小写字母，数字0 到9、标点符号， 以及在美式英语中使用的特殊控制字符。而最高位为1的另128个字符（80H—FFH）被称为“扩展ASCII”，一般用来存放英文的制表符、部分音标字符等等的一些其它符号。

其中：0～31及127(共33个)是控制字符或通信专用字符（其余为可显示字符），32～126(共95个)是字符(32是空格），其中48～57为0到9十个阿拉伯数字，65～90为26个大写英文字母，97～122号为26个小写英文字母，其余为一些标点符号、运算符号等。

现在所有使用英文的电脑终于可以用同一种编码来交流了。理解了ASCII编码，其他字母型的语言编码方案就触类旁通了。

一波三折的中文编码

第一次尝试：GB2312

ASCII这种字符编码规则显然用来处理英文没有什么问题，它的出现极大的促进了信息在西方尤其是美国的传播和交流。但是对于中文，常用汉字就有6000以上，ASCII 单字节编码显然是不够用。为了粉碎美帝国主义通过编码限制中国人民使用电脑的无耻阴谋，中国国家标准总局发布了GB2312码即中华人民共和国国家汉字信息交换用编码，全称《信息交换用汉字编码字符集——基本集》，1981年5月1日实施，通行于大陆。GB2312字符集中除常用简体汉字字符外还包括希腊字母、日文平假名及片假名字母、俄语西里尔字母等字符，未收录繁体中文汉字和一些生僻字。 EUC-CN可以理解为GB2312的别名，和GB2312完全相同。

GB2312是基于区位码设计的，在区位码的区号和位号上分别加上A0H就得到了GB2312编码。这里第一次提到了“区位码”，我就连带把下面这几个让人摸不到头脑的XX码一锅端了吧：

区位码，国标码，交换码，内码，外码 …

这个是对abuild/kbuild项目的一些总结，也是用Beamer写的第二个slide，遇到的问题不少，折腾了几天，勉强还算满意吧。

…

本文是作者在学习doclist压缩时的一点总结，希望以尽可能简单明了的方式描述各个算法的思想和适用场景，帮助同学们理解和比较。本文并不涉及具体的算法实现，代码请大家自行google。这里需要强调的是“所谓的改进顺序”只是作者yy出来方便理解记忆，并不反应真实的压缩方法发展历程。

1.什么是doclist？

倒排表的基本组成部分，看例子：

Computer： 10,35,100,170,370,29000,30000,30010

表示computer这个词出现在编号（docid）为10,35,100,170,37029000,30000,30010的doc中，10,35,100,170,370,29000,30000,30010即为doclist，在下文中作者会多次使用这个例子来演示压缩算法以及计算压缩比，但请注意这个例子是作者虚构的，所以按照例子得到的结论并不能代表每个算法的真实优劣。

在搜索引擎倒排索引中需要大量保存这类数据，如何高效的存储和访问成为一个搜索引擎性能高低的关键。对一个压缩方法的效果进行评估主要看以下3个方面：1. 压缩速度，2.压缩比3.解压缩速度。可以认为这3个是互相影响和制约的，一般来说压缩速度越慢，压缩比越高，解压缩也越慢。而对搜索引擎来说这3个因素中最关注的是3和2，可以适当放宽的是1.为什么？因为doclist压缩只有一次即建索引的时候，而每次查询都需要解压缩；压缩比高则索引越小，更多的索引可以放内存，查询速度自然更快。

2.最naive的方法：定长int

方法：使用定长的int来精确记录每一个docid

小改进1：由于docid为不可能为负数，可以使用uint来保存

小改进2：根据docid的取值范围选择u16，u32，u64

小改进3：根据docid的取值范围选择合适的bit数N，N>=logMAXDocid，这样每个数只需要N个bit。这里有一个内存访问对齐的问题，每次取一个数效率不高，怎么办？一次取32（64）个数，自然就是对齐的了嘛。

10,35,100,170,370,29000,30000,30010	压缩算法	需要的bit	说明
	U16

…