企业IT的2.0革命

随着移动和云计算的普及,企业2.0,或者说的企业IT消费化变革正在成为重塑企业IT市场的一股颠覆性力量。相比财大气粗的主流企业IT厂商,创业公司们胜在基因。

近日Madroina投资集团的Matt Mcllwain在Gigaom撰文指出:

与过去30年个人电脑时代的企业级计算模式不同,今天员工手中的消费技术正在重新定义企业级计算的构建与使用方式。员工使用个人设备(BYOD),个人应用(BYOA)大量免费云服务以及企业级开源软件正引发企业级IT的一次重大变革。

三十年前,那些雄心勃勃的员工把个人电脑带到办公室,替换掉蠢笨的UNIX小型机和主机终端。当年这些知识工人使用的PC应用,包括 Visicalc,Lotus 1-2-3和Harvard Graphics,将计算力赋予个人,极大地改变了工作方式,开启了企业1.0时代。

如今,我们看到又一次重大的范型转换,各行各业的员工们都开始从云端的应用商店选择他们所要使用的各种应用和工具,从文件分享到人力资源应用都是如 此。只要在应用商店点击两下,支付一小笔钱,员工就能立刻拥有他们想要的工具和应用来解决问题,而不是通过企业IT部门,这,就是所谓企业2.0最显著的 特征。

员工翻身做主人

在企业1.0时代,员工使用的应用和终端都归企业IT部门集中化管理,而今天,随着智能终端、移动应用、实时协作通讯服务的极大丰富,App Store式的应用消费文化已经深入新一代员工的人心。消费IT的快速更新、优秀的用户体验以及易用性已经成为企业IT必须学习的对象。

今天的员工拥有越来越多的应用话语权,随着消费应用的渗透,企业应用的选型、部署和分发越来越去中心化,而企业IT部门的管理方法也从过去的集中式向协调式演变。

过去数十年中,企业IT的创新被PC生态圈的几个少数领导者把持,而如今,通过员工手中的消费终端和应用,企业IT的创新源动力来自所谓的企业 2.0创业公司,而企业员工,也正在从过去的企业IT的被动的接受者和学习者变成了批评者和建议者,甚至,他们开始采取行动在团队甚至部门内开始部署自己 的企业2.0应用。

新商业模式让创业公司变得空前强大

上述企业2.0用户行为模式和需求的变化还将改变企业级技术方案的交付方式。旧的,许可证销售模式让位于订阅模式。过去大的技术厂商订单金额巨大,拥有规模经济优势,但如今随着新的应用部署和分发的模式的流行,新的企业2.0创业公司拥有更好的发展机会。

如今,创业公司们通常选择Freemium模式(免费试用),能够以APP运营的模式快速迭代,快速创新。通过社交媒体等新的沟通渠道,创业公司能与用户直接互动,快速获得反馈。通过实时分析技术,他们能看到用户喜欢试用应用中的哪些功能,并灵活对产品或服务进行修改。

创业公司还将薄利多销、细水长流的消费应用盈利模式引入了企业IT,并收到了市场和投资者的广泛欢迎。

反观传统企业IT供应商,在企业2.0市场,他们面临严峻的挑战,过去数十年围绕技术(服务器、存储、网络等)类别进行的,自上而下的销售模式显然 不适用企业2.0市场,这些IT供应商需要自我颠覆,从头建立新的产品和销售模式,但这谈何容易。这也给企业2.0创业公司留下极好的机会。

不难理解,为什么近期上市的企业2.0创业公司如Splunk、ServiceNow和Tableau等,会受到华尔街投资者的狂热追捧,而大量风险投资如潮水般涌入新的企业2.0创业公司。

未来五年,今天的的企业IT厂商们需要将他们的产品开发模式打断经脉重来,拼上几年难看的财报也要培育出新的占领市场的方法和竞争力,否则将被无情的边缘化,这个过程非常艰难,风险巨大,有人称之为“创新者的困境”。

360wifi评测

评测了百度的小度wifi,怎么能不在玩玩360的小wifi?

360wifi-1

 

从颜色上看,有茶婊绿,武藤蓝,大便黄还有高级黑,土豪金 等等,这点就比小度wifi色彩斑斓多了。

今天入手的是个雪白滴。

IMG_20131119_135448

 

看起来没有什么特别之处,拆开来看看吧。

IMG_20131119_135637

 

包装没有什么特别的,和小度一样,有点不同的是有一个耳机的防尘塞,这边看起来比小度贴心一些,小赞一下。

接下来的事情也平淡无奇,无非就是按照流程去下载驱动,然后插入上网了。驱动下载 http://wifi.360.cn

然后就是安装那些事……

360wifi-2 360wifi-3 360wifi-4 360wifi-5

 

连接起来使用的感受和小度一样,几乎没有区别,唯一的不同就是360没有什么文件和影音互传,不过从实用的角度来说,使用的概率也不是很大,所以只能说难分伯仲吧,从价格上的差别来说更是小到可以忽略了,至于想使用那一款,我觉的无非就是品牌的认可度了:)

玩转百度云盘

曾记得当年金山那货神神秘秘的搞出来1T盘的时候,让多少屌丝激动的一米,我承认当年我也屁颠屁颠的每天去摇那个推广码,然后给大家分享。

后来金山没有信用的将1T盘用户全部降到了20G,虽然给我10G我也用不完,但是心中却是不爽,不过好像扯远了……

这里悄悄告诉大家一下怎么玩转百度网盘的小技巧吧,哈哈哈,顺便在鄙视一下金山 哼~

首先,你的有个盘吧,不知道的可以去http://pan.baidu.com/自己申请,这里不多说了。

然后有了盘你就可以上传,下载你的文件了,如果说这里就说完了,我想你肯定想拍死我。嗯接下来怎么搞呢?

屌丝技术宅的最爱,当然是要用技术改变生活,咳咳咳~

打开百度吧,为啥,不为啥,谁叫人家是百度呢?

p1

在搜索框上输入 site:pan.baidu.com  xxxx 至于找个人,你不认识我也不解释了。这里是指抛砖引玉。

