2013年7月月 发布的文章

memcache在linux下的安装

大前提:安装gcc 

输出表明缺少gcc

输出表明缺少gcc


最简单的是yum安装:
yum -y install gcc
1、libevent是安装 memcached 的唯一前提条件。它是 memcached 所依赖的异步事件通知库。

tar -zxvf  libevent-1.4.11-stable.tar.gz
./configure
make
make install

configure

configure


make

make


make install

make install


2、memcache安装

./configure
make
make install

mem configure

mem configure


mem make

mem make


mem make install

mem make install


3、memcache启动

./memcached -d -m 1024 -u root -p 11211 -c 1024 -P /root/memcache_api_1.pid -t 24

memcached启动参数描述:
-d :启动一个守护进程
-m :分配给Memcache使用的内存数量,单位是MB,默认是64MB,
-u :运行Memcache的用户
-l :监听的服务器IP地址
-p :设置Memcache监听的端口,默认是11211 注:-p(p为小写)
-c :设置最大并发连接数,默认是1024
-P :设置保存Memcache的pid文件 注:-P(P为大写)
4、验证启动
ps -ef | grep memcached | grep 11211

查看是否存在进程

查看是否存在进程


验证memcache安装是否成功

验证memcache安装是否成功


5、命令说明
command

key key 用于查找缓存值
flags 可以包括键值对的整型参数,客户机使用它存储关于键值对的额外信息
expiration time 在缓存中保存键值对的时间长度(以秒为单位,0 表示永远)
bytes 在缓存中存储的字节点
value 存储的值(始终位于第二行)
6、通过进程号kill掉memcache进程
kill -9 3146

百度百科数字博物馆:数字体验云冈石窟的魅力

云冈石窟,全称大同云冈石窟,是中国最大的石窟之一,与敦煌莫高窟、洛阳龙门石窟和天水麦积山石窟并称为中国四大石窟艺术宝库。 其位于山西省北部大同市区以西16公里处的武周山南麓,依山而凿,东西绵延约一公里,气势恢弘,内容丰富。现存主要洞窟45个,大小窟龛252个,造像5万1千余尊,代表了公元5至6世纪时中国杰出的早期佛教石窟艺术。其中的昙曜五窟,布局设计严谨统一,是中国佛教艺术第一个巅峰时期的经典传世杰作。
百度百科数字博物馆:
数字体验云冈石窟的魅力
http://baike.baidu.com/museum/yungang.html

云冈石窟

云冈石窟

一个有趣的网站

http://www.haniboi.com/ 一个有趣的网站

hadoop云计算

hadoop云计算

xss攻击

恶意攻击者往Web页面里插入恶意html代码,当用户浏览该页之时,嵌入其中Web里面的html代码会被执行,从而达到恶意用户的特殊目的。
XSS的种类:
XSS攻击分成两类,一类是来自内部的攻击,主要指的是利用程序自身的漏洞,构造跨站语句,如:dvbbs的showerror.asp存在的跨站漏洞。
另一类则是来自外部的攻击,主要指的自己构造XSS跨站漏洞网页或者寻找非目标机以外的有跨站漏洞的网页。如当我们要渗透一个站点,我们自己构造一个有跨站漏洞的网页,然后构造跨站语句,通过结合其它技术,如社会工程学等,欺骗目标服务器的管理员打开。
XSS漏洞是Web应用程序中最常见的漏洞之一。如果您的站点没有预防XSS漏洞的固定方法,那么就存在XSS漏洞。这个利用XSS漏洞的病毒之所以具有重要意义是因为,通常难以看到XSS漏洞的威胁,而该病毒则将其发挥得淋漓尽致。
XSS工作流程:
1)恶意用户,在一些公共区域(例如,建议提交表单或消息公共板的输入表单)输入一些文本,这些文本被其它用户看到,但这些文本不仅仅是他们要输入的文本,同时还包括一些可以在客户端执行的脚本。如:

2)恶意提交这个表单
3)其他用户看到这个包括恶意脚本的页面并执行,获取用户的cookie等敏感信息。
例子:
site:suning.com inurl:callback

由一个漏洞引发的思考

最近项目比较紧,没时间来写博客,意味着思考少了。两件事:
1、struts2最近爆出了一个漏洞,线上版本必须修补。但是线上的版本源代码已经不可恢复了,新版本代码又没开发、测试完成,代码版本管理没有做好,即使是自己一个人做项目也应该管理好代码。版本控制非常重要,虽说上一个版本不一定好!
2、新版程序发现一个问题,这个问题是在开发过程中很容易忽略掉的,而且必须放在并发访问中才能出现的问题。另外,由于日志输出没做好,导致调试很费劲。简单描述下该问题:
三句话:
1)从连接池获取一个连接
2)将字符型数字转换为整型数字
3)获取连接,查询数据,释放连接
问题出现在第二句话上,当第二句转换失败抛异常时,并未被处理,而是直接抛回给上层调用方法,所以,连接更本就不会被释放掉,就出现了资源枯竭,死锁的状态。
总结下:
真应该好好学习java啊  多线程  异常处理和异常处理对于程序的影响  程序执行流程  动态代理  线程池死锁 还有什么链接生成、关闭  如何查看resin堆栈信息 
先把异常处理 和 适当输出日志 弄好,这个是靠经验的!
 

