grep用法

grep是一个常用的命令。
以前只知道^$.+?*这些用法。以及-E的正则表达式。

今天偶然发现还有一些更高级的匹配模式。具体如下:

[:alnum:]    字母与数字字符
[:alpha:]    字母
[:ascii:]    ASCII字符
[:blank:]    空格或制表符
[:cntrl:]    ASCII控制字符
[:digit:]    数字
[:graph:]    非控制,非空格字符
[:lower:]    小写字母
[:print:]    可打印字符
[:punct:]    标点符号字符
[:space:]    空白字符,包括垂直制表符
[:upper:]    大写字母
[:xdigit:]    十六进制数字

还有一些常用的就是
{n}            必须匹配n次
{n,}        必须匹配n次或n次以上
{n,m}        必须匹配n到m次,包含n和m

下面我们进行简单的测试下就知道了
文本内容如下test.txt

A novel is a book of long narrative in literary prose

The genre has historical roots both in the fields of the medieval and early modern romance and in the tradition of the novella

The latter supplied the present generic term in the late 18th century.

Further definition of the genre is historically difficult.

The construction of the narrative, the plot, the way reality is created in the works of fiction.

Most of these requirements were introduced in the 16th and 17th  centuries in order to give fiction a justification outside the field of  factual history.

The individualism of the presentation makes the  personal memoir and the autobiography the two closest relatives among  the genres of modern histories.
grep a[[:blank:]] test.txt

5561066808_a504984507_z.jpg

grep -E [a-z]\{10\} test.txt

5561066804_ae4c0ebe60_z.jpg

grep Th.[[:space:]] test.txt

5561066798_fb5625ab54_z.jpg

###########################################

Best regards
Timo Seven
blog:http://www.timoseven.com
twitter: http://twitter.com/zauc
Linux System Admin  & MySQL DBA

厉建宇的阿里巴巴离职信

厉建宇是美籍华人,好多观念上跟我们有很大的不同。

下文就是他之前要离开阿里巴巴留下的离职信。回顾了他在蓝讯和阿里巴巴的路程。本文也展现了他的一些工作理念,应该说跟着这样的领导还是跟对人的。也许这就是google之所以伟大的原因中的一点:简单。 

中文不佳,全用英文写又无法让更多的同学了解我的心路旅程,所以请各位原谅我蹩脚的中文。

*一个简单的道理:一块2TB桌面级硬盘今天的价格约为700元,相同大小的企业级硬盘一块今天的要价仍然超过1,500元,这两个硬盘最大的差别是RVI震动率的设置(因此,桌面级硬盘在震动率稍大的时候,依然能够正常工作,企业级硬盘为了提升可靠性,所以当震动略大的时候,会停止工作,保护磁盘),两者连螺丝的位置都相同(不是用于固定硬盘的螺丝,是用于固定磁盘内部机构的螺丝),我们假设硬盘仍然坚守摩尔定律(每18个月容量增加一倍),一年半后就算我们需要更换所有的桌面级硬盘(注),我们还可以做到用相同的成本,获取两倍的存储容量!四年半后,我们将以同样的价格拥有四倍的存储!加上半导体制程的进步,当固态硬盘开始取代机械硬盘(约计在2015年前后发生),我们服务器的性能和效率能将再上一个台阶(每块SSD可以提供250MB/s吞吐量,而且只有2.5英寸(SFF),一台2RU的服务器可以配置24个SFF的服务器,也就是6GB的吞吐量,这也就不难解释为什么2012年开始销售的服务器会配置两个万兆以太网端口了)!

