随手记

2013-08-21html

二级结构真是一个很好的结构,用在 IPv4 地址管理上,就是 CIDR;用在 UNIX/LINUX 的用户管理上,就是 组 和 用户的概念,能够用来作权限控制;用在网络服务上,服务提供者组能够作负载均衡;再加上版本号的话,就是构建/发布的命名规则,例如 maven 中的 group 和 artifact 的概念。node


2013-08-23linux

若是你的程序会被他人使用,最好提供一个指南(tutorial)文档,其中包含一个简单、完整、易于理解的例子(如,以用户登陆、请假申请为例),若是可以用讲故事的方式来进行描述就更棒了。git

理解一个系统,最好先感性,后理性;先脉络,后细节。程序员


2013-09-04github

用习惯了 Git,如今的项目用 SVN,感受二者的差距就出来了。首先,若是断网了,则 SVN 没法提交本地修改;其次,SVN 的 merge + commit 操做之后,只能看到 commit 的日志,被 merge 进来的分支的历史所有丢失了,只能看到 commit 操做的修改历史。golang


2013-09-05web

logback 配置文件的思惟模型原来是这样子的:Logger 是咱们的某个小头目(能够有多个,可是 Root Logger 有且只有一个),Appender 是真正输出日志的干活儿的,必须先成为某个日志控制器小头目的小弟(经过 appender-ref 指定)而后才能开始干活。
mongodb


2013-09-15docker

问:计算机的模型是什么?

答:存储 + 计算


问:为何存储是个问题?

答:

• 服务器必须逻辑上是不宕机的

• 服务器能够宕,可是状态必须维持
• 存储是状态的维持者
• 状态维持很是麻烦,因此须要把存储从业务中抽象出来,让业务系统不用为维持状态烦恼
• 抽象的结果
    – 中间件产生
    – 一般是某种你们熟知的数据结构
• 字典(KV)、文件系统(FS)、队列(MQ)等等


问:存储为何会成为互联网服务?

答:

• 技术门槛愈来愈高

    – 品质要求更苛刻
        • 数据只是存下来已经不行了,还要存多份以防止丢失
        • 数据只是存多份已经不行了,还要在丢失副本的时候及时恢复以防止丢失
        • 光是保证数据不丢已经不行了,还要数据时时都在线,不能出现服务不可用,服务任何环节都不能有单点故障
    – 扩展能力成为问题
        • 互联网的用户愈来愈多
        • 单用户在线的数据愈来愈多

• 服务外包取代技术外包

    – 运维难度愈来愈大
        • 服务愈来愈复杂,就算有相应的开源软件,看管软件的运行过程,以保证服务的健康运行,也已是巨大的负担
    – 竞争愈来愈激烈
        • 巨头横行
        • 大量的同质化产品
        • 如何让本身跑得比别人快?创业者须要善假于物。


问:服务器端软件的性能瓶颈在哪里?

答:I/O,包括磁盘 I/O 和 网络 I/O


问:服务器端软件的 I/O 瓶颈的解决方案是什么?

答:

1) Go 语言使用了闭包 + 协程,而非使用异步回调(许式伟在《Go 语言编程》一书中的解释是,使用异步回调对程序员的心智负担太大,程序的逻辑被 I/O 切割而碎片化,对象的生命周期也很难管理)

2) Node.js 使用了异步回调,即 event loops, callbacks, closures and non-blocking I/O


2013-09-17

UNIX 有几个统一性的理念或象征,并塑造了它的 API 及由此造成的开发风格。其中最重要的一点应当是“一切皆文件”模型及在此基础上创建的管道概念。总的来讲,任何特定操做系统的开发风格均受到系统设计者灌注其中的统一性理念的强烈影响——由系统工具和 API 塑造的模型将反渗到应用编程中。


在 UNIX 中,低价的进程生成和简便的进程间通信使众多小工具、管道和过滤器组成一个均衡系统成为可能。


UNIX 提倡把程序分解成更简单的子进程,并专一考虑这些子进程间的接口。这至少能够经过如下三种方法来实现:
    1)下降进程生成的开销。
    2)提供方法(shellout、I/O 重定向、管道、消息传递和套接字)简化进程间通讯。
    3)提倡使用能由管道和套接字传递的简单、透明的文本数据格式。