然后你会发现很多好玩的东东……

p2

 

拿第一个举个栗子吧,11部合集,真大哇,我的云盘才3T -_-# 别抽我。点击进去。

p3

 

看到了哇,人家的种子呢,好人一生平安呐。还愣着干嘛,点击离线下载哇!

p4

 

哎呦,看起来好拉风的样子,等什么呢,麻溜地点击开始下载 come on!

p5

 

任务添加完成了,剩下来的就看百度的了,给力吧。

p6

 

速度还不错,秒杀!

p7

 

哎呦,罪过,罪过。 你要问我这有什么用呢?那就试试在线,也许能帮到你。

p8

 

每次看到他们我都满眼愤怒,你们呢,小伙伴们!这个小技巧就分享与尔等,请别问我名字,我叫雷锋!

高性能Web应用扩展

成功不可能一蹴而就,任何高性能、大规模的Web应用都是慢慢扩展而来。然而通往成功的路上从来不缺乏艰辛,这里为大家分享对扩展性影响最大的20个绊脚石以及避免之道。

Sean Hull是Heavyweight Internet Group的创始人兼高级顾问,拥有20年以上技术顾问相关经验,曾为多家知名机构提供咨询,其中包括The Hollywood Reporter、Billboard、NBC Universal、Zagats、Rent the Runway及ideeli,这些高速增长的公司每个月处理接近1亿的独立访客。Hull在Amazon EC2部署和Linux及MySQL性能上有着丰富的经验。巨大流量的处理需涉及多个方面,其中包括网站扩展性、业务连续性、安全及架构挑战等。近日,Hull分享了高性能Web应用打造的经验,剖析了扩展之路上20个最大的绊脚石。以下为译文:

1.  二阶段提交

通常情况下,当数据库中的数据发生改变时,它需要同时被写入内存和硬盘。当一个提交发生时,传统数据库需要负责数据在真实存储媒质上的持久化。牢记,内存的数据在崩溃或者重启后都会消失。即使数据已经在数据库中缓存,数据库仍然需要将其持久化到磁盘上,MySQL的二进制日志及Oracle的redo日志都符合这个要求。

通过MySQL集群或者类似DRBD(Distributed Replicated Block Device)或者Amazon Multi-AZ(Multi-Availability Zone)的分布式文件系统,提交并不仅仅是在本地发生,同时也在远端。二阶段提交意味着需要从远端得到反馈,鉴于网络及一些其它的延时,提交速度可能会被毫秒级的降低,仿佛高速公路上的所有汽车都因重载变慢。如有考虑使用Multi-AZ或者读备份,不妨查看Amazon RDS(Relational Database Service)与MySQL的比较。

同步复制同样会出现这些问题,因此MySQL解决方案是半同步的,这也可以看做是在二阶段提交上的一些让步。

2.  缓存不足

在所有层中缓存的作用都至关重要,那么什么地方最需要使用缓存:浏览器、页面、对象还是数据库存?下面不妨统统试一下。

浏览器缓存似乎遥不可及,除非你清楚浏览器是从Web Server中取出指令及其渲染的页面。因此,如果包含的对象有一个比较长的生命周期,浏览器将会缓存他们,不需要再次进行读取。这不仅会加快用户的浏览速度,同样会有益于Server对网站的托管,因为会切实的减少用户的二次读取。

猛戳这里查看更多浏览器缓存相关,确保设置了期满头文件及缓存控制。

页面缓存需要使用类似Varnish的技术,可以将它看成一个迷你的高速、低开销Web Server。它不可以支撑类似Apache可以的复杂页面,但是它可以让非常简单的页面更快。因此位于Apache之前,用于减少负载,让Apache可以处理更加复杂的页面。就像交通警察,在专注更复杂的机动车前,先给自行车放行。

对象缓存由类似memcache的组件完成,可以把它当做是应用程序的便利贴。做数据库查询时会先访问缓存寻求数据,如果发现了所需的数据,那么结果返回的时间将比访问数据库快10-100倍,这样就可以快速的构建页面,从而在眨眼间为用户呈现。如果它没有发现所需的数据,或者只发现了一部分,那么将会建立数据库请求并将返回的数据放于缓存中,让更多的后来者受益。

3.  缓慢的磁盘I/O、RAID 5、多租户存储

数据库中的一切都受到存储的限制,这里既包含了空间问题,也受设备读写的速度掣肘。

如果你使用实体服务器,那么一定要当心RAID 5,独立磁盘冗余阵列的一种,数据保护和奇偶性将严重的影响写操作。同时,如果其中一个磁盘损坏,那么这个阵列在磁盘重建时将变得非常缓慢。

这个方案一般使用RAID 10,它将为你提供独立的镜像集。这导致没有奇偶校验计算,从而不会影响重建时的速度。

云环境可能会涉及到类似于Amazon EBS(Elastic Block Store,一个类似于SAN的虚拟化磁盘)的技术。鉴于其基于网络,你必须与其它租户竞争存储的读写。因为每个存储能支撑的读写速度是固定的,所以你的邻居可能会影响到你网站及应用程序的读写速度。

最近,Amazon又公布了一个重量级产品Provisioned IOPS(每秒I/O操作)。对于技术专家来说看起来非常不错,但是对于其它人来说毫无价值。尽管如此,其依然重要,这意味着你可以锁定你数据库所需的磁盘性能。如果你想在Amazon上托管数据库,那么不妨多关注一下这个。

4.  串行处理

在超市结账时,如果有10个收银台开放,那么从事的是并行处理。如果每个收银台都在休息,只有一个登记处开放,那么从事的是串行操作。那么结账的队伍将变得非常长,不仅是结账人的心情受到影响,购物者也同样如此。这点经常发生在线路不够的大桥收费站以及许多人一起离场的体育场所。

网络应用需要严格的避免串行,因等待API调用而产生的阻塞,所有的后端节点都在等待一个搜索服务器,只要你应用程序的某处形成一个线就代表了串行化的发生,那么必须不惜一切代价去清除它。