*成本!成本!成本!:我为什么放弃在ChinaCache的股权,回到美国求职呢?那是因为作为CTO,我没有阻挡我的CEO快速扩张视频分享下载(FLV)这条业务线,结果,到2008年中,当土豆在投资者(VC)的降低成本的要求下,自建CDN设施的时候,Chinacache的业务一下子下降了60%,几个月前刚刚购买的交换机和服务器都必须折价出售,最糟糕的是还找不到买家,IT设备的价格是天天掉价的!倘若当初CEO拒绝10%股权赎回的诱惑(VC要求业绩必须连续两年出现100%增长),将发展FLV业务的经费投资在集群效率的优化,那么ChinaCache就可能可以用更低的成本提供FLV下载的业务,加上时段复卖及规模效应,就可以将FLV下载业务的销售价格低于土豆(自建CDN)的成本价,土豆,优酷等视频分享业者也就不会在VC的压力下建设自己的FLV下载基础设施。两个月发不出薪水给普通员工啊!你们一定能够体会那种痛苦,我堂堂一个中国互联网骨干设施的先期建设者,居然要靠砸锅卖铁来等待VC的bridge loan来渡过那艰难的三个月,所以我把股权给了留下来的同事(不知道CEO有没有执行这个意愿),自己回到美国求职。相同的道理,阿里巴巴在过去十年,凭借优秀的商务模式,占据80%的电子商务市场,但是,业务模式创新的速度已不如前十年,同质竞争的压力又不断地增加………一种似曾相识的感觉涌上心头:2000年之后,思科分别在两个阶段受到来自Juniper和华为的追赶,ChinaCache只不过将类似的问题集中在一年之内爆发,所以,当这样的问题来临是,无论你请什么人来,都救不了这样的企业。

*新商业文明 – 谈厂商和用户之间的关系 (扭曲化的结果就是贿赂,无意义的折扣),电子商务在解决供需的问题,我们也应该用相同的概念来解决我们基础设施的问题。讲实在话,阿里巴巴和国有电信运营商采购的腐败就只有一步之远!如果厂商在我们团建时提供一桌四千元的晚餐,我们这些月薪一万元的SA工程师,怎么能够不嘴软呢?如果团建经费再多一点,如果厂商招待费放开一点,我们的工程师需要厂商那一点点小恩小惠吗?

*思科让我回去做主管EC3(企业级云计算),华为让我进入CTO办公室主管云计算业务,我都没同意,它们的薪水可都是高出阿里巴巴三倍的薪水!我想留下来,就是马总的一句“国有”企业 — 一个真正意义的公用事业!另外,是谁鼓励土豆,优酷建设自己的FLV基础设施呢?我怎么可能跟这些砸了我的事业的人再继续合作呢?这些设备厂商唯一想的事情就是让你多买一些,至于你能不能高效应用这些设备,它们才不关心呢!地球明天会不会因为Global warming而变得风雨无常,你的公司会不会因为低效而面临经营的困难都不是它们考虑的问题,因为他们只关系自己的荷包是不是够满,是不是够钱能够买一部Audi R8 Spyder,明天会不会因为业绩不佳而被裁员…………

我愿意和Intel合作,是因为它总是能告诉我产业发展的方向,我愿意和英业达,富士康,广达,锐捷合作,因为它们总是能够非常快速的反映我们的需求(直接帮助提升我们服务器的效率),我们甚至做到让这些厂商提供原材料的价格(BoM cost),让它们自己提它们认为合理的利润,借此建立一种可持续发展的合作关系。可是,每一次一到采购,我们这些策略就执行不下去(总是买Dell,Huawei品牌的商用服务器),我也没脸再跟ODM厂商要求开发新的机种(一个原因是厂商没有因为前期研发的付出而获利,另一个原因是2011年项目没有获得支持,所以研发经费为0)。

就算在中国电信,也知道采购部门必须和需求部门分离,就这样还不能阻挡腐败的发生,我们阿里云却把运行维护,计划建设,采购放在同一个VP下,虽然这么做有助于解决(小)部门KPI被过份放大的问题,但是这三个部门合在一起,许多Check & Balance就消失了,结果当然不是以阿里巴巴的利益为优先,更不要提公用事业这个伟大的理想了!