真实世界里的编程,其实就是管理复杂度的问题(例如,下降系统的总体复杂度,下降程序员的心智负担)。


2013-09-24

每当本身迷茫或者自满的时候,就会想一想若是是本身所敬仰的人处于一样的场景,会怎样应对,而后,心境平和、“stay hungry, stay foolish”。


2013-09-25

A little bit upset..., not prepared to protect myself from those who are unreliable and to always have a backup plan.

EDA(以业务为核心的事件驱动架构) + CQRS(读写分离) + SOA(服务要自治)【注:这里的事件是业务层面的事件,而不是技术层面的事件


2014-02-26


139K goroutines 支撑 68K 活跃链接, 每一个链接有两个goroutine ,由于net包的write和read是阻塞的,只能是1:2。这条推特的意义在于,证实了了GOLANG的并发模型,解决了服务器端的 C10K 问题,并且是突破了 10K ,达到了 68K。


2014-05-13

Android:现实世界的购物平台

越过各类软件更新的小树叶,咱们所看到的是Google辛勤栽种的一整片森林。将定位功能(包括离线地图)与行为识别、文字广告和强大的即时购买联系到一块儿,不难看出Google正将这广告平台推向更广阔的现实世界,直接装入了人们的口袋之中。

2014-05-17

《beego失落的手册》:http://go-talks.appspot.com/github.com/beego/tutorial/zh/beego/beego.slide#1


2014-05-22

http://confreaks.com/events/gophercon2014


2014-05-23

GO语言国内小站集锦:

http://studygolang.com/topics/node22

http://bbs.go-china.org/

http://sudochina.com/

http://www.golangtc.com/


2014-05-27

摘自《SteveY对Amazon和Google平台的吐槽

因此,有一天,Jeff Bezos下了一份命令。固然,他老是这么干,这些命令对人们的影响来讲就像用橡皮槌敲击蚂蚁同样。这个命令大概是2002年,我想偏差应该是在正负1年内 —— 这个命令发布的范围很是地广,设想很大,让人眼珠子鼓出来的那种,这种惊讶程度和其余的命令相比,就好像你忽然收到公司给你的奖金同样让人惊讶。

这份大命令大概有以下几个要点:(陈皓注:这里是本篇文章的要点!若是这真是Bezos发出来的,那么太赞了,Bezos彻底就是一个系统架构大师啊,那但是2002年左右啊。做者调侃Bezos彻底是正话反说啊)

  • 1) 全部团队的程序模块都要以经过Service Interface 方式将其数据与功能开放出来。(陈皓注:Service Interface也就是Web Service)
  • 2) 团队间的程序模块的信息通讯,都要经过这些接口。
  • 3) 除此以外没有其它的通讯方式。其余形式一律不容许:不能使用直接链结程序、不能直接读取其余团队的数据库、不能使用共享内存模式、不能使用别人模块的后门、等等,等等,惟一容许的通讯方式只能是能过调用 Service Interface。
  • 4) 任何技术均可以使用。好比:HTTP、Corba、Pubsub、自定义的网络协议、等等,均可以,Bezos无论这些。(陈皓注:Bezos不是微控经理吗?呵呵。)
  • 5) 全部的Service Interface,毫无例外,都必须从骨子里到表面上设计成能对外界开放的。也就是说,团队必须作好规划与设计,以便将来把接口开放给全世界的程序员,没有任何例外。
  • 6) 不这样的作的人会被炒鱿鱼。

