放翁（文初）的一亩三分地

@Any
http://code.google.com/p/sharedthreadpool/

@铁木真
包括google，flickr都有自己的认证，虽然支持OAuth，这种看起来大而全的标准，在实际使用中最多只能用于平台互通，在初期的平台建设上，并不一定要去赶着潮流，呵呵。而且我做开放平台的时候,OAuth还是0.1呢。OAuth1和2差异也很大，不过明年我为了平台间互通也会考虑支持一下。

@冰河快狼
http://www.slideshare.net/cenwenchu/ss-6142016

@爱品者
hehe，千万不要提补偿，做事情一定要简单粗暴，如果一定说要保证一致性，那么有些必定要一致性的过程就不能拆分，否则搞死自己：）

@爱品者
我还是一个前端盲：），你回答的很不错了，第一点再次请求带来的消耗（虽然是304只返回消息头）和一个域下最多2个链接的却是挺大的问题（我记得有些人就压缩合并在一起了），js重新解析我到不知道，是不是如果页面不卸载，指向同一个js的时候也不会再解析一次。
至于缓存我觉得不论前端后端都一样，关键还是更新和读取比例的问题，不合适的话，同步反而成为累赘。
管道这块其实和前面两个没啥关系，只是服务端和客户端都可以用，将一个大事务切割成为多个小任务的时候，串行执行可以减少每个阶段自有资源的生命时常，可以提高复用效率，并行执行可以提高多个大任务执行中对于各个阶段资源消耗的利用率。
你的回复前两点，我提交到我的微薄上去，挺好的

EA@darren

@BucketLI
1.有权重的的线程池是基于concurrent上封装的，自己尝试过封装，性能差不多，就没什么意思了，现在配置maxpoolsize和minpoolsize是一样大的，这样当线程池到了上限后就放入队列，队列满了就丢弃，如果需要加入超时特性，其实就把线程池自带的队列中的数据封装带有时间戳，然后定时轮询清理掉过期任务。或者采用时间槽的概念，比如分成6个时间槽，每隔10分钟切换一个时间槽，那么当你任务20分钟是容忍极限的话，那么在每次切换时间槽的时候清除相隔2个位置的队列。
2.这个还是看你自己的策略，简单来说，如果一个必选步骤错了，就产生结束任务的事件，有后台线程执行删除任务操作。
3.CountDownLatch你是用线程阻塞？为每一个任务都分配一个？我不是很清楚你的做法，但是个人感觉CountDownLatch用于任务的join启动和结束比较好，你也可以描述一下你们的做法？

今天的后续文章会谈一下这点@BucketLI

@君楚
起初用词的时候就是自己考虑了一下，不过你看看wikipedia的解释，我觉得尚可 http://en.wikipedia.org/wiki/Instruction_pipeline

一般尽量不会太晚，超过12点太多时间，早晨6点多肯定起来了@xzs

线程的栈数据是jvm自己的，要不然也不会有启动太多线程导致OOM或者栈溢出的问题了@xzs

@夜露死苦
我达不到，但是如果当时有人和我说的话，我会少走很多弯路，呵呵，所以我和他说了，重要的是给建议别人，而不是去挑剔。

@chinablue
本来是从来不删除别人的评论的（有点删除的冲动，保留个10天公示一下），包括你说的某某前辈给我的意见，呵呵，我不知道你对这个前辈是不是也有你所说的那种葱白（既然你喜欢别字，那我也应景一下），删除你的评论，是因为每个人都有权利选择自己的院子里面是不是需要容得下各种植物，我这篇文章没有推到首页（包括csdn），只是自己留下来（见谅，网络硬盘也是硬盘），多说无益，呵呵，希望你生活的精彩