*我为什么不愿再继续写代码 – 这几个月为了提升服务器的性能,我每天工作到半夜,连续了三四个月,在代码的世界里,我很快地就找到了自己,很快地就能够有一些成就感,特别是捡起15年没有再读过的TCP内核代码,我很快乐我能够找出它在LFN(高性能,高延迟(缓存))的不足,但是,做这个工作我只能带动几位工程师,做绿色数据中心,我却能够带动整个中国的互联网基础设施工业,这就是我为什么不愿意再继续写写代码,而是希望能够去改变一个产业。

注:厂商提供的桌面级硬盘的质保也是三年,而根据Google提供的数据,硬盘的年损坏率略低于4%,生命周期内损坏率约为8.6%,也就是说90%硬盘都能够工作三年,而不是一年半,那么一块硬盘差800元,12块硬盘就是10,000元,11,000台12盘的服务器三年的成本就节省一亿元人民币,这一亿元人民币难道不够让我们请10个高级系统工程师(三万元一个月也就是一亿元的10%),,将我们硬盘跟换的流程优化,所以他们就不必每次跟换硬盘的时候都必须工作到半夜12点?

########################################### 

Best regards
Timo Seven
blog:http://www.timoseven.com
twitter: http://twitter.com/zauc
Linux System Admin  & MySQL DBA

昨日一天跟房子干上了

今天一天跟房子干上了。

http://www.soufun.com/house/zt/201102/312kft.html这个是当初是报名的网址。

地址,当初这上面可是写好有午餐和礼品,可一天下来什么都没有,还好之前出门的时候带了点吃的,不然今天可是饿着肚子了。搜房网你去死吧。整的什么团阿,看来开发商给你的钱是少了,不然你怎么会这样抠门呢。还是你自己都私吞了。本来我参加这种活动就是奔着这些小礼品去的,就跟上次去参加MSN车友会一样,吃吃饭,开开卡丁车,中中奖。而这次搜房网看房团居然什么都没有,要啥都没有我参加看房团干嘛? 给你做活广告? 你们也就这点小心思。北苑又不是不认识,也不是太远。祝愿你们股票早日跌到1美元以下直接退市。
5522099370_d146995f9d_z.jpg

早上参加了搜房网北一路线的看房团,主要是北苑那边3个楼盘。第一个什么天润福熙大道只有TMD尾房,在北苑这种地方还建高端住宅,旁边一排高压线,真正有钱人会买房住在高压线旁边? 不知道是不是开发商拿地价格太高。宣传单上写着2W6一平,怎么到你们嘴里就是3W1一平了呢。后面的世华泊郡价格也一般,2W5单价,就开2栋楼,看来大的开发商都喜欢搞饥饿销售。周边环境实在是太差了。而最后一个筑花年连价格和开盘时间都没定呢,样板间也没有。户型就一种,看来开发商都把买房的当傻子来看了。大家都在观望着。我同样也观望着。

今天路上还碰到好多摆摊的中介,号称请听政策分析。看来中介们好想找人聊聊天啊。

后来又坐地铁是拿退房的钱去了,汗,手续都走完了还要经过20个工作日才能打到卡里,这些开发商都真够黑的。看到财务那边一堆退房的单子。接着去看了红木林。红木林户型倒是挺多,但是同样也是没有样板间,不过好户型我看下来就一种。要到5月份才有样板间,所以还是到时候再说吧。今天就先排个VIP号。之前还让这边的亲戚关注下说开盘了告诉我一声,结果也没有通知,还好问了下销售。

从现在来看也就远洋一方从户型和位置上还不错,只是价格稍贵,我看上的那个户型均价22000呢。比其它的户型都贵,要是再打个8折啥的就好了。那边都快靠近通州了,也就值这个价格吧。当然当初2W5均价买的那些人闹事算不算是开发商的策略呢? 现在谁不知道一方降价打折呢。

