最近在自己的机器上部署了Hadoop0.18，在这里记录一下过程：
操作系统使用CentOS 5
每一步后面括号中标明操作的对象，“对所有节点”是在所有节点上都执行一次。“对主节点”只需按要求在主节点执行即可。
在网上下载JDK程序包。
这里以jdk1.5.0_14为例，并安装在/home目录下。
在http://www.apache.org/dist/hadoop/core下载Hadoop,选择一个版本，例如：hadoop-0.18.3.tar.gz，安装至/home目录下。
这里假设有三台机器，主节点10.63.0.51，从节点10.63.0.52和10.63.0.53。多台机器的配置可依此类推。
在/home/hadoop-0.18.3/conf下，配置hadoop-site.xml文件如下：
使用mysql自带的mysqlslap工具测试数据库的性能，命令行的方式并不太友好，这里我们仍然介绍下jmeter来测试mysql。Jmeter使用了JDBC技术，使得可以测试任何支持JDBC技术的数据库，包括mysql，oracle，pgsql,Mssql等。我们分步演示下jmeter测试mysql的步骤。
（1） 仍然是新建测试计划，在其下新建一个线程组。并设置并发为50，不循环。
（2） 配置JDBC。在线程组上点击右键，选择添加→配置元件→JDBC Connection Configuration。配置各项参数，其中Variable Name：可以随便填写，此处填写mysql。最主要的配置是Database Connection Configuration.
Database URL:JDBC格式的数据库连接，每种数据库的URL都有所区别。Mysql的如下，jdbc:mysql://localhost:3306/test，test为数据库名称。
JDBC Driver class：JDBC驱动的名称
Username：数据库用户名
Password:数据库密码
其它配置项保持默认即可。
添加了JDBC参数后，我们还需要添加mysql的JDBC驱动。因为jmeter并没有自带这一jar包。可以到mysql官方网站找到mysql的JDBC驱动，在“测试计划”中添加class path。如图所示：
如果忘了这一步的话，将导致运行失败。
（3）添加JDBC请求。需要修改的参数包括：
在对服务器进行压力测试时，我们经常使用apache自带的工具ab。Ab虽然使用方法很简单，但功能也弱一些，对HTTP请求进行压力和性能测试，除了ab外，还有一款更专业的工具，叫做Jmeter..Jmeter是apache下的一个开源项目，使用java进行编写，是一个功能强大的性能测试工具，除了可以测试HTTP请求外，还能对FTP请求，数据库连接（使用JDBC）等进行测试，并且其HTTP测试的功能更强大，更有好的支持GET/POST定制。
先到官方网站下载最新版本：http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi，目前最新版是jakarta-jmeter-2.5.1。下载后，直接解压，运行bin/jmeter.bat即可。在使用jmeter前，先来了解几个术语：
1、线程组：测试里每个任务都要线程去处理，所有我们后来的任务必须在线程组下面创建。可以在“测试计划->添加->线程组”来建立它，然后在线程组面板里有几个输入栏：线程数、Ramp-Up Period(in seconds)、循环次数，其中Ramp-Up Period(in seconds)表示在这时间内创建完所有的线程。如有8个线程，Ramp-Up = 200秒，那么线程的启动时间间隔为200/8=25秒，这样的好处是：一开始不会对服务器有太大的负载。
2、取样器（Sampler）：可以认为所有的测试任务都由取样器承担，有很种，如：HTTP 请求。
3、断言：对取样器返回的请求结果给出判断，是否正确。
4、monitor（监你妈的TG的河蟹听）：它的功能是对取样器的请求结果显示、统计一些数据（吞吐量、KB/S……）等。
我们试用一下：
（1） 建立测试计划
测试计划描述了执行测试过程中JMeter的执行过程和步骤，一个完整的测试计划包括一个或者多个线程组(Thread Groups)、逻辑控制（Logic Controller）、实例产生控制器（Sample Generating Controllers）、monitor、定时器（Timer）、断言（Assertions）等。打开JMeter时，它已经建立一个默认的测试计划,一个JMeter应用的实例只能建立或者打开一个测试计划。
现在我们开始填充一个测试计划的内容，这个测试计划向一个文件发出POST请求，我们需要JMeter模拟50个请求者（也就是50个线程），每个请求者连续请求两次。
几乎可以肯定每个人都听说过 SELinux (更准确的说，尝试关闭过)，甚至某些过往的经验让您对 SELinux 产生了偏见。不过随着日益增长的 0-day 安全漏洞，或许现在是时候去了解下这个在 Linux 内核中已经有8年历史的强制性访问控制系统(MAC)了。
SELinux 全称 Security Enhanced Linux (安全强化 Linux)，是 MAC (Mandatory Access Control，强制访问控制系统)的一个实现，目的在于
强制访问控制系统的用途在于
举例来说，系统上的 Apache 被发现存在一个漏洞，使得某远程用户可以访问系统上的敏感文件(比如 /etc/passwd 来获得系统已存在用户)，而修复该安全漏洞的 Apache 更新补丁尚未释出。此时 SELinux 可以起到弥补该漏洞的缓和方案。因为 /etc/passwd 不具有 Apache 的访问标签，所以 Apache 对于 /etc/passwd 的访问会被 SELinux 阻止。
相比其他强制性访问控制系统，SELinux 有如下优势：
那么 SELinux 对于系统性能有什么样的影响呢？根据 Phoronix 在 2009 年使用 Fedora 11 所做的横向比较来看，开启 SELinux 仅在少数情况下导致系统性能约 5% 的降低。
SELinux 是不是会十分影响一般桌面应用及程序开发呢？原先是，因为 SELinux 的策略主要针对服务器环境。但随着 SELinux 8年来的广泛应用，目前 SELinux 策略在一般桌面及程序开发环境下依然可以同时满足安全性及便利性的要求。以刚刚发布的 Fedora 15 为例，笔者在搭建完整的娱乐(包含多款第三方原生 Linux 游戏及 Wine 游戏)及开发环境(Android SDK + Eclipse)过程中，只有 Wine 程序的首次运行时受到 SELinux 默认策略的阻拦，在图形化的“SELinux 故障排除程序”帮助下，点击一下按钮就解决了。
了解和配置 SELinux
1. 获取当前 SELinux 运行状态
getenforce
可能返回结果有三种：Enforcing、Permissive 和 Disabled。Disabled 代表 SELinux 被禁用，Permissive 代表仅记录安全警告但不阻止可疑行为，Enforcing 代表记录警告且阻止可疑行为。
目前常见发行版中，RHEL 和 Fedora 默认设置为 Enforcing，其余的如 openSUSE 等为 Permissive。
2. 改变 SELinux 运行状态
setenforce [ Enforcing | Permissive | 1 | 0 ]
该命令可以立刻改变 SELinux 运行状态，在 Enforcing 和 Permissive 之间切换，结果保持至关机。一个典型的用途是看看到底是不是 SELinux 导致某个服务或者程序无法运行。若是在 setenforce 0 之后服务或者程序依然无法运行，那么就可以肯定不是 SELinux 导致的。
若是想要永久变更系统 SELinux 运行环境，可以通过更改配置文件 /etc/sysconfig/selinux 实现。注意当从 Disabled 切换到 Permissive 或者 Enforcing 模式后需要重启计算机并为整个文件系统重新创建安全标签(touch /.autorelabel && reboot)。
官网: http://openresty.org/
虽然是中国人做的,但没几个汉字.....
我用Nginx,是这样一个过程:
1. 系统rpm中的nginx,能让其跑起来
2. 玩配置文件
3. 玩编译选项
4. 写插件,集成第三方插件
OpenResty , 是淘宝一位大牛(agentzh)集成的包含N多好插件的Nginx捆绑源码包,这位仁兄自称Nginx最活跃的第三方模块开发人员哦
下面,当然要列一下到底集成了什么模块:
LuaJIT -- 极速版Lua实现
ArrayVarNginxModule -- 数组类型的Nginx变量
AuthRequestNginxModule -- 鉴权,想象一下以C代码的速度判断一个请求是否合法,是不是很有快感呢?!
DrizzleNginxModule -- Nginx-MySQL桥,非阻塞的哦,我又爱又恨的一个模块,值得注意的是,其响应是RDS流
EchoNginxModule -- 以非常直观的方式在Nginx配置文件中编写简单的处理逻辑,源码包含大量注释,绝对是入门好例子!!
EncryptedSessionNginxModule -- 加密会话
FormInputNginxModule -- 解析post请求中的参数,这下子,简单请求根本不需要PHP/Java来处理啦
HeadersMoreNginxModule -- Nginx默认的header模块只能添加或忽略,这个给你CRUD全套的!!
IconvNginxModule -- 编码转换,不多说,也不懂
StandardLuaInterpreter -- 与Lua官方实现所匹配,一般用不上,因为我们用LuaJIT!!
MemcNginxModule -- 与Memcached的绝配,谁用谁知道!! 与upstram_keepalive一起用,你能更High!!
Nginx
NginxDevelKit -- N多第三方插件都依赖的东西,不知道为啥
LuaCjsonLibrary -- Lua版的Json处理库实在太慢,这个才叫速度!!
LuaNginxModule -- 我的最爱,一般逻辑,完全没必要用Java/PHP啦
LuaRdsParserLibrary -- 在Lua中直接处理RDS流,速度杠杠的!
LuaRedisParserLibrary -- 在Lua中处理Redia模块的响应,暂时我还没用上
PostgresNginxModule -- Nginx-Postgres桥,输出的也是RDS流
RdsCsvNginxModule -- RDS流转CVS格式,不知道能干啥,报表?
RdsJsonNginxModule -- RDS流转JSON字符串,之前经常用这个
Redis2NginxModule -- Nginx-Redis2桥
SetMiscNginxModule -- 提供很多很实用的方法,例如base64编解码,URL编解码,SQL防注入等等
SrcacheNginxModule -- 缓存模块,据说跟Memc模块一起用比较爽
UpstreamKeepaliveNginxModule -- 与Memc模块的标配,号称性能提升几倍呢
XssNginxModule -- 防跨站攻击的
OpenResty的最大的好处是帮你弄清楚各个模块的编译顺序,别小看,学问大大的呢
当初没有这东西,单单弄清楚模块间的编译顺序就耗费不少时间
来吧,试试这个国产的精品!!
refer:http://wendal.net/338.html
注意，问题可能没有你想的那么简单，满足要求的数分布得并没有那么规则。 1 、 2 、 3 、 4 里有一个满足要求的数， 5 、 6 、 7 、 8 里也有一个满足要求的数，但是 9 、 10 、 11 、 12 里就没有了。
尽管如此，这个问题仍然有一个秒杀解。你能多快想到？
答案就是 1000 。首先， 0 和 4000 都是满足要求的数，因而我们不去看 1 到 4000 中有多少个满足要求的数，转而去看 0 到 3999 中有多少个满足要求的数，这对答案不会有影响。注意到，如果固定了末三位，比如说 618 ，那么在 0618 、 1618 、 2618 、 3618 这四个数中，有且仅有一个数满足，其各位数字之和能被 4 整除。考虑从 000 到 999 这 1000 个可能的末三位组合，每一个组合都唯一地对应了一个满足要求的四位数，因此问题的答案就是 1000 。
真正有趣的事情在后面呢。一个小朋友举手说：“老师，我明白了，按照这个道理，从 1 到 3000 里各位数字之和能被 3 整除的数也是 1000 个。”另一个小朋友说：“废话，各位数字之和能被 3 整除就表明整个数能被 3 整除，在 1 到 3000 里这样的数当然有 1000 个嘛！”全班哄堂大笑。
refer:http://www.matrix67.com/blog/archives/4644
大多同事都已经养成用junit写单元测试的习惯,但junit在测试spring 时，存在一些不足！
1. Spring 容器多次初始化问题
根据 JUnit 测试用例的调用流程，每执行一个测试方法都会重新创建一个测试用例实例并调用其 setUp() 方法。由于在一般情况下，我们都在 setUp() 方法中初始化 Spring 容器，这意味着测试用例中有多少个测试方法，Spring 容器就会被重复初始化多少次
2. 用硬编码方式手工获取 Bean
在测试用例中，我们需要通过 ApplicationContext.getBean("bean id") 的方法从 Spirng 容器中获取需要测试的目标 Bean，并且还要进行造型操作。
3. 数据库现场容易遭受破坏
测试方法可能会对数据库记录进行更改操作，破坏数据库现场。虽然是针对开发数据库进行测试工作的，但如果数据操作的影响是持久的，将会形成积累效应并影响到测试用例的再次执行。举个例子，假设在某个测试方法中往数据库插入一条 ID 为 1 的 t_user 记录，第一次运行不会有问题，第二次运行时，就会因为主键冲突而导致测试用例执行失败。所以测试用例应该既能够完成测试固件业务功能正确性的检查，又能够容易地在测试完成后恢复现场.
4. 不容易在同一事务下访问数据库以检验业务操作的正确性
当测试固件操作数据库时，为了检测数据操作的正确性，需要通过一种方便途径在测试方法相同的事务环境下访问数据库，以检查测试固件数据操作的执行效果。如果直接使用 JUnit 进行测试，我们很难完成这项操作。
Spring 测试框架是专门为测试基于 Spring 框架应用程序而设计的，它能够让测试用例非常方便地和 Spring 框架结合起来.
下面我们看下如何使用：