@一意孤行
呵呵，大部分都同意啦，只是有句俗话说的好：少不读三国，老不读红楼，在适合的时候做适合的事情，青春就是用来烧的，这也是将来成熟的一种历练。感谢你对我的关注，对我来说，技术是一种爱好，但是现在我更在乎的是产品，不再会和过去一样为了技术而技术，如何用技术来支持产品满足用户是我在乎的（当然设计的好的架构（不是啥开源框架，呵呵）在用户需求不断变化的时候可以更快的响应，能够前瞻到用户的潜在需求，挖掘出用户真正的需求）。最后贴一段我的Boss（菲青）前一阵子给我的一段评语：回放翁的文章。放翁和自雪应该是阿里/淘宝开放的先行者。从08年我们开始干开放的活儿，就是大家从无到有的累积。当然，新业务的建立需要时间，革命尚未成功。但是，看到放翁的转变从一个技术狂爱者到一个以业务为支撑的技术专家，我很佩服他的成长，也感觉TOP很幸运有了这些人，才使得TOP能够继续成长。我们的目标是以技术来支撑，改变业务产品，但不是技术主导业务。当然，因为我们流量及业务复杂度的关系，这中间沉淀下来的技术含量绝不亚于淘宝内部的一些大型系统！

@孔夫子
这么说我同意，呵呵，学形，学意或者悟道都是不断进步的，这也是我们这些老家伙为什么会比新人值钱的原因，如果仅仅关注技术外在那么做个五年还就是一个熟练工

@孔夫子
首先技术的目标就是服务客户，这就是最更本的要求，否则就是一个没有毕业的大学生，因此我所涉及的内容不会为了技术而技术，是产品需要而生。其次，这年头一堆人搞忽悠，没有人踏踏实实的写点代码，基本不靠谱，同时创新不是脑袋里蹦出来的，而是在使用前人已有的技术时发现无法满足需求才去思索和实践得到的结果，整天想着创新却不踏踏实实的干点事情，那就是等着天上掉馅饼，呵呵，不多说，仁者见仁，智者见智，少一些抱怨，多一些实干，把平凡的事情做的不平凡那就够了

@孔夫子
如果你不了解淘宝开放的服务，请去看文档；如果你觉得需要开放的没有开放，你可以提需求；如果你有实际的工作成果，请展示；的却时间可以证明很多事情，同时在评论别人的时候需要更多的拿出建议，而不仅仅是批判，这才是大家需要的氛围，这年头没有不好的技术，只有生搬硬套的误用。

@puran
一看这个名字就想起了你了，呵呵，好久没有联系了

@wangchangbing
我这边是好看的么

占个坑，明天来看，哈哈哈，感谢分享

@ethan
1.对于趋势统计我们现在是将每日数据入库来做更加个性化的统计，因为分析后的数据已经是比较粗粒度，但是同时有能够满足个性化需求的，因此就不再这个系统中设计了。当然趋势告警这边有做
2.先不说月，我在系统中有max,min,average，其实就有一定的这个意思，当着些逻辑满足不了，可以自动扩展reduce的方法来实现。
3.对于结果的merge是master单线程做的，多线程提交只是放在合并队列，因此不存在并发问题。而且合并结果本来就有资源竞争，对于此类过程，多线程和单线程效率没什么区别，多线程反而增加复杂度。

mapping file其实就是用java的管道和内存文件来做的，效率应该说在java中比较好了，实际的测试我到没有准确的做过，也不好给出结果。

当前正在做即时分析，数据源也可以切换到DB上去了，时间可以缩短，省掉了对大文件切割和拖拉的时间。（这块时间的却是在分析中最耗时的），这样我除了每天的日报表，也有了段时间的报表（每15分钟，自己可以定义时间段），增量合并后就是一天的报表。