而且这当中发现好多违规的东西,住建委不是要客户首付款在房屋封顶前都存在住建委专用账户上,可看了半天好像就远洋一方是这样干的,而其它楼盘都是存到开发商自己的账户。这不是很明显的违规吗,可销售说了这个都是很正常的。看来大多开发商都是缺钱的。同志们再摒摒吧,等开发商更缺钱的时候房价才会腰斩呢。

###########################################

Best regards
Timo Seven
blog:http://www.timoseven.com
twitter: http://twitter.com/zauc
Linux System Admin  & MySQL DBA

nginx的问题(续)

昨天说了nginx的几个问题,

由于我现在支持的主要是通用CDN,也就是小图片和CSS以及JS这些东西,并没有做大文件的cache。而问了我们视频部门他们也根本不用nginx作为cache使用,所以有些问题还是没考虑周到。

一个问题是之前发现的,在做tmpfs的时候,当你设置的cache大小为tmpfs的90%的时候,一旦要缓存的内容大于这个90%的时候,nginx会自己崩溃掉。这个我明天做个测试再重现一下,现在有点忘记原因了,好像是tmpfs会占用到实际的磁盘才导致的。

另外一个其实是upstream的问题,这个是一个新浪的老兄提的,基本现在是无解。问题是:比如平均一个文件10M,你在磁盘上存3000个文件,然后模拟多个客户端去访问,因为shm一开始是空的,所以都会去后端拽文件,我们放慢这个拽的过程,比如说网络不好吧 呵呵,那么第一个请求发现不在lookup失败,就会去upstream取数据,边取边向downsteam发,并且存在一个临时文件中,这时第二个请求来了也请求这个文件,因为第一个请求没有处理完,所以第二个请求找不到目标文件只好继续去后端拽,又生成临时文件,并发量大的时候,一个大文件会对应N多的临时文件,最终这些文件rename到一个目标文件,大大浪费了磁盘IO。这个rename是内核做的,nginx调完之后就返回了。这种问题往往会导致内部网络流量非常大,而实际却没有根本没有大。