Hadoop map和reduce的个数

一般情况下,在输入源是文件的时候,一个task的map数量由splitSize来决定的,那么splitSize是由以下几个来决定的
goalSize = totalSize / mapred.map.tasks
inSize = max {mapred.min.split.size, minSplitSize}
splitSize = max (minSize, min(goalSize, dfs.block.size))
一个task的reduce数量,由partition决定。
在输入源是数据库的情况下,比如mysql,对于map的数量需要用户自己指定,比如
jobconf.set(“mapred.map.tasks.nums”,20);
如果数据源是HBase的话,map的数量就是该表对应的region数量。
map和reduce是hadoop的核心功能,hadoop正是通过多个map和reduce的并行运行来实现任务的分布式并行计算,从这个观点来看,如果将map和reduce的数量设置为1,那么用户的任务就没有并行执行,但是map和reduce的数量也不能过多,数量过多虽然可以提高任务并行度,但是太多的map和reduce也会导致整个hadoop框架因为过度的系统资源开销而使任务失败。所以用户在提交map/reduce作业时应该在一个合理的范围内,这样既可以增强系统负载匀衡,也可以降低任务失败的开销。
1 map的数量
map的数量通常是由hadoop集群的DFS块大小确定的,也就是输入文件的总块数,正常的map数量的并行规模大致是每一个Node是10~100个,对于CPU消耗较小的作业可以设置Map数量为300个左右,但是由于hadoop的没一个任务在初始化时需要一定的时间,因此比较合理的情况是每个map执行的时间至少超过1分钟。具体的数据分片是这样的,InputFormat在默认情况下会根据hadoop集群的DFS块大小进行分片,每一个分片会由一个map任务来进行处理,当然用户还是可以通过参数mapred.min.split.size参数在作业提交客户端进行自定义设置。还有一个重要参数就是mapred.map.tasks,这个参数设置的map数量仅仅是一个提示,只有当InputFormat 决定了map任务的个数比mapred.map.tasks值小时才起作用。同样,Map任务的个数也能通过使用JobConf 的conf.setNumMapTasks(int num)方法来手动地设置。这个方法能够用来增加map任务的个数,但是不能设定任务的个数小于Hadoop系统通过分割输入数据得到的值。当然为了提高集群的并发效率,可以设置一个默认的map数量,当用户的map数量较小或者比本身自动分割的值还小时可以使用一个相对交大的默认值,从而提高整体hadoop集群的效率。
2 reduece的数量
reduce在运行时往往需要从相关map端复制数据到reduce节点来处理,因此相比于map任务。reduce节点资源是相对比较缺少的,同时相对运行较慢,正确的reduce任务的个数应该是0.95或者1.75 *(节点数 ×mapred.tasktracker.tasks.maximum参数值)。如果任务数是节点个数的0.95倍,那么所有的reduce任务能够在 map任务的输出传输结束后同时开始运行。如果任务数是节点个数的1.75倍,那么高速的节点会在完成他们第一批reduce任务计算之后开始计算第二批 reduce任务,这样的情况更有利于负载均衡。同时需要注意增加reduce的数量虽然会增加系统的资源开销,但是可以改善负载匀衡,降低任务失败带来的负面影响。同样,Reduce任务也能够与 map任务一样,通过设定JobConf 的conf.setNumReduceTasks(int num)方法来增加任务个数。
3 reduce数量为0
有些作业不需要进行归约进行处理,那么就可以设置reduce的数量为0来进行处理,这种情况下用户的作业运行速度相对较高,map的输出会直接写入到 SetOutputPath(path)设置的输出目录,而不是作为中间结果写到本地。同时Hadoop框架在写入文件系统前并不对之进行排序。
http://blog.sina.com.cn/s/blog_4439f9310101bxss.html

hadoop客户端该如何配置

Hadoop集群主要是由三部分组成的:主节点、从节点和客户端,即master、slave和client。我们在搭建hadoop集群的时候通常只考虑了主节点和从节点的搭建,却忽略了客户端。当我们搭建完成后,我们在其中的一台机器上运行wordcount或者计算π时,实际上我们已经默认将一台主节点或者一台从节点当做客户端来使用了,但是,如果我想把客户端独立,该如何单独配置客户端呢?
答案其实很简单,只要在配置slave的时候,不要把客户端添加到slave里,即客户端和hadoop集群其他的节点配置是一摸一样的,但不参与运算
完整的hadoop集群搭建过程,请参考:《Hadoop集群搭建详细简明教程》

slave配置

slave配置

行存储和列存储比较–理解hbase的基础

目前大数据存储有两种方案可供选择:行存储和列存储。业界对两种存储方案有很多争持,集中焦点是:谁能够更有效地处理海量数据,且兼顾安全、可靠、完整性。从目前发展情况看,关系数据库已经不适应这种巨大的存储量和计算要求,基本是淘汰出局。在已知的几种大数据处理软件中,Hadoop的HBase采用列存储,MongoDB是文档型的行存储,Lexst是二进制型的行存储。在这里,我不讨论这些软件的技术和优缺点,只围绕机械磁盘的物理特质,分析行存储和列存储的存储特点,以及由此产生的一些问题和解决办法。
一.结构布局
行存储数据排列