@ethan
1.condition和valuefilter就是数据清洗的环节，当然也支持，map和reduce的自定义。
2.对于top排名只需要定义order即可，当前流出了字段，不了解什么叫做时间窗随意。
3.没有这个需求，我不是做DB。
4.对于与处理来说由于对于记录输入只是一次遍历，因此没有必要再去细分什么类型的reduce，一条记录阅读完成以后这些分析必须全部做，这是一个串行的过程，因此无所谓前后之分。
5.松散的设计就是让master足够轻，同时任务slave就是资源廉价，通过用算法来分配任务，在失效时间和分配之间找到平衡点，master和slave的关系。
6.还是那个设计，如果master要监控slave，那么就不是我说的松散设计，而是传统的分布式mapreduce的思想。选择松散就是在控制度和复杂度之间找到平衡点。

对于处理来说就是需要找到关键路径，然后在关键路径上找各个环节可以优化并行处理的工作，至于如何优化，的却需要去验证，就好比文件切割和任务块执行，最简单的设计就是根据多核来设定单机的工作线程，因为这是消耗cpu的工作。

对于文件切割会根据采用的方式不同而不同，我只是关心java方式，呵呵，其他我不关心了，对于java我就用map file的方式来切割，管道输入输出效率还是很高的，我不了解你的测试用的是什么方式。

不过很感谢你的留言，起码看到有人还是看了，呵呵。

@叮当
赫赫,技术是学习入门,然后靠实践再去推翻或者改进已有的知识体系,作出来的是实践积累,反过来影响知识.

@HiMagic!
其实我是要说明，对于流程中的工作需要细分，监听消息到来和分发消息是很单薄的工作（可能在高并发下还有合并消息），而具体的工作执行应该是另一个繁重而不稳定的阶段，需要区分对待，来提高前面队列的稳定性，当然worker比较慢同样会导致worker线程耗尽，这就需要考虑用什么策略来应对，可以用超时设置，丢弃排队等方式来实现。

写错了，真是的啊。

观察过,1.5肯定是不回收的,它的一个锁信号量,1.6回收比较慢,要到一定的内存占用比例才会去Gc。SIP最早时候的内存泄露就是这个问题。

像牛一样干活的人

@躺着读书
楼上说的很对,我的比喻不恰当,改一下.赫赫,不过就中西医来说,我的想法是当你的手段越丰富,可能让人变得浮躁,其实不管是中西医,关键还是那个人,要能够沉的下心去做事.

如果使用内存数据库,的却写出的频度可以比普通的数据库要快,但是就算是内存数据库,它的连接资源还是有限的,就算使用连接池,其实在每天几十亿的数据量下还是撑不住的.这里虽然用了线程,但是采用的是比较单一的使用方式,线程切换代价不大.不过这个可以测试一下看看,采用mysql内存数据库，然后每来一条数据就写，与批量异步写看看对于系统压力以及性能来说是否有变化。

Google的Gdata，豆瓣的Open API，Amazon的S3等等都是REST的，当然并没有说REST一定是好的，技术没有所谓的优劣，只有用的人是否在合适的场景充分的利用了它的优势特点。

对了，最近修复了几个边界问题，最新版本为2.4

^_^,不错

@Always BaNg.
不是淘宝，是阿里软件

没有,如果可以，你可以用这两个包在同样的环境试试看。

不错

动作很快么,呵呵.昨天我才在theserverside看到，你今天就出中文版了。

改造Spring的组件，支持import

Enterprise Architect

写的不错哦：），不过有一点要纠正的就是socket不是协议，是对网络通信协议抽象实现的一种方式，tcp和udp是两种传输协议，而http是标准的应用协议（设计初衷），只是有人将http误用为传输协议（这也就是REST的理念），他们三者和socket完全没有什么必然的联系。

看了三篇文章，也受益不少：），不过对于OSGI和SCA以及服务框架有自己一点想法，这儿写不下：），回blog写。不过以后有了你和我交流和学习，对将来完善动态载入的服务框架更加有信心了^_^

@vagrant
先谢谢你的支持啦：），不过我是没看过你说的那电视，至于我的名字，呵呵，我爷爷取的，应该没什么太大关系。