5.  缺少Feature Flag

在给业务部门建立应用时,开发者一般从特性和功能入手。Feature Flag将至关重要,它让人们可以通过后端配置文件或管理员UI页面关闭或者打开特性。

为什么他们如此重要?如果你有早上4点的救火经验,那么你将明白启动应急计划的必要性。你需要可以关闭评级、评论以及应用程序其它的一些特性,这将不会导致整个系统崩溃。更重要的是,在新特性发布时,有些时候问题并不明显,直到一群互联网用户同时涌入。Feature Flag让你可以选择性的关闭一些功能,而不是关掉整个网站。

6.  单一的数据库副本

你必须使用一个以上的读副本或者MySQL从节点,这允许在主节点出问题时的快速故障转移。

拥有数据库的多个副本意味着横向扩展。如果你有两个,你就会看到3-4个会对你基础设施的提升。

7. 使用数据库进行排队

MySQL数据库非常适合储存表格、数据以及他们之间的关系,不幸的是,它并不适合处理应用程序的队列。尽管如此,许多开发者都习惯使用一个表格来达到这个目的。比如,让你的应用程序包含一些作业表格,或者一个状态列,拥有一些类似“in-process”、“in-queue” 及“finished”的值。

因为锁竞争、scan及 poll进程将造成更多的工作,这些解决方案会带来一些扩展性问题,它们将会显著的降低数据库速度。幸运的是这里存在很多有效的开源解决方案,比如RabbitMQ及Amazon的SQS。

8.  使用一个做全文查询的数据库

页面搜索是掣肘应用程序的另一个方面,尽管MySQL一段时间也支撑了full-text索引。但是它们只对MyISAM表格有效,其它类型表格都不买账,一直困扰着开发者。

一个解决方案是使用类似Solr的专业搜索引擎,这些技术拥有许多很好的库去支撑你的编程语言,同时会提供一个更快的搜索速度。这些方案同样易于扩展,并且不会让你的数据库成为累赘。

替代方案是Sphinx SE,一个MySQL存储引擎,将Sphinx服务器整合进数据库。此外,MySQL 5.6版本中还使用了InnoDB做全文搜索的默认搜索引擎。

9.  对象关系模型

ORM,就像毒药一样,一旦进行使用,就很难摆脱。有利的一面是ORM有益于快速原型,并且允许非专家级MySQL开发者使用对象或者内存模式进行读写访问。如果你不进行扩展,那么他们的速度将非常快,并让功能的快速交付得到保障。

然后DBA(数据库管理员)会因为缓慢且丑陋的查询来到开发团队并且说:“这个查询在应用程序什么地方,我们需要进行修复,它需要被重写。”开发团队则会说:“我们也不知道!”从而会收到来自运营组一些质疑的眼神。

有能力对bad sql进行跟踪并将其指出是非常重要的。DBA团队需要一定的指引找到bad sql的源头。如果查询是来自ORM,他们并不具备这些指引。这样你的团队将面对一个巨大的技术负债,同样也是个非常难以解决的挑战。

10.  缺少Instrumentation

Instrumentation(仪表盘)为应用程序提供了码表和油表,这是汽车不可缺少的两个部分。他们提供了应用程序的内部工作信息:他们记录了时间信息,并且提供了应用程序耗时最多的环节。

一个非常人气的网络解决方案就是New Relic,它提供了一个非常全面的可视化界面,针对各个领域工作者——项目经理、开发者、运营团队,甚至是业务部门都可以从图中发现问题所在。当然,现在已经有很多的开源Instrumentation。

11.  缺少代码仓库及版本管理

尽管现在这个问题已非常少见,但是还有有些互联网公司在没有版本控制下去建立应用程序。当然那些使用了的人,很清楚它将给团队带来的日常优势和组织控制。

如果你没有使用,随着应用程序变得更加复杂,你将被卷入技术负债的漩涡,为应用不同部分添加员工将变得异常困难。

一旦你使用版本控制,确保囊括了所有的组件,包含配置文件以及其它要素。而丢失部署时需要用到的部分,将带来额外的风险。

12.  单点故障

如果你的数据只存在一个主数据库上,这就是一个单点故障。如果你的服务器位于一个单独的磁盘上,这也是个单点故障。单点故障可以比作“阿基里斯之踵”技术用语。

不惜任何代价,单点故障都要在应用程序中移除。麻烦的是如何去认识单点故障,即使是选择单一的云供应商都可以称为单点故障,如果拥有多个供应商,或者使用Amazon不同的部分,那么AirBNB的服务将幸免Amazon 2012年10月的部分宕机。

13.  缺乏只浏览模式

如果你深夜在Yelp、Facebook或者是Tumblr上发布评论,你可能就会收到这样的信息:“该特性不可用,请稍后再试”。稍后可能是50或者60分钟,也许可能还需多试几次。对于非技术用户,他们仍然感觉网站在正常运行,只是奇怪了一点而已。

实际情况是,应用程序只允许你去浏览网站,但是不可以做任何改变。可能是主数据库或者是一些存储组件不可用了。

只浏览模式可以通过保留主数据库的多个读备份来实现,使用MySQL副本或者是Amazon读副本类似途径。这样就可以在没有主数据库情况下,保留网站全部浏览功能正常,这一点非常重要。

14.  脆弱的沟通

在扩展上谈沟通可能非常奇怪,但是应用程序技术层不可能因为团队间社交和文化上的差异分离。

强大的通信线路是必要的,队员必须要知道在错误发生时将找谁。好的交流需要自信及知识渊博的领导,广泛的听取意见并加以改善。

15.  缺少文档

当Web应用程序包含许多层时,文档至关重要。开发者需要给程序、功能、页面做文档,让后来者看代码时可以清晰的发现所需的提示及见解。当有程序发生故障时,运营程序需要在配置文件上添加评论去表明更改历史。业务流程及关系同样应该出现在公司的wiki里,让人们发现自己问题的解决方案。