行存储

行存储


列存储数据排列
列存储

列存储


表格的灰色背景部分表示行列结构,白色背景部分表示数据的物理分布,两种存储的数据都是从上至下,从左向右的排列。行是列的组合,行存储以一行记录为单位,列存储以列数据集合单位,或称列族(column family)。行存储的读写过程是一致的,都是从第一列开始,到最后一列结束。列存储的读取是列数据集中的一段或者全部数据,写入时,一行记录被拆分为多列,每一列数据追加到对应列的末尾处。
二. 对比
从上面表格可以看出,行存储的写入是一次完成。如果这种写入建立在操作系统的文件系统上,可以保证写入过程的成功或者失败,数据的完整性因此可以确定。列存储由于需要把一行记录拆分成单列保存,写入次数明显比行存储多,再加上磁头需要在盘片上移动和定位花费的时间,实际时间消耗会更大。所以,行存储在写入上占有很大的优势。
还有数据修改,这实际也是一次写入过程。不同的是,数据修改是对磁盘上的记录做删除标记。行存储是在指定位置写入一次,列存储是将磁盘定位到多个列上分别写入,这个过程仍是行存储的列数倍。所以,数据修改也是以行存储占优。 数据读取时,行存储通常将一行数据完全读出,如果只需要其中几列数据的情况,就会存在冗余列,出于缩短处理时间的考量,消除冗余列的过程通常是在内存中进行的。列存储每次读取的数据是集合的一段或者全部,如果读取多列时,就需要移动磁头,再次定位到下一列的位置继续读取。 再谈两种存储的数据分布。由于列存储的每一列数据类型是同质的,不存在二义性问题。比如说某列数据类型为整型(int),那么它的数据集合一定是整型数据。这种情况使数据解析变得十分容易。相比之下,行存储则要复杂得多,因为在一行记录中保存了多种类型的数据,数据解析需要在多种数据类型之间频繁转换,这个操作很消耗CPU,增加了解析的时间。所以,列存储的解析过程更有利于分析大数据。
三. 优化
显而易见,两种存储格式都有各自的优缺点:行存储的写入是一次性完成,消耗的时间比列存储少,并且能够保证数据的完整性,缺点是数据读取过程中会产生冗余数据,如果只有少量数据,此影响可以忽略;数量大可能会影响到数据的处理效率。列存储在写入效率、保证数据完整性上都不如行存储,它的优势是在读取过程,不会产生冗余数据,这对数据完整性要求不高的大数据处理领域,比如互联网,犹为重要。
改进集中在两方面:行存储读取过程中避免产生冗余数据,列存储提高读写效率。
如何改进它们的缺点,并保证优点呢?
行存储的改进:减少冗余数据首先是用户在定义数据时避免冗余列的产生;其次是优化数据存储记录结构,保证从磁盘读出的数据进入内存后,能够被快速分解,消除冗余列。要知道,目前市场上即使最低端CPU和内存的速度也比机械磁盘快上100-1000倍。如果用上高端的硬件配置,这个处理过程还要更快。
列存储的两点改进:1.在计算机上安装多块硬盘,以多线程并行的方式读写它们。多块硬盘并行工作可以减少磁盘读写竞用,这种方式对提高处理效率优势十分明显。缺点是需要更多的硬盘,这会增加投入成本,在大规模数据处理应用中是不小的数目,运营商需要认真考虑这个问题。2.对写过程中的数据完整性问题,可考虑在写入过程中加入类似关系数据库的“回滚”机制,当某一列发生写入失败时,此前写入的数据全部失效,同时加入散列码校验,进一步保证数据完整性。
这两种存储方案还有一个共同改进的地方:频繁的小量的数据写入对磁盘影响很大,更好的解决办法是将数据在内存中暂时保存并整理,达到一定数量后,一次性写入磁盘,这样消耗时间更少一些。目前机械磁盘的写入速度在20M-50M/秒之间,能够以批量的方式写入磁盘,效果也是不错的。
四. 总结
两种存储格式各自的特性都决定了它们不可能是完美的解决方案。 如果首要考虑是数据的完整性和可靠性,那么行存储是不二选择,列存储只有在增加磁盘并改进软件设计后才能接近这样的目标。如果以保存数据为主,行存储的写入性能比列存储高很多。在需要频繁读取单列集合数据的应用中,列存储是最合适的。如果每次读取多列,两个方案可酌情选择:采用行存储时,设计中应考虑减少或避免冗余列;若采用列存储方案,为保证读写入效率,每列数据尽可能分别保存到不同的磁盘上,多个线程并行读写各自的数据,这样避免了磁盘竞用的同时也提高了处理效率。 无论选择哪种方案,将同内容数据聚凑在一起都是必须的,这是减少磁头在磁盘上的移动,提高数据读取时间的有效办法。
行存储列存储

行存储列存储


http://www.infoq.com/cn/articles/bigdata-store-choose