在接下来的几年,Amazon内部转变成面向服务架构SOA(Service-Oriented Architecture),在这华丽转身的过程当中,他们学到了至关巨多巨多的东西。我在的那个时候,世界上就有不少不少的关于SOA的学术文档,但在Amazon的那种超大规模的面前,世间的这些文档就好像告诉印第安纳琼斯(陈皓注:电影夺宝奇兵男主角)过马路前要先看看两边有没有来车同样没用,Amazon的研发工程师们在这个过程当中发现了不少不少的问题,并从中学到了不少。下面只是他们这些问题中的沧海一粟:

  • pager escalation(陈皓注:生产线上问题的寻呼系统)变得比较困难,由于ticket可能会转过来转过去(陈皓注:ticket就是处理问题的工单),只到转了20次,都找到真正能解决问题的团队和人。若是每个呼叫都花去团队的15分钟的响应时间,那在找到真正的团队以前,几小时就已通过去了,除非,你能建造出不少不少的脚手架,测量标准和报告。
  • 每个和你的相关团队忽然间均可能成为一个潜在性的DOS攻击者。没人可让事情有进展,直到在每个Service里放上配额(quota)与节流阀(throttling)的机制。
  • 监控与QA是被统一了。若是你不进行一个大规模的SOA,你就不会这么去想。可是,等到你的Service说,“是的,我还好!”,但实际状况多是,服务器里惟一能正常运做的功能就是一个快乐的机器声音在呼叫你:“我很好,收到,收到”。为了要确认整个服务能正常运做,你须要对Service的每个部分都去Call一下。这个问题会以递归的形式地出现,直到你的监控系统可以全面性地系统地检查全部的Services和数据,此时,监控系统就跟自动化测试QA没什么两样了,因此二者完美的统一了。
  • 若是你有上百个Services,并且你的程序只能经过由这些Services来跟其余团队的程序作沟通,那么,没有一套Service发现机制的话,你就不能找到这些Service。因此,你得先有一套Service的注册机制,这也是一个Service。因此,Amazon有一套全体适用的Service注册机制,以例能够经过反射机制来找到Service,并知道Service的API,以及是否可用,在哪儿。
  • 调试其余人的代码以调查问题变得很是的难,几乎都不可能,除非有一套全面性的标准的方式,他能够在可被调试的沙盒里运行全部的Services。
上面这些只是极少数几个例子,在Amazon在进化的过程当中,Amazon遇到这样的问题可能一打甚至数百个,Amazon都一一学习和总结了。对于把Service外部化甚至还有不少几乎没有人会想到的很是生僻的东西,固然,也不会有你想像的那么多,Amazon都学到了。把业务组织成Service让团队学会了不能相信对方,就如同他们不能信任公司之外的程序员同样。

当我在2005年中期离开Amazon加入Google时,这个努力进化的过程还在进行时中,但那时已经至关的先进了。从Bezos颁布法令的时间到我离开的时候,Amazon已经把文化转变成了“一切以Service第一”为系统架构的公司,今天,这已经成为他们进行全部设计时的基础,包括那些毫不会被外界所知的仅在内部使用的功能。

那时,若是没有被解雇的的恐惧他们必定不会去作。我是说,他们今天仍然怕被解雇,由于这基本上是那儿天天的生活,为那恐怖的海盗头子Bezos工做。不过,他们这么作的确是由于他们已经相信Service这就是正确的方向。他们对于SOA的优势和缺点没有疑问,某些缺点还很大,也不疑问。但总的来讲,这是正确的,由于,SOA驱动出来的设计会产生出平台(Platform)。

是的,这就是Bezos的法令要达成的目标。他之前(如今也是)一点不关心各团队是否好,也不关心他们使用什么样的技术,实际也不去管他们如何运做他们的业务,除非团队开始把事搞砸。可是,Bezos比绝大多数的亚马逊人都很早很早就领悟到,Amazon必须成为一个平台。

若是是你,你会想到要把一个在线卖书的网站设计成为一个有扩展性,可程序化的平台?你真的会这样想吗?

嗯,第一件Bezos领悟到的大事是,为了销售书籍和各类商品须要的基础架构,这个基础架构能够被转变成为绝佳计算平台(Computing Platform)。因此,如今他们有了Amazon Elastic Compute Cloud(亚马逊弹性运算云平台EC2),Amazon Elastic MapReduce,Amazon Relational Database Service(亚马逊关系数据库服务),以及其余可到AWS aws.amazon.com查获得的一堆Service。这些服务是某些至关成功的公司的后台架构,好比 我我的喜欢的 reddit 是这一堆成功公司的其中一个。

另外一大领悟是,他知道他们不可能永远都创造出对的东西。我认为,当Larry Tesler说他妈妈彻底搞不懂怎么使用那个该死的网站时,Bezos的某根筋被触动了,固然,我也不清楚究竟是谁家母亲,这可有可无,由于没有人的母亲可以会用那个该死的网站。事实上,连我这个在那工做超过5年的人都以为Amazon网站的接口使人胆战惊心。