文档可以在各个层次起到帮助作用,每个人都应该拥抱这个爱好。

16  缺少应急演习

应急通常情况下总会被忽视,团队可能会有“我们覆盖的地方都有备份”这类的说辞。不错备份、恢复的途径很通吃,关键是确保备份的文件万无一失。一旦在故障转移时发现备份有缺失,那么你不愿意发生的事情必然发生。

应急演习让事情发生之前有了相应的经验,公司应该将此作为运营团队工作的一部分,每年都需要进行几次。在云时代,应急演习已经变得比以前轻松许多。为保证所有组件都被备份而启动服务器是非常值得的,在这个过程中你将学到这项操作该持续多长时间,以及困难所在的地方,更知道需要小心些什么。

17.  缺少监视和指标

监视有着与版本控制同样的重要性:非常基本,缺少它工作将无法进行;然而确实有一些网站没有监视,或者是监视力度不够——有些服务器或者是核心组件并未被监视。

不间断的收集系统及服务器数据,同时,应用程序和业务级别的可用性也同等重要。如果你不想亲自动手,不妨考虑一个Web服务方案。

18.  莽撞的运营

你骑着马在街道上飞奔,明着带枪进入酒吧,你认为这是在交朋友?肯定不是,你在暴力的胁迫别人遵循,所有人都不会有归属感。强大的信心是好的,但是团队的合作是不可缺少的,团队的智慧高于任何个人。

团队需要不断的对改变做交流,用管理的角度进行,准备好应对失败等等。采取小心及规避风险的态度,永远都有备用计划,你应该有能力撤销所有改变,并且认真对待破坏性的改变,以及那些不可恢复的地方。

19.  日益增长的技术负债

随着应用不断的增长,队伍需要花越来越多的时间在老代码的维护和支持上,消除漏洞及缺陷。因此,花在新特性上的时间将越来越少。必须谨慎的维护好新特性与技术负债上投入时间的平衡。如果你发现你的技术负债增加,可能就是横下决心重写的时候了。重写可能会影响到短期新特性及客户特性的开发,但是从长远的角度上看是非常好的。

技术负债并不总是能被轻易的认知,在你建立特性或者是修复bug时,你更习惯于聚焦局部的细节,非常容易失去全局观,这也是为什么全面人才更益于Web扩展的原因。

20.  不足的日志

日志直接影响到度量及监视。你在寻找故障和排错时肯定希望得到更多的日志,但是在一个不间断运行的情况下,你同样会需要一些关键服务的日志。服务器系统日志、Apache及MySQL日志、缓存日志等,这些都需要被保存。而在日志太多时,你总是会减少一些地方的日志,或者裁剪及循环日志文件,从而丢弃旧的。

原文链接: Sean Hull’s 20 Biggest Bottlenecks That Reduce And Slow Down Scalability

你需要了解的vim命令

从 1970 年开始,vi 和 vim 就成为了程序员最喜爱的文本编辑器之一。5年前,我写了一个问自己名为 “每个程序员都应该知道的 100 个 vim 命令” 这次算是之前那篇文章的改进版,希望你会喜欢。

基础

:e filename Open filename for edition
:w Save file
:q Exit Vim
:q! Quit without saving
😡 Write file (if changes has been made) and exit
:sav filename Saves file as filename
. Repeats the last change made in normal mode
5. Repeats 5 times the last change made in normal mode

在文件中移动