当有多个连接来获取同一个文件的时候,squid中却没有跟nginx cache一样的问题。我们看看squid是怎么解决的吧。我们在squid有这样一个参数collapsed_forwarding on(http://wiki.squid-cache.org/Features/CollapsedForwarding),一旦设置了参数了,当发现有连接请求同一个文件的时候,squid会合并多个连接,但是它会以最慢速的那个连接去取,然后同步地传送给客户端。这样就不会重复请求后端了。但是squid也有问题,因为首先它是同步的。当用户请求的是动态的内容的话会导致客户端错误。而且当一个用户连接速度很快,一个用户连接速度很慢,那就会以最慢的速度进行获取和传输。所以在squid3.0以后取消了这个参数。

这个问题的解决办法暂时看起来只能在nginx cache前充一下热点的大文件。还好一般内网都是千兆连接,这个速度往往大于用户的连接速度。只有当文件特别大,并且热点文件特别多的情况下才会发生。而且nginx这种处理方式也有一定的好处。

nginx upstream流程我们可以参考http://bollaxu.javaeye.com/blog/900424http://bollaxu.javaeye.com/blog/900357这2篇文章。基本是由于nginx upstream为了防止锁所以进程间是不共享的。

###########################################

Best regards
Timo Seven
blog:http://www.timoseven.com
twitter: http://twitter.com/zauc
Linux System Admin  & MySQL DBA

nginx cache现有的几个问题

在我这边现实环境中主要是有三个问题。

第一个问题是当cache过期的时候,nginx会把cache状态设置为updating,但是这个updating却没有设置一个超时,所以导致的情况当一个cache过期的时候好多nginx会连接到源站取数据,而如果源站并发量有限的话,会导致源站突发负载过高,而这个时候导致nginx一直处于updating过程中,如果导致源站挂掉的话,那完蛋了。当然我们也可以设置proxy_cache_use_stale updating;但是这样会导致cache的内容不准确。

解决的方法有2种,一个是我们现在更改nginx源码,使之可以updating设置有超时时间,这样不会导致长时间连接源站造成拥塞。另外一种就是nginx cache分层,分为父节点和子节点,只有父节点才会去源站更新,子节点只从父节点上更新。

第二个问题是upstream中server的状态,我们知道upstream中可以设置proxy_next_upstream当一个服务器挂掉后自动转到其它的服务器上,但是这里有个问题就是让用户访问的时候proxy会每次都会先访问下这个坏的服务器,连接不通了再转到其它服务器上,这每次都要测试会浪费大量的时间。我们需要得到的是proxy会独立一个线程去检查后端服务器,一旦发现后端服务器挂掉的话,那直接从upstream中剔除掉这个服务器就可。而等检测后端服务器又存活了再加进来。

这个现在有ngx_http_healthcheck_module这个第三方模块。具体可以参考http://wiki.nginx.org/HttpHealthcheckModule

第三个问题是nginx proxy连接nginx cache的时候居然使用的是http1.0的,而不是http1.1,就没法使用keepalive连接后端,导致我们小文件的cache服务器连接数过高,而没法进行复用链接。

这个暂时还没有解决,不过看到http://wiki.nginx.org/HttpUpstreamKeepaliveModule这个第三方模块,但是实际还没有测试过,没法做什么结论。

其实大家可以完全查看http://wiki.nginx.org/3rdPartyModules 来看看是否针对自己的应用,有些还是我们国人自己开发的,但是针对第三方模块还是要谨慎使用,上面的healthcheck模块还是经过我们自己的开发重新修改后并进行压力测试后再上线的。开源就是这点好啊。看来我要得学习学习C语言编程来,以后自己也改改增加增加功能啥的。

###########################################

Best regards
Timo Seven
blog:http://www.timoseven.com
twitter: http://twitter.com/zauc
Linux System Admin  & MySQL DBA

mysql读写分离

Mysql读写分离


首先我们必须知道为什么要分离。这个一般是由于以下原因导致的。

  1. 性能,单台数据库实在是撑不住了
  2. HA,防止单台数据库挂掉造成应用不可用
  3. 扩展,由于业务新增了新的需求

以上几种是我们常见的要进行分离的原因。其中做多的可能是第一和第二种。这个主要还是涉及到钱和服务器的数量上。一般业务都会在前端部署更多的服务器,而在最后端的数据库服务器往往比较少。但是对于好多web2.0 UGC这样的业务的网站还是有必要重视后端的速度和稳定性。

 

分离的多种方案

  1. query proxy,这个一般是由单独的服务器来进行的,由它负责这个sql语句路由到哪个服务器上。这种proxy的话最好还是要建立HA方式,不然这个proxy就是一个单点故障。这个在之前人人的系统中就是如此,虽然只是负责发起查询的时候建立真实mysql服务器和应用服务器连接,但是还是比较危险的。
  2. Load balance, 后面一堆服务器,通过轮寻的方式来访问mysql服务器。这个很多时候是通过内部DNS来实现。

 

分离的多个原则

  1. 根据内容进行分离,针对某个表或者某个库的查询到哪个服务器上。这个其实就是数据库分区的概念。这个在之前的人人系统中我们也经历过从单台数据库服务器,最终分离出所有的应用到单独的数据库中,并且都有了单独的服务器。这样一旦服务器出现问题,也只会影响到单独的应用,而不会是全部的应用都不可用。
  2. 根据后端mysql服务器的状态,当第一台服务器到达某个标准状态时候再请求到第二台服务器上。这种原则容易造成第一台服务器长时间的高负载运行。
  3. 根据session分离,根据session和后端服务器的映射表来分离。这个对于proxy的要求比较高,需要在内部存储这样一个映射表,并且要可以实时进行更新映射表。

 

现有的问题

  1. 有多个写,这个现在有双MASTER的方案。多个分区的也会总有一个master实在忙不过来的时候,特别是web2.0网站的UGC内容。对于cms系统来说完全没有必要。
  2. 没有session隔离,这个有可能导致查询到的数据不准确。这个就是如何保证用户刚提交内容后马上看到提交后的结果。这个之前在人人某个网页游戏中发生过类似事情,在程序中update数据后立刻去读数据库。但是实际上是updatemaster数据库,但是select查询的是slave数据库。后面我说到seconds_behind_master这个时间并不准就是这里,虽然seconds_behind_master=0但是还是不能在master做了update后可以实时的传导到slave上啊。
  3. 需要用到内部DNS,或者hosts文件来进行调度。

 

这种分离导致的问题

  1. 导致问题的复杂,一个简单的update语句会导致所有的相关数据库服务器进行update
  2. 导致过多的读写,slave方案的最大问题就是在master服务器上的写同样会传导到slave服务器上,同时slave服务器还要支持读。

 

现在我们在mysql5.1以上的版本中使用行复制,但是这个现在还不是很成熟。

不要相信show slave status\G;中的seconds_behind_master,这个在实际中并不太准确。

 

之前我用到的几种query proxy

  1. 一种是比较山寨的方法,让程序员在在代码中嵌入,insert, update这种语句直接连接master服务器,而select直接连接到slave服务器。在多个slave服务器之前使用haproxy进行调度代理。这种方法的缺点是,当业务调整,或者服务器IP更改后还要去修改DNS服务器去,同时还得寄希望于程序中没有把insert这种语句没有一个指向slave服务器上。当然优点就是部署简单。
  2. mysql proxy: 这个貌似很官方的,但是配置语法较麻烦,容易弄错,自己没有实践过,周边同事实践后感觉不好。
  3. 最后一种是人人正在使用的。是完全自己做的,用的是ICE框架。直接一个单独的配置文件进行配置就可。配置文件的主要内容是instance名字,数据库名,数据库IP地址,读还是写,还是读写都可。这个东西使用方式对于程序员来说很简单,它只要知道连接哪个数据库用什么instance名字就可,不需要知道其他任何信息。其它信息(读写方式,数据库地址等等)都是靠这个中间层来确定的。同时对于这些信息都会缓存在应用程序本地,以后不用再次请求中间层,而是直接连接对应的数据库就可以了。第一次应用程序请求的时候会请求到中间层,中间层返回对应的数据库地址和名字以及数据库的用户名密码等信息,然后应用程序使用这些信息来连接数据库,而第二次请求的时候就直接连接数据库了。但是这个系统的问题是每个应用程序本地都要知道这个中间层的地址,每次修改中间层的配置文件后都要重新reload下通知所有应用程序下次请求都要先请求下中间层,无论修改的配置跟你这个应用程序有没有关系。

###########################################

Best regards
Timo Seven
blog:http://www.timoseven.com
twitter: http://twitter.com/zauc
Linux System Admin  & MySQL DBA

我家的狗狗–第二季

小时候就一个圆脑袋
5497042054_2365cbc2ae_z.jpg

干嘛你要看着我呀?
5497042066_a06d105bb6_z.jpg

我也喜欢长啸几声
5496458279_e7699d25f2_z.jpg

我们长大了哦
5496458297_85a6485050_z.jpg

我们就爱趴着
5497065290_baa66a1698_z.jpg

我也来点朦胧的
5497065310_dbb69397f3_z.jpg

有时候我也思考东西
5497077884_7709db9780_z.jpg

也有惆怅的时候
5497065300_6ab69e5831_z.jpg

这么多愁善感当然是女孩拉,但是我不喜欢这个造型
5497065296_ae22072506_z.jpg

有时候我也来点摇滚的风格
5497077896_ccb004ae32_z.jpg

我就是不喜欢穿衣服,那就意味着我要出门了
5497077906_c50a40ffa7_z.jpg
###########################################

 

Best regards
Timo Seven
blog:http://www.timoseven.com
twitter: http://twitter.com/zauc
Linux System Admin  & MySQL DBA