我并非很肯定Bezos是如何领悟到的——领悟到他不能创造 出一个产品能适用于全部的人。不过,怎么来的这不重要,重要的是他的确领悟了。这种事有一个正式的术语,叫Accessibility,这是计算机世界中最最重要的事情了。

最!重!要!的!事!

若是你在内心面在想“哼?你是说,像盲人和聋人那种Accessibility吗?”,那么,你不是惟一这样想的人,由于我已经知道有不少不少像你这样的人:这种东西对大家这种人来讲是不可能有正确的Accessibility,因此这事你还不能理解。固然,不能理解也不是你的错,就像眼盲,耳聋,或是其余行动不便的残疾人,这些也不是他们的错。当Software——或ideal-ware——若是由于某些缘由不能被存取或使用,那么,这就是软件或是那想法的错了。这就是Accessibility failure。

就如同生命中那些重大的事同样, 每一个事都有一个邪恶的双胞胎姊妹,它在幼年都受到父母的溺爱,如今它已经成长为同等强大的复仇女神(是的,Accessibility有不仅一个复仇女神),这个复仇女神叫安全性(Security),他们在一块儿老是争执不休,冤家一对。

不过,我会和你争论Accessibility要比安全性来的重要多了,由于零Accessibility就意为着你根本没有作出产品来,而若是安全性为零,你仍然仍是能够有一个某个程度上成功的产品,譬如说Playstation Network。

那三件Amazon比Google强的中的最后一件事是,Google很不会作平台(Platform)。咱们就不懂什么是平台。咱们就根本不知道平台的内涵。大家其中一些人明白,可是大家是少数派。在Google过去这六年来,越清楚这一点就越让我痛苦。我曾有一线但愿,来自Microsoft和Amazon,以及近来Facebook的竞争压力,会让咱们全体人都清醒过来,并开始打造咱们公司的Service。不是那种特制的或半生不熟的,而是多少和Amazon的相似的那种:一次到位,真正的,没有做弊或是欺骗,而且把它放在最高优先级的位置。

但实际上却不是,这个事被放在了好像是第10仍是第11位,或是第15位,我不知道,反正是至关低。只有少数几个团队严肃地看待这个事,但大多数的团队不是从没有思考过这个事,就是只有一不多的人很鼠目寸光地在看待这个事。

对大多数的团队来讲,只要是让他们以提供给别人那种可程序化的方式存取他们的数据与运算的方式来开发软件,就算几个小小的粗糙的Service,对他们来讲也是翻天覆地。他们大部分人都认为他们在作产品,但他们只是在提供那些凄惨粗糙的Service。回去看看前面我所列的那些部分的Amazon学到的东西,而后告诉我,哪个粗糙的Service能让你有超凡脱俗的产品。迄今为止,就我所知,一个也没有。就算是这些粗糙的东西很不错,不过这就好像要汽车的时候,你却只有汽车的零件。

没有平台的产品是没用的,再精确一点,去平台化的产品老是被平台化的产品所取代

Google+是咱们彻底失败的不懂Platform最明显的例子,从最高层的管理层(嗨,Larry、Sergey、Eric、Vic,大家好)一直到最最底层的员工(嘿,你)都不懂。咱们所有通通都不懂。平台Platform的黄金守则是Eat Your Own Dogfood(吃你本身的狗食——本身都要用本身的平台)。Google+这个平台是个杯具的过后抄袭者。咱们在发布它的时候彻底没有任何API。我查了一下,目前也只有少得可怜的API。Google+的一个团队的成员在发布API时告诉我这个事,我问:“这是Stalker API(用来偷窥内部数据的API)吗?”,她郁闷地说,“是啊”。个人意思是,我那只是个玩笑话,可是,不,咱们提供的惟一的API就是取得某人的信息流,因此,我想我把玩笑开到本身头上了。

Microsoft知道“狗食守则”至少有20年了。这已经成为他们世世代代文化的一部分了。不能是你吃人类的食物而给你的开发人员们喂狗食。那样作只会是为了短时间的成功而掠夺了平台长期价值。平台就是要你考虑得长远。