k or Up Arrow move the cursor up one line
j or Down Arrow move the cursor down one line
e move the cursor to the end of the word
b move the cursor to the begining of the word
0 move the cursor to the begining of the line
G move the cursor to the end of the line
gg move the cursor to the begining of the file
L move the cursor to the end of the file
:59 move cursor to line 59. Replace 59 by the desired line number.
20| move cursor to column 20.
% Move cursor to matching parenthesis
[[ Jump to function start
[{ Jump to block start

剪切、复制和粘贴

y Copy the selected text to clipboard
p Paste clipboard contents
dd Cut current line
yy Copy current line
y$ Copy to end of line
D Cut to end of line

搜索

/word Search word from top to bottom
?word Search word from bottom to top
* Search the word under cursor
/\cstring Search STRING or string, case insensitive
/jo[ha]n Search john or joan
/\< the Search the, theatre or then
/the\> Search the or breathe
/\< the\> Search the
/\< ¦.\> Search all words of 4 letters
/\/ Search fred but not alfred or frederick
/fred\|joe Search fred or joe
/\<\d\d\d\d\> Search exactly 4 digits
/^\n\{3} Find 3 empty lines
:bufdo /searchstr/ Search in all open files
bufdo %s/something/somethingelse/g Search something in all the open buffers and replace it with somethingelse

替换

:%s/old/new/g Replace all occurences of old by new in file
:%s/onward/forward/gi Replace onward by forward, case unsensitive
:%s/old/new/gc Replace all occurences with confirmation
:2,35s/old/new/g Replace all occurences between lines 2 and 35
:5,$s/old/new/g Replace all occurences from line 5 to EOF
:%s/^/hello/g Replace the begining of each line by hello
:%s/$/Harry/g Replace the end of each line by Harry
:%s/onward/forward/gi Replace onward by forward, case unsensitive
:%s/ *$//g Delete all white spaces
:g/string/d Delete all lines containing string
:v/string/d Delete all lines containing which didn’t contain string
:s/Bill/Steve/ Replace the first occurence of Bill by Steve in current line
:s/Bill/Steve/g Replace Bill by Steve in current line
:%s/Bill/Steve/g Replace Bill by Steve in all the file
:%s/^M//g Delete DOS carriage returns (^M)
:%s/\r/\r/g Transform DOS carriage returns in returns
:%s#<[^>]\+>##g Delete HTML tags but keeps text
:%s/^\(.*\)\n\1$/\1/ Delete lines which appears twice
Ctrl+a Increment number under the cursor
Ctrl+x Decrement number under cursor
ggVGg? Change text to Rot13

大小写

Vu Lowercase line
VU Uppercase line
g~~ Invert case
vEU Switch word to uppercase
vE~ Modify word case
ggguG Set all text to lowercase
gggUG Set all text to uppercase
:set ignorecase Ignore case in searches
:set smartcase Ignore case in searches excepted if an uppercase letter is used
:%s/\<./\u&/g Sets first letter of each word to uppercase
:%s/\<./\l&/g Sets first letter of each word to lowercase
:%s/.*/\u& Sets first letter of each line to uppercase
:%s/.*/\l& Sets first letter of each line to lowercase

读写文件

:1,10 w outfile Saves lines 1 to 10 in outfile
:1,10 w >> outfile Appends lines 1 to 10 to outfile
:r infile Insert the content of infile
:23r infile Insert the content of infile under line 23

文件浏览器

:e . Open integrated file explorer
:Sex Split window and open integrated file explorer
:Sex! Same as :Sex but split window vertically
:browse e Graphical file explorer
:ls List buffers
:cd .. Move to parent directory
:args List files
:args *.php Open file list
:grep expression *.php Returns a list of .php files contening expression
gf Open file name under cursor

和 Unix 系统交互

:!pwd Execute the pwd unix command, then returns to Vi
!!pwd Execute the pwd unix command and insert output in file
:sh Temporary returns to Unix
$exit Retourns to Vi

对齐

:%!fmt Align all lines
!}fmt Align all lines at the current position
5!!fmt Align the next 5 lines

Tabs/Windows

:tabnew Creates a new tab
gt Show next tab
:tabfirst Show first tab
:tablast Show last tab
:tabm n(position) Rearrange tabs
:tabdo %s/foo/bar/g Execute a command in all tabs
:tab ball Puts all open files in tabs
:new abc.txt Edit abc.txt in new window

分屏显示

:e filename Edit filename in current window
:split filename Split the window and open filename
ctrl-w up arrow Puts cursor in top window
ctrl-w ctrl-w Puts cursor in next window
ctrl-w_ Maximize current window vertically
ctrl-w| Maximize current window horizontally
ctrl-w= Gives the same size to all windows
10 ctrl-w+ Add 10 lines to current window
:vsplit file Split window vertically
:sview file Same as :split in readonly mode
:hide Close current window
:­nly Close all windows, excepted current
:b 2 Open #2 in this window

自动完成

Ctrl+n Ctrl+p (in insert mode) Complete word
Ctrl+x Ctrl+l Complete line
:set dictionary=dict Define dict as a dictionnary
Ctrl+x Ctrl+k Complete with dictionnary

Marks

m {a-z} Marks current position as {a-z}
‘ {a-z} Move to position {a-z}
Move to previous position

缩写

:ab mail mail@provider.org Define mail as abbreviation of mail@provider.org

文本缩进

:set autoindent Turn on auto-indent
:set smartindent Turn on intelligent auto-indent
:set shiftwidth=4 Defines 4 spaces as indent size
ctrl-t, ctrl-d Indent/un-indent in insert mode
>> Indent
<< Un-indent
=% Indent the code between parenthesis
1GVG= Indent the whole file

语法高亮

:syntax on Turn on syntax highlighting
:syntax off Turn off syntax highlighting
:set syntax=perl Force syntax highlighting

via http://www.catswhocode.com/blog/130-essential-vim-commands

微信5.0免费表情添加

微信5.0出来了,我们当然第一时间要升级哇,对不对,除了能打飞机以外,还有表情对不对,还他妈的很丑对不对,最让我和我的小伙伴惊呆了的居然是,这个

他妈的破玩意居然要6软妹币对不对,我去年买了个登山包,超耐磨!

我们的米都不是大风刮来的是吧,我们也要表情么,关键把妹还有加分对吧,那还等啥小伙伴们,快添加哇。

OK Follow Me!

首先你的有手机吧,不是高富帅的iOS 7和iOS 6你起码也得有个Android吧。

你得有微信5.0吧。没有你就别看了,浪费情绪啊。

 

赶紧打开微信呐,有个“发现”按钮,很骚有没有!还有更骚的扫一扫啊~

1       2

3      4

5     6

 

扫把,哈哈,至于是啥自己看吧~

11 22 33 44 55 66

 

 

我在Facebook的这三年

本周开始是我在Facebook的第四个年头。我的经验在这里发生了巨大的变化:退学后我就来到了这里,在这里遇到了前所未有的挑战。单从这方面讲,我经历和遇到的挑战比这里4/5的人都要多。所以,我想分享一些我的认识和见解,希望其他一些程序员能感觉这有些用处。

作 为一个软件工程师,你的工作是开发出能解决问题的东西。初次进入公司时,你会被分配一些小任务,你可以解决它们。随着专业技能的增加,问题的规模越大越 大。避免这种问题规模变大或问题难度增加的做法是错误的。程序是你用来解决问题的工具。如果你园丁,你会去种花和除草。提高你的能力发挥并不是种更多的花 和除更多的草,你的愿望应该是能更快更高效,成为更有经验的园丁。你真正应该做的是,抬起头来,从整体看这个花园,思考如何布局,整体规划这个花园。

为 了能更有效的提高能了,你需要有效的交流渠道。交流渠道代表着一个人在这个世界上活动的能力。作为一个程序员,在你的生活环境里拥有顺畅的交流渠道,这对 你全面发掘遇到的问题的边界和最有效利用问题解决方案起着至关重要的作用。这既包括你的代码上的沟通,也包括在公司里和他人的交流。对于你参与的代码库, 你要快速的了解清楚各个组件是如何组合的。以这些知识为基础,你不能只去修复被分配的bug问题,而应该去考虑如何阻止这类问题再次发生。你不能只去想着 实现一个新功能,而应该考虑如何在这些老代码和新代码上提炼出一个公用组件,让它们共享80%的代码。这需要付出努力,但从长期看会有巨大的回报。

站 在更高层面看问题,将整个公司视为己有。不要允许你的同事不做到最好。理解各种决策的权衡以及原因;理解一些临时方案的决定和这样做的必要性,但如果你感 觉不对,一定不要在提出你的观点以求获取更好方案前就接受。这是你的公司(你的花园),如果你允许有人犁错了方向,整个花园规划将会变成一场灾难。养成勇 于change的习惯,并有信心这些变化将向好的方向发展。

人很容易陷入认为自己无法做到无所不知的漩涡,认为周围的人都比你聪明、有经 验,害怕自己说的不对,被对方看不起。事情其实不是这样。当你有了一个想法,和你的团队分享——即使你不能确定你的想法是否正确。错误的认识往往是通往正 确认识的里程碑,因为它能帮助你界定问题的真实边界,还因为你能通过的对错误想法的反复推演而获得正确的想法。

你并不能立即很明显的发现跟 公司内的其他团队中的人保持交流、维持关系有多重要。随机找一个你几个月未一起工作的人,和他进行简短的聊天。这能给你遇到的问题带来新颖的思路,也能让 你发现其它团队已有的解决方案,你可以拿来用。团队之间的信息交流能让你对公司有更全面的认识,而和另一个项目里的基层程序员交谈能激发新思想,新方案, 和新优势整合的机会。

我也是刚刚总结出这些经验。我希望这些能给你启发,促你进步,把它据为己有,指引你的团队走向正确的方向。祝你在Facebook工作的开心;我知道我是的。

facebook

支撑5亿用户、1.5亿活跃用户的Twitter最新架构详解及相关实现

 

Twitter如今在世界范围内已拥有1.5亿的活跃用户,为了给用户生成timeline(时间轴)需支撑30万QPS,其firehose每秒同样生成22MB数据。整个系统每天传输tweet 4亿条,并且只需要5分钟就可以让一条tweet从Lady Gaga手中呈现到她3100万粉丝的屏幕上。当下Twitter系统的规模及强大的吞吐量确实惹人艳羡,然而在出道之初Twitter也只是个奋斗在 RoR上的小站点而已,下面就一览Twitter如何完成从RoR到以服务为核心的系统架构蜕变。

Twitter系统的一些特性:

1. 当下的Twitter已不满足于Web App的现状。Twitter期望成为一组API,驱动世界范围内的移动客户端,成为世界级最大的实时事件链之一。

2. Twitter主导的是消费机制,而不是生产机制。每秒读取timeline的操作就会产生30万次的查询,而每秒的写入请求只有6000左右。

3. 离群值,拥有巨量粉丝的个体开始变得普遍,大量粉丝拥有者发送tweet时会因为大量的扩散而变得缓慢。Twitter试图将这个延时控制在5秒内,但是也并非一直生效,特别是名人们发送tweet以及相互转发变得越来越频繁后。这样就导致转发的内容可能比原始内容先一步到达共同粉丝的界面上,这样一来,就高价值用户来说,Twitter的主要精力必须从写操作转移到读操作上。

4. 使用Redis集群处理Home Timeline(首页时间轴,包含了众多关注者的tweet),最大条数为800。

5. 从你关注的人和你点击的链接,Twitter可以获知一系列关于你的信息。

6. 用户最关心的是tweet内容,然而大部分的基础设施却和这些内容不相关。

7. 对如此复杂堆栈进行性能追踪所需求的监视和调试系统往往非常复杂,同样旧决策的影响会不时的出现。

twitter

Twitter面临的挑战

1. 1.5亿的用户以及支撑timeline(home及Search)的30万QPS会让最初的具体实现(Naive materialization)变得缓慢。

2. 最初的具体实现由大量选择语句组成,遍及整个Twitter系统,曾今使用后被取缔。

3. 使用一个基于写的扩散方案。在接收到tweet时,系统将做大量的计算以发现tweet需要呈现的用户。这将造就更快、方便的读取,不要对读做任何的计算。由于所有的计算都被安排到写去执行,每秒大约可处理4000个写操作,比读操作要慢一些。

Twitter的团队合作

1. Platform Service团队承担起了Twitter核心基础设施的一切事务:

 

  • 他们负责Timeline Service、Tweet Service、User Service、Social Graph Service这些驱动Twitter平台的所有组件。
  • 内外客户端使用了大致相同的API
  • 产品团队不需要担心任何规模相关
  • 针对第三方API的注册应用过百万
  • 做容量规划,打造可扩展后端系统架构,在网站超出预期增长时要不断的更换基础设施。

 

2. Twitter还拥有一个架构团队。负责Twitter的整体架构,维护技术负债列表。

Pull和Push模式

1. 任何时刻都有用户在Twitter上发布内容,Twitter的任务就是考虑如何将消息同步发出并呈现到粉丝。

2. 真正的挑战就是实时性约束,目标则是在5秒内将消息发送到粉丝:

  • 交付意味着尽可能快的收集内容、投入互联网,并且在尽可能短的时间内返回。
  • 交付要做的是发布到内存timeline集群、推送通知以及触发电子邮件,其中包括所有的iOS、黑莓、安卓通知以及SMS。
  • Twitter是最大的SMS制造者
  • Elections可以成为产生内容并且以最快速度扩散内容的最大动力

3. 两种类型的timeline:user timeline(用户时间轴,即指定用户tweet页)及home timeline

  • user timeline就是一个指定的用户发布的所有tweet
  • Home timeline是你所有关注用户user timeline的一个临时合并
  • 业务规则。非你关注人@你时,将会被自动过滤,转发的tweet也可以被过滤。
  • 在Twitter的规模做这些事情是非常有挑战性的

 

Pull模式

1. 指向timeline,比如Twitter.com及hone_line API。之所以将tweet发送给你,是因为你对其进行了请求。基于Pull的交付:你通过REST API的调用向Twitter请求这些数据。

2. 查询timeline,搜索API。对资料库进行查询,尽可能快的返回所有匹配指定查询的tweet。

Push模式

1. Twitter运行了一个巨型的实时事件系统,通过Firehose以每秒22M的速度推送tweet。

  • 给Twitter打开一个socket,他们将会在150毫秒内完成所有公共tweet的推送。
  • 任何时候给推送集群打开的socket都超过1百万个
  • 使用类似搜索引擎的firehose客户端,所有公共的tweet都通过这些socket传输

2. 用户流连接。TweetDeck及Mac版的Twitter同样通过这种方式驱动。在登录的时候,Twitter会查看你的社交图,同样也只会推送关注人的消息,重建home timeline,而不是在持久的连接过程中获得同一个timeline。

3. 查询API,发布一个对tweet的持续查询时,每当有新的tweet发布,并且被认定匹配这个查询,系统会将这条tweet发送给相应的socket。

高等级基于Pull的timeline

 

  • Tweet由一个写入API生成,它将会通过负载均衡器及TFE(Twitter Front End)
  • 这种做法很直接,所有的业务逻辑在tweet生成时就已经被执行。
  • 随着tweet的扩散过程开始,新生成的tweet会被投入一个大规模的Redis集群中。每个tweet都会在3个不同的机器上做3个拷贝。因为在Twitter的规模,每天会有大把的机器出故障。
  • 粉丝的查询基于Flock的社交图服务,Flock会维护粉丝及粉丝列表:

 

 

  • Flock会返回一个接收者的社交图,并且开始循环访问所有存储在Redis集群上的timeline
  • Redis集群拥有TB级以上的内存
  • 每次投递4K左右的tweet
  • Redis使用原生的表结构
  • 如果你有2万个粉丝,负责粉丝查询的守护进程将会确认2万个用户在Redis集群中的具体位置,然后它会横跨整个Redis集群将Tweet ID插入相应的列表中。所以当你有2万个粉丝时,每条tweet的写入都会造成2万个插入操作。
  • 储存的信息包括新生成tweet的ID、tweet编写者ID以及一个4字节大小的状态信息(转发、评论或者是其它相关)。
  • Home timeline位于Redis集群中,每个有800条tweet。如果你向后翻太多页就没了,RAM是限制列表tweet数量的最大瓶颈。
  • 为了控制延时,所有活跃用户都存储在内存中。
  • 活跃用户的定义是在30天内有登陆过Twitter,当然这个规则可以根据缓存容量、实际使用等进行修改。
  • 如果你不是活跃用户,tweet就不会被放入缓存。
  • 只对home timeline进行存盘(持久化。PS:个人觉得这里应该是user timeline,如果是home timeline下文的重建方法显然不科学,欢迎大家讨论
  • 如果home timeline不在Redis集群中,则需要经历一个重建的过程:

 

 

  1. 对社交图服务进行查询,找出你关注的人。分别的访问磁盘获取每个人的数据,然后将他们送回Redis。
  2. 通过Gizzard使用MySQL处理磁盘存储,这将抽象出所有SQL事务并且提供了全局备份。

 

 

  • 鉴于每条tweet都会做3个备份,如果其中某台机器发生故障,他们无需对这台机器上的所有timeline进行重建。
  • 当tweet被转发时,将会存储一个指向原tweet的指针。

 

 

  • 当做home timeline查询时,Timeline Service将被调用。Timeline Service确认home timeline究竟存在哪台机器上:

 

 

  • 鉴于timeline备份在3个不同的机器上,所以需要运行3个不同的哈希环。
  • 一旦找着其中一个,就会尽可能快的返回结果。
  • 虽然这个过程会花费稍长的一点时间,但是读的处理仍然很快。从冷缓存到浏览器上呈现大约需要2秒,其中一个API的调用时间大约400毫秒。

 

 

  • 鉴于timeline只包含了tweet的ID,所以还必须要做tweet内容的查询。确定了ID以后,Twitter将通过T-bird并行获取tweet的内容。
  • Gizmoduck是个用户服务,而Tweetypie则是个tweet对象服务,每个服务都拥有自己的独立缓存。用户缓存使用的是memcache集群,缓存了所有用户。Tweetypie处理的是上个月的内容,它将一半的tweet储存在它独立的memcache集群中,当然这个部分服务的是内部用户。
  • 内容的过滤同样会省却一些读取时间,比如过滤掉法国的纳粹相关,这些内容的读取时间在呈现之前就被过滤了。

 

高等级的搜索

1. 所有的计算都通过读来解决,这让写更加简洁

2. 当有tweet生成时,Ingester会做相应的语法分析和索引,随后会将其传入Early Bird机器中。Early Bird属于Lucene的修改版本,同时索引都储存在内存中。

3. 在tweet扩散过程中,它可能会被储存在多个home timeline中,其个数由粉丝的数量决定。然而在Early Bird中,一个tweet只会被存入一个Early Bird机器中(不包括备份)。

4. Blender负责timeline的查询,横跨整个数据中心做集散操作。它对每个Early Bird做查询,以发现与查询条件匹配的内容。如果你搜索“New York Times”,Blender会查询数据中心的所有分片并返回结果,同时还会做分类、合并及重新排序等。排序的规则基于互动的数据,也就是转发、收藏及评论的数量等。

5. 互动的信息使用写的模式完成,这里会建立一个互动timeline。如果你收藏或者回复一个tweet,将会触发对互动timeline的修改;类似于home timeline,它同样由一系列的互动ID组成,比如收藏ID、评论ID等等。

6. 所有这些信息都被送到Blender。以读的方式进行重算、合并以及分类,返回的结果就是search timeline为你呈现的界面。

7. Discovery是个基于你相关信息的定制搜索,这些信息主要来自你关注的人、打开的链接,而重新排序的规则同样基于这些信息。

Search和Pull是相反的

1. 搜索和pull看起来非常相似,其实他们有着本质上的区别。

2. 在home timeline情况下:

  • 写。一个写tweet的动作会触发一个O(n)规模的Redis集群写入操作,n的值取决于粉丝的数量,由此可见处理Lady Gaga及Barack Obama这样拥有数千万粉丝的名人将会很麻烦。Redis集群上的信息都会写入磁盘,Flock集群会将user timeline储存到磁盘上,但是通常情况下timeline在Redis集群的内存中都可以发现。
  • 读。通过API或网络查找Redis是一个常数规模的操作。Twitter对home tiimeline的读操作做了高可用性优化,读操作只花费数十毫秒。这里也可以看出Twitter主导的是一个消费机制,而不是生产机制。每秒可处理30万个读操作,而写操作每秒处理6000个。

3. 搜索timeline情况:

  • 写。Tweet生成,并且传输到Ingester,只会写入一个Early Bird机器。一个tweet处理的时间大约为5秒,其中包括了排队及寻找待写入的Early Bird 机器。
  • 读。每个读请求都会触发一个O(n)规模的集群读操作。读大约需要100毫秒,搜索不涉及到存盘。所有的Lucene索引都保存在RAM中,所以聚散是非常有效率的,因为不涉及到磁盘。

4. Tweet的内容基本上与大多数的基础设施都是无关的。T-bird存储了所有tweet内容,大部分的tweet内容都是在内存中。如果没有的话,可以通过select查询将其拉回内存。与tweet内容相关的功能非常少,搜索就是其中一个,而Home timeline则完全不关心。

未来的工作

1. 如何将这条数据的管道打造的更快更有效

2. 在5秒内做到tweet的扩散,但是并不是时刻的奏效,特别是越来越多的高粉单位。

3. Twitter是非对称的关注,只有你关注人的tweet才会呈现给你。Twitter可以从这些单向关注中获取你更多的信息,有些单向关注同样还影射出一些社会契约。

4. 问题一般发生在大基数的图上:@ladygaga拥有3100万粉丝,@katyperry拥有2800万粉丝,@justinbieber拥有2800万粉丝,@barackobama拥有2300万粉丝。

5. 大批量粉丝的拥有者每发送一条tweet将造成数据中心大量的写入操作,而随着越来越多名人之间的交互,挑战变得更加的艰巨。

6. 这些需要扩散给大批量用户的tweet是Twitter最大的挑战,在关注这些名人的共同粉丝中,经常会出现回复tweet比原文更早一步送达的情况。他们在站点中引入竞态条件,比如最近关注Lady Gaga的粉丝可能会比老早之前关注的粉丝早5分钟看到tweet内容。比如说一个用户先收到了tweet,并进行回复,然而这时候Lady Gaga的原微博并没有扩散完毕,这样就会存在有些用户先看到回复的情况,为用户造成很大的困扰。Tweet通过ID进行排序,因为他们大多数是单调递增的,然而在如此粉丝规模下,这种做法并不奏效。

7. 寻找读和写途径的合并,不再做如此大规模的扩散;比如传播Taylor Swift新生成的tweet,取代在生成时进行扩散tweet ID,而是在读取时候就进行合并。通过平衡读写途径,节省百分之几十的资源。

解耦相关

1. 基于Twitter通过各种途径传播tweet,解耦可以让不同技术团队独立完成自己的工作。

2. 基于性能问题,系统也需要解耦。Twitter过去使用的一直是完全同步模式,而在两年前因为性能问题他们停用了这个模式。设备接收一个tweet需要145毫秒,接收完毕后就断开所有客户端连接,这么做同样也因为技术负债。写的路径由Ruby驱动,通过MRI实现,一个单线程服务器,每次Unicorn worker分配都会耗尽所有处理性能。每当有tweet流入,Ruby就会接收它,将它放到一个队列中然后断开链接。他们在每台服务器上只运行45-48个进程,这样的话每个机箱能同时处理的tweet数量也是这么多,所以他们必须尽可能快的断开连接。

3. 当下的tweet已经通过异步模式来处理,而这些讨论也都是建立在异步之上。

监视相关

1. 系统性能实时仪表盘

2. 使用VIZ系统监视每个集群,请求Timeline Service并从Scala集群获取数据的平均时间为5毫秒。

3. 基于Google Dapper系统的Zipkin,工程师可以通过Zipkin对请求的细节进行监视,比如获取请求所访问的服务及请求时间,这样就可以获知每个请求的性能细节。这样就可以通过每个阶段耗费的时间对系统进行调试,同样也可以从总体上看从请求到交付耗费的时间。花费了两年的时间,Twitter将活跃用户的timeline降到2毫秒。

部分统计数据:

 

  • 如果你有100万个粉丝,每个tweet将耗费数秒的时间来传播
  • Tweet输入统计:每天4亿条;日平均统计5000每秒;日统计峰值7000每秒;大事件期间高于1.2万每秒。
  • Timeline交付统计:每天300亿次(更多数据见原文)

 

原文链接: The Architecture Twitter Uses to Deal with 150M Active Users, 300K QPS, a 22 MB/S Firehose, and Send Tweets in Under 5 Seconds 

利用win7和mini无线网卡打造你的wifi

今天公司的wifi挂掉了,手上只有台式机一台,插网线上网,mini  无线网卡一个,可怜的手机君:)

不行,需要共享。 插上无线网卡(USB)的 你懂得。

然后在开始菜单输入 cmd  右键 以管理员身份打开。

输入

netsh wlan set hostednetwork mode=allow ssid=wow key=11111111

开启虚拟无线网卡。

然后在你的设备管理里面应该可以看到多出来一个无线网络2 修改名称为 wifi吧,好记。

然后右击你的物理网卡,邮件 高级里面设置共享上网

wifi

然后在 cmd 里面输入netsh wlan start hostednetwork 来启动你的wifi基站吧。

然后手机君,你怎么在线啦。

 

 

umount 提示device is busy nfs

视频网站对于资源的占用真是不容小觑,对于硬盘和网络,哎呀说多了都是泪-。-

今天硬盘扩容,需要更换原来的NFS挂载目录。一切都正常,反而在nginx那台服务器偏偏提示

 

device is busy

为什么win下的臭毛病也会在Linux发生, …………

fuser -m -v 目录

会告诉你那个进程在占用,导致busy

然后使用强大的  fuser -m -k  目录 然后你懂的。

最后说一下,磁盘最好用物理机,别用虚拟机做nfs服务器,要用的话也别用虚拟硬盘做nfs服务器。

血泪史。