Google+就像膝跳反射,一种短视的的东西,是基于觉得Facebook其伟大产品的成功做出的错误判断。但那不是为何他们能成功的东西。Facebook的成功是由于他们创建了一个可让外界在其上上面开发的产品群。因此对Facebook对每一个人来都不同。有些人把所有时间花在“Mafia Wars”上,有些人则是花在“Farmville”(开心农场)。那里还有成百上千个不一样的高质量的时间消耗类的游戏,因此,人们老是能够在那里找到他们想要的。

咱们的Google+团队看了看说:“哎呀,看来咱们须要一些游戏,让咱们去找一些人来为咱们写些游戏吧”。你是否开始看到这样的的思考有多么不靠谱了吗?问题在于咱们试图在预测人们想要什么,而后推出产品给他们。

你不能这么作。真的不能。也不可靠。在这个世上,甚至在整个计算机的历史上,只有极少数几我的可以这么干,Steve Jobs是其中一个。可是咱们没有Steve Jobs。对不起,咱们真的没有。

Larry Tesler有可能说服了Bezos相信他并非Steve Jobs,但Bezos意识到他不须要成为Steve Jobs也能提供给全部人好的产品:你们感到容易使用的接口与工做流。Bezos明白他只要有让第三方开发人员来作的平台,这些东西天然就会有的。

我要向一些人道歉,这些人会以为我所说的是再明显不过的了。是的,的确是巨明显的。只是咱们没有去作。咱们没有领会平台,咱们也没法领会到Accessibility。这二者原本就是同一件事,由于平台会解决Accessibility。而平台就是Accessibility。

  • 是的,Microsoft领会到了。并且大家也像我同样知道Microsoft他们对这些东西只知其一;不知其二。那是由于他们可以了解平台彻底是他们商业上意外性的副产品,是他们一开始的业务就是提供平台。因此他们在这个领域有着三十多年的经验。若是你去看看 msdn.com,并多花点时间浏览一下,假设你之前从没去看过,你等着被吓到吧,由于那里面的东西但是多得不能再多。他们拥有成千成千成千个API。他们拥有一个超巨大的平台。说实话,太巨大了,由于他们要霸占一切,但至少他们作了。
  • Amazon也领会了到了。Amazon的AWS(aws.amazon.com)至关的惊人。去看看吧,四处点一下。使人羞耻吧。咱们今天什么都尚未。
  • 很明显Apple也领会到了。他们作了在基础上不开放的选择,具体来讲是移动平台。可是他们明白什么是Accessibility,而且他们知道如何燃起第三方开发团体的力量,并且他们吃本身的狗食。你知道吗?他们的狗食作得很好吃啊。他们的APIs比Microsoft的要干净不知道多少倍,并且是远古的时候就这样了。
  • Facebook也领会到了。这正是让我所担忧的。这使得我不得我抬起懒惰屁股写下这些东西。我恨写Blog。我恨……Plus(指Google Plus)无论怎么称呼它,反正在Google+上发表长篇大论,就算这是个糟糕的地方,可是你仍是但愿Google能成功.我真但愿!个人意思是,Facebook想挖我,并且很容易就去了。但Google是个人家,因此我坚持我这个小小的家庭干涉,就算你不舒服。

等到你为Microsoft与Amazon提供的平台感到神奇后,固然,我想也你可能会被Facebook吓到(我不敢去看,由于我不想让我太沮丧),让咱们回头看看 developers.google.com 。是否是有很大的差异?咱们的这个平台看起来像是你家小学五年级的侄子搞出来的东西同样——让一个小学五年级的学生,试着为一个强大的的平台公司去设计平台,就像像咱们问这个小学生:“若是这家公司什么资源都有,那你会作出个什么东西来?” 同样。

这里请不要误解我——我知道一个事实,dev-rel 团队为了发布这些API曾经不得不去“搏斗”。据我所知,这个团队很不错,由于他们知道什么是平台,而且他们如英雄般努力挣扎地要作出来,然而遇到的倒是“平台冷漠”的环境,难听点仍是那种有敌意的环境。

我只是在直白地描述出一下 developers.google.com 在外人眼里是什么样子。它看起来很幼稚。Maps APIs在哪呢,老天啊?其中有些东西仍是实验性的项目,我点进去看的APIs……他们都毫无价值。他们很明显都是些真正的狗食。甚至都称不上是好的有机食品。跟咱们内部APIs比起来,他们所有简直就是猪屎马粪。

固然,也不要错误地理解我对Google+的见解。他们还不算是最差的。这是文化氛围的事。咱们如今作的简单来讲就是要进行一场战争,是一场失败不少的少数的平台派和那些强大的信心坚持的产品派的战争。

那些从头至尾明白理解供外部可程序化的平台概念的团队都是受压迫的人——Maps跟Docs团队浮如今我脑海中,并且我也知道GMail是这个方向的先头部队,可是他们很可贵到资金注入,由于这不是咱们文化的一部分。Maestro的资金彻底无法和Microsoft Office开发平台的资金相比:就像小白兔和暴龙相比同样。Docs团队知道本身永远没法和Office竞争,除非他们能遇上Office的脚本能力,并且他们得不到他们相要的资源。个人意思是我假定他们没有,如今应用的脚本能力只在电子表格中有,并且没有为API设置键盘快捷键。在我看来,这个团队彻底没有被重视。


可是,当咱们摆出那种咱们知道怎么给用户设计出完美的产品的姿态时,你最好相信我,咱们就是笨蛋。你能够说是自大,天真,或是别的什么,无所谓,但最终的结果就是咱们干的很愚蠢。由于,这世界不可能有一个产品对全部人都是完美的。

你看,咱们的浏览器竟然不能让人设定默认的字号。这就是咱们对Accessibility的公然冒犯。个人意思是,我总有一天会老的,我也会得老花眼,并会变瞎的。个人意思是我不会变瞎,可是若是你到了40岁,你的老花眼让你看不清近的东西。那么,字号的选择会成为生和死的问题:某用户就会被彻底排除在产品以外。可是Chrome团队就是这么NB傲慢:他们想要开发出无需配置的产品,他们对此至关自豪,去你TMD是瞎子还聋子,管你是谁,在你剩下的日子每访问一个页面都按一下Ctrl-+吧。

并不只是他们是第一个。问题是,咱们是一家“产品”公司,一直一直都是。咱们开发的最成功最有吸引力的产品——搜索引擎,那样巨大的成功让咱们产生了不少定式和偏见。

  • Amazon过去也是家产品公司,一道神秘的力量使得Bezos领悟到他们须要平台。那道神秘力量来源于,他们被 逐渐蒸发的市值逼到墙角了,不得不千方百计突围出来。但他当时所拥有的只有一群工程师和他们的一堆计算机……除非他们能变成印钞机……你能够看到他们是怎么搞出来AWS的,而不是像咱们Google+同样过后诸葛亮。
  • Microsoft从一开始就是个平台,因此他们有不少不少的实践。
  • Facebook:我有些没看透。我不是专家,不过我很确定他们一开始也是一个产品,而且成功了很长时间。因此我不知道他们何时开始转变成为平台的。应该是好久之前的事了,由于他们要成为平台后,Mafia Wars这玩意才会出现(而Mafia Wars也很老了)。也许,Facebook只是看一眼咱们,就问到:“咱们如何击败Google?他们少了什么?”

咱们面对的问题很是的庞大,由于咱们须要通过剧烈的文化转变后,咱们才能迎头遇上。咱们没有内部的SOA平台,因此咱们外部也没有。这就是说,咱们整个公司都“没有领会到”:产品经理没有,工程师没有,产品团队没有,没人领会到。就算是个别人有,好比你你有,那也至关于没有,除非咱们在生死存亡的时候。咱们不能这样不断推出产品,并装做咱们之后会把这些产品转变成迷人美丽的可扩展式的平台。咱们试过了,不行。

平台的黄金守则,“Eat Your Own Dogfood 吃本身的狗食”,换句话说,“先打造出本身使用的平台,而后把它用在全部的地方”。你不能过后再作,那样作就太困难了——你去问问那些把MS Office平台化、把Amazon平台化的人。若是你放在后面作,那么你比一开始要花十倍的精力才能作对。你不能做弊,你不能让内部软件走秘密通道以取得特定的优先权限,不为何,你必需从一开始就要解决这个问题。


2013-05-31

golang net 库

err时没有close ??
DialTimeout
dialtimeout是不行的
由于http会有复用
方案1:
要写个结构 继承conn 而后在每次读数据时调设置超时时间

type TimeoutConn struct {
    net.Conn
    timeSegment time.Duration
}


func DialTimeout(netw, addr string) (net.Conn, error) {
    conn, err := net.DialTimeout(netw, addr, time.Second*5)
    if err != nil {
        return nil, err
    }
    
    return &TimeoutConn{
        Conn: conn,
        timeSegment: time.Second * 5
    }, nil
}


func (c *TimecoutConn) Read(b []byte) (n int, err error) {
    c.SetReadDeadline(time.Now().Add(c.timeSegment))
    return c.Conn.Read(b)
}


func (c *TimecoutConn) Write(b []byte) (n int, err error) {
    c.SetReadDeadline(time.Now().Add(c.timeSegment))
    return c.Conn.Write(b)
}

方案2:
@七贝
咱们是这样处理的。。。
func TimeoutDialer(cTimeout time.Duration, rwTimeout time.Duration) func(net, addr string) (c net.Conn, err error) {
return func(netw, addr string) (net.Conn, error) {
conn, err := net.DialTimeout(netw, addr, cTimeout)
if err != nil {
return nil, err
}
conn.SetDeadline(time.Now().Add(rwTimeout))
return conn, nil
}
}

func NewTimeoutClient(connectTimeout, readWriteTimeout time.Duration) * http.Client {
return & http.Client{
Transport: & http.Transport{
Dial: TimeoutDialer(connectTimeout, readWriteTimeout),
},
}
}


2014-06-20

Skype for Linux:

http://www.techspot.com/downloads/4985-skype-for-linux.html
[

国内用户,离线deb包安装能够到这里http://t.cn/RvOaRTw,网盘离线下了一份。 到skype官方会被重定向到和光明日报版skype,好坑。 //@校长Ubuntu:你会发现很奇葩。。由于在skype官方网你根本找不到linux版本,反正我找了半天没找到。。。。我只能在ubuntu软件中心安装skyp

]


2014-08-01

好的代码应当便于理解、便于测试。

2014-12-22

Docker —— 从入门到实践

http://yeasy.gitbooks.io/docker_practice/


--------------------------------------------------------------------------------

2014 技术总结流水账

  • WEB API
    • Spring Boot
  • 存储
    • SQL
      • PostgreSQL
    • NoSQL
      • Redis
      • SSDB
  • 编程语言
    • Java
      • myBatis-Spring
      • Jedis
  • 分布式
    • Twemproxy
    • Codis
  • WEB GUI
    • RequireJS
    • AngularJS
  • 技术书籍
    • UNIX 编程艺术
    • GO 语言编程
    • GO WEB 编程

2015 技术计划

  • WEB API
    • beego
  • 存储
    • NoSQL
      • Redis
      • SSDB
  • 编程语言
    • Go
  • 分布式
    • Codis
    • ZooKeeper
    • etcd
  • DevOps
    • Docker
    • Kubernetes
    • seagull
  • WEB GUI
    • AngularJS
    • ECharts
    • AngularUI
    • Angular Material
  • 技术书籍
    • Docker 技术入门与实践
    • Go 并发编程实战
    • UNIX 环境高级编程
  • 源码阅读
    • beego
    • codis
    • golangtc
  • WEB 工具
    • Nginx

2014-03-10

Sharding & IDs at Instagram

Each of our IDs consists of:

  • 41 bits for time in milliseconds (gives us 41 years of IDs with a custom epoch)
  • 13 bits that represent the logical shard ID
  • 10 bits that represent an auto-incrementing sequence, modulus 1024. This means we can generate 1024 IDs, per shard, per millisecond

2015-05-11

搭建高可用mongodb集群(一)——配置mongodb

http://www.lanceyan.com/tech/mongodb/mongodb_cluster_1.html


2015-07-30

爬取 AJAX 网页信息的 Java 库/框架

1. HttpUnit ( http://www.httpunit.org/ )

2. crawljax ( https://github.com/crawljax/crawljax )


2015-09-07

github explore (https://github.com/explore)


2015-10-13

https://jobs.lever.co/github/

相关文章
相关标签/搜索