昨天检查更新有问题的站点，竟然发现自己的博客也在其中。输入网址发现根本不是自己的博客，联系托管方，说是ip换了，而且已经换了很久。也就是说，我已经很久没搭理这方空间了。当初开这个博客，是希望对日常积累的技术做些笔记。如果没创业，也许这个技术博客还可以走得很远。尽管现在每天的多数时间还是敲代码，但多少已经失去了当年深究技术细节的热情和时间了。在车库认识刘一，还是个学生，只身来北京尝试创业。做的产品叫十字路口，是一个小清新风格的讲述创业故事的空间。他虽是计算机专业，但不是很会技术，所以外包给peter团队。穷学生毕竟没多少钱，开发上就停在了相对可以的一版。之后我再去车库，就看到他或是找人写故事或是自学Ruby尝试改些东西。也许，从客观条件来看，他的这次创业很难成功。但我想，他一定可以从中收获很多成长很多，也许到了某个时机，它也可以爆发更大的能量。关于他的故事，我只用一个段落就写完了。换成他，也许其中的心路历程可以延展的很长很长。就像我写给十字路口的推酷，絮絮叨叨至今，并不是多成功的创业故事，但它是我人生很重要的经历，它值得我去记录和怀念。说到成功，想起了比特币。最近比特币在车库很火，不少创业者心生浮躁。人多的地方难免浮躁，尤其是你看周围的张三李四几日不见已成土豪。赵东也和我聊过这事，尽管我也想早点找到挣钱的途径，但终觉得，这不是我想做的营生。做阅读是够苦逼的，但我的奢求也不多，能把这件 ...继续阅读 (14)

搬到黄泥川之后，经常性的跑步锻炼。尽管减肥的愿望没有多少进展，至少没有变得更胖。就像爱好骑车时想骑行中国，跑上步后就想能否跑得更远一些。两个月前从海事大学跑到了黄泥川，大概有10多公里，感觉体能还能接受。之后就寻思着跑个更远的，从黄泥川到旅顺汽车站（就是公交站北广场-旅顺的终点站），约23公里，连跑加休息估计得3个小时。时间就赶到了今天，早晨还下着雨，中午就放了大晴，下午3点一刻多，戴着摇滚音乐就上路了。下面是沿途随手不专业的拍的几张图。尽管天气很热，但到旅顺的路上都是山，也就阴凉很多了。上面这图没拍出效果，是很难得的遇到养蜂人。小的时候，夏天经常看到赶着车的养蜂人，后来是越来越少见了。其实，漫长的旅途之中切肤的感受是粘在身上的T恤、不断流淌的汗水、沉重的双脚和疲惫的神经。当你想着还有很多路要跑过的时候，旅途点缀的些许风景并不能使你有多少兴奋的感觉。我眼神不好，不是很确定这是不是一棵没有多少枝叶的树。这一路上，在拍这棵树的时候，我休息了能有一首歌的时间。离旅顺还有5公里左右远的地方，我爱这蓝色的海啊。之前有将近8公里的路程就没看到一个商店，终于见着一个小卖部，买了瓶脉动，瞬间喝完，没怎么消化继续上路，结果有些岔气了。有些反光，当时没看清自己拍的是什么，结果没把“大连外国语”拍进去，离大外不远的还有个大连医科大学。又不凑巧，mp3没电了，这就像创业路上没了鸡血一样，瞬间感觉失去了前进 ...继续阅读 (16)

写段html页面获取的代码很简单了，其实也不需我多说。不过，要能正确的获取html内容似乎也不是很容易。自tuicool.com内测以来，不断发现需要改进的细节问题，以致之前的新功能开发计划只能往后推。昨天就发现网站推荐的文章中有乱码的情况，站点来源竟是大名鼎鼎的mashable.com，而且收录的该站点文章多数都是乱码。所以，赶紧的在新文章抓取时对乱码情况做了检查，至少不能暴露给用户啊。接下来就分析和实验xhttpproxy的代码，结果发现，当不给httpclient传“user-agent”头时，返回的结果是ok的，这种情况实际上httpclient加了自己的“user-agent”头，而我试了其他多种“user-agent”都不行，不知道mashable.com对请求头做了什么样的校验策略啊，竟然对httpclient这么友好（如果使用java自带的Httpconnection也是可以的，它会默认传个带有java标识的一串字符）。前一阵子还遇到一个case，需要设置请求头”Accept“为”*/*”才能正常返回结果，否则连接就会被重置。如果我深入的检查抓取来的数据，可能还有不少bad case。这其实就有些让人头疼，因为很多网站对http头做了检查但策略又各不相同，加之我这方面的经验也不丰富，只能遇到一个分析一个。说 ...继续阅读 (14)

ki-analyzer是基于ik-analyzer修改而来的分词程序，所以名字上只是简单的变了一下，源码方面还是沿用了ik的包名等。之所以在ik-analyzer之上山寨另一个轮子，也实在是因为我的需求ik-analyzer不能很好满足，并且功能、设计、改动方面较ik-analyzer有很大出入，所以另起山寨。ik-analyzer项目现在还活着，前不久发布了新版，貌似只是源码实现细节的调整，项目也不是很活跃。当然，国内的几个开源分词程序基本都停滞了。ki-analyzer程序是上周修改的，这周实际测试了一下，只能说bug方面基本稳定，但尚需进一步检验。因为一些想要的功能暂时还用不上，所以也没着急做。关于ki-analyzer的详细情况可以参考项目首页信息，对该项目感兴趣或有问题的朋友可以联系我。 ...继续阅读 (22)

昨天做数据时发现个很诡异的情况，当然，再诡异的技术现象也有发生原因。抛开我的问题来说，我可以再提出个问题：是否在某种编程语言中，存在着那么一个变量i，使得i!=i成立，也使得while(i==i);可以成功的退出？如果你想到并理解了，你可以终止阅读这篇可能冗长的文章，尽管为了填补这个月的博客空白我刻意小题大作一番。在java语言中，Double.NaN就能使得上面两个表达式成立。说起浮点型中的NaN，之前的少有印象就是来自javascript，而考虑到没怎么搞过js，这点印象也就仅限于曾经alert出来的令人惊异的NaN（以及undefined）了。先说说浮点型吧，它的标准出自IEEE 754，Java规范中的章节是http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3，两篇也挺冗长的英文内容。可以重点提及的是，在内部实现上，32位的float和64位的double是使用int和long表示的。具体的表示方法可以从java api文档上看到更好的解释。以Double为例，它提供了下面3个方法：分析发现，除了常规的double取值，NaN（not a number）并不是对应着唯一的表示，尽管它并不是一个数值，比如除0或者对负数取平方根的结果都是NaN，但它们的发生原因是不一样的，所以如 ...继续阅读 (20)

mongodb支持的数据类型中，ObjectId是其自有产物，本文对其做些简单的介绍。存储在mongodb集合中的每个文档（document）都有一个默认的主键_id，这个主键名称是固定的，它可以是mongodb支持的任何数据类型，默认是ObjectId。在关系数据库schema设计中，主键大多是数值型的，比如常用的int和long，并且更通常的，主键的取值由数据库自增获得，这种主键数值的有序性有时也表明了某种逻辑。反观mongodb，它在设计之初就定位于分布式存储系统，所以它原生的不支持自增主键。而现实的世界是，大量应用在可预见的时空里并不需要分布式的mongodb，所以网上就出现了大量的实现mongodb自增主键方法的文章。恩，我之前也干过这种事情。还是看看ObjectId的底细吧。ObjectId被设计成跨机器的分布式环境中全局唯一的类型，长度是12个字节。有朋友可能嘀咕了，这可比int大了两倍，比long也多了一个int，很不经济嘛，但在现在的硬件配置中，多出的这些字节很难有理由成为系统的瓶颈所在，所以尽可能放心使用之。ObjectId的12字节是如此构成的：0-3这4个字节是时间戳（timestamp）、4-6这3个字节是机器码（machine）、7-8两个字节是进程id（pid）、9-11是程序自增id（increment）。可以看下java driver中Object ...继续阅读 (14)

赋闲以后很长没有更新博客了，说忙完全是借口，多半因为没有兴致所致。今天凌晨比赛多多，趁着比赛的前奏和间隙，遂浏览些技术文章。发现了 highscalability.com整理出了wordnik使用mongodb和scala的使用经 验：http://highscalability.com/blog/2011/2/15/wordnik-10-million-api- requests-a-day-on-mongodb-and-scala.html。这个wordnik也算是mongodb的先驱应用者之一，并贡献了一些管理工具给社区，去年的mongoSF大会也有它的参与：http://www.slideshare.net/fehguy /migrating-from-mysql-to-mongodb-at-wordnik。说起mongodb，从初识到现在已经有些时间，却也没有大场面使用和深入研究。nosql风吹了两年多势头愈发趋于冷静，能真正被大家认可使用的也就那 么几个，但又都离如mysql般成熟有些距离。而说起wordnik，它最初使用的就是mysql，后来主要因为性能问题转投mongodb，效果似乎还不 错。不过，单看wordnik的数据规模和访问情况，精心的使用mysql完全可以胜任，只是mongodb可能能更简单的胜任他们的应用场景。 wordnik给出的一些mongodb使用 ...继续阅读 (17)

前两天在solr邮件组看到一封广告帖，一个叫searchblox的搜索产品可免费使用，好奇心驱使我简单了解并使用了一下。searchblox是基于lucene的搜索解决方案，现在的版本已经是6.1,看来也有些年头了。searchblox不是个开源产品，有免费的版本，也有收费的版本，看文档介绍，收费版本除了提供服务支持还多了复制功能。功能上看，searchblox集成了爬虫和搜索功能，也提供Http API接口供索引和查询，可以在http://www.searchblox.com/developers/documentation上更多的了解searchblox的功能。但搜索功能方面，它也就是solr的子集。试用它很简单，下载解压缩后可直接java -jar start.jar通过jetty启动它，访问它的web admin console观察它的功能。就数据源来说，可以通过配置抓取的网站、RSS feed、本地文件夹数据，供searchblox自动索引和查询。如果索引数据来源自数据库等，searchblox没有提供直接支持，但可以使用它的Http API操作（或许它更应该提供多语言的客户端API）。下面看下它的架构图，可以更好的睽睽它提供的功能：在可扩展性方面，它提供了复制的支持，但没有提供shard支持：写到这里，其实我都不想对searchblox再评头论足了，它看起来实在不是很吸 ...继续阅读 (16)

22日下午3时多，收到搜索系统的报警邮件，错误日志如下：[2010-11-22 15:16:14][ERROR][pool-6-thread-1][SnapPuller.java(650)]Unable to move index file from: /indexpath/index.20101122031500/_21.frq to: /indexpath/index.20101122031000/_21.frqSnapPuller是Solr复制用到的一个类，我对它做了一些修改，所以把它挪到我的代码里了。报错的代码片断如下：privatebooleancopyAFile(finalFiletmpIdxDir,finalFileindexDir,finalStringfname,finalListcopiedfiles){finalFileindexFileInTmpDir=newFile(tmpIdxDir, fname);finalFileindexFileInIndex=newFile(indexDir, fname);finalbooleansuccess=indexFileInTmpDir.renameTo(indexFileInIndex);if(!success){L ...继续阅读 (17)

昨天的搜索系统又出状况了，几个库同时重建索引变得死慢。经过一个上午的复现分析，确定问题出现httpclient的使用上（我使用的是3.1这个被广泛使用的遗留版本）。搜索系统在重建索引时，是并发多个线程（默认是8个）不停的从PHP客户端取数据（当然，从另一个角度来说，搜索系统是客户端，PHP端是服务端），取回后放到一个队列里由单独的一个或多个线程更新索引。在测试环境复现发现，对于一个请求，PHP端打印耗时是1-2秒，但搜索端打印在4-6秒。这种耗时差别也就两种可能性，一个是PHP端返回到搜索端接受完耗时太长，另一个就是搜索端在真正发给PHP端数据前等待了很久。因为有了之前的jetty7的困顿，起初我怀疑是传输数据的问题。因为请求数据的代码部分我只是简单的使用了httpclient，所以只能从httpclient着手分析。我想到把PHP端和搜索端的请求起始和结束时间都打出来对照一下，不过在这样做之前我把搜索端的并发请求线程数调到了1,看下单线程情况下效果如何，结果惊奇地发现PHP端和搜索端的耗时相近。所以，可以确定，是httpclient的并发连接处理上可能存在问题。不消说，翻开httpclient API中和配置相关的接口，结果找到HttpConnectionManagerParams类中下面两个函数：publicvoidsetDefaultMaxConnectionsPerHost ...继续阅读 (15)

据我不完全统计，solr代码中使用引用计数的用途有两种：一个是引用资源，一个是引用对象。技术上来说引用计数的使用没多少可大说的，不过如果没有正确的close获得的资源和对象，泄漏的bug就出现了。引用资源solr中供使用的IndexSearcher是SolrIndexSearcher，使用时它是寄存于RefCounted。RefCounted的代码如下：publicabstractclassRefCounted{protectedfinalType resource;protectedfinalAtomicInteger refcount=newAtomicInteger();publicRefCounted(Type resource){this.resource=resource;}publicintgetRefcount(){returnrefcount.get();}publicfinalRefCountedincref(){refcount.incrementAndGet();returnthis;}publicfinalType get(){returnresource;} ...继续阅读 (13)

前几天就在twitter上看到oracle提升mysql售价的消息，推上的英文圈对oracle的这一举动议论纷纷，但中文圈很是平静，倒是像csdn、javaeye这样的媒体做头条报道：Oracle提高了MySQL的售价。这一新闻难免又引起大家对mysql前景的悲观，对迁移存储系统到postgre、nosql等蠢蠢欲动。其实多数mysql使用者可以轻松的忽略这一新闻，因为人家oracle提价mysql影响的是买收费版本mysql的用户，并不会影响我等使用免费版本的用户。国内媒体在转载这一新闻时也没有深究其信息的准确性，对于一些概念解释上的偏差，容易引起误解。这一新闻的源头就是http://www.mysql.com/products/的价格表上的变化。从该网页可看到，mysql版本有5个，免费的版本有Community Edition和Classic Edition（现有页面没有这个称呼，它就是MySQL as an Embedded Database），收费的版本有Enterprise Edition、Standard Edition、Cluster Carrier Grade Edition。oracle对mysql售价的调整有两方面：1、提高三种收费版本的价格，比如Standard Edition现在2000$,而原来的价格只有599$，这对付费用户确实有些影响。这里插段说明， ...继续阅读 (19)

solr的index schema中，除了支持基本数值类型的field，还支持一些特别的field，比如较常用的CopyField。以下面的schema配置片断为例：name="eshequn.post.db_post.0"version="1.1"xmlns:xi="http://www.w3.org/2001/XInclude">>for titlename="t"type="text"indexed="true"stored="false"/>for abstractname="a"type="text"indexed="true"stored="false"/>for title and abstractname="ta"type="text"indexed="true"stored="false"multiValued="true"/>>source="t"dest="ta"/>source="a"dest="ta"/>>字段t是文章的标题，字段a是文章的摘要，字段ta是文章标题和摘要的联合。添加索引文档时，只需要传入t和a字段的内容，solr会自动索引ta字段。这算不上多高级的功能，不过如果让你来实现这个功能，你会怎么做呢？我接手的搜索系统原来就有类似的功能，它的做法是，将t和a字段的文本合并，塞到ta字段，无可厚非的做法。不过，有人注意到lucene的Document ...继续阅读 (15)

看到一个很不错的工具http://github.com/eishay/jvm-serializers/，可以用它来评测各种流行的java序列化反序列化工具，使用上也很简单。想试试该工具的，下载源码后参考起README操作即可。而我更关心的是，是各种工具的性能对比，以作选择的一个衡量标准，也就是http://github.com/eishay/jvm-serializers/wiki的图示和数据。本文也就简单转摘其图示，图示中的java-manual指的是根据对象（数据）格式手工操作（当然是最快的，但不具有通用性），java-buildin-in就是内置的序列化方式（ObjectOutputStream、ObjectInputStream），其他工具的使用版本可以查看其wiki。1、Total Time (“total”)创建一个对象，将其序列化成一个字节数组，然后再反序列化成一个对象。2、Serialization Time (“ser”)创建一个对象，将其序列化成一个字节数组。3、Deserialization Time (“deser+deep”)相比于序列化，反序列化更耗时。为了更公平的比较，jvm-serializers在反序列化测试时访问了反序列化得到的对象的所有字段（也就是deep的含义），因为部分工具反序列化时“偷懒”而没有做足工作。4、Serialized Size ...继续阅读 (16)

对于使用主从复制的mysql用户来说，经常会遇到的问题是，当主库的写压力增大时，基于单线程复制的从库跟不上主库的写速度，造成应用从从库读到脏数据。如果在数据库前面使用了cache，那么这种脏数据的影响就更恶劣。更糟糕的是，如果在主库上执行了耗时很长的sql，那么从库就会被完全阻塞，这也限制了程序员们不要在主库执行耗时长的语句，更不要提那些alter schema的语句。对于mysql主从的这个缺陷，可以使用一些其他方式规避它，比如做sharding处理，控制每个master的写压力在合适的范围内，也可以去主从，通过应用来分发请求到各个db（应用相当于主库），但这些做法相比复制无疑会复杂的多。我很早就有的一个想法是，为什么不做一个mysql的多线程复制（并行复制），使得从库的写速度能跟上主库，而是一直使用这种低效的单线程复制？那时我没有从mysql官方看到这方面的消息。最近，看到Baron Schwartz的MySQL Limitations Part 1: Single-Threaded Replication，值得分享和讨论一下这个问题。Baron Schwartz在文章中提到了多线程复制的3种思路，列举如下:1）每个数据库一个线程。这样做的前提是各个数据库之间是独立的，主库不需要做什么修改，从库上对每个数据库起一个线程执行复制过来的binary log。这种方式的优点在于，基于 ...继续阅读 (15)

在我整理solr SolrIndexSearcher性能问题分析的时候，我就在想，我是不是误用了SolrIndexSearcher，才出现我所以为的性能问题。当我想到其实现特点，我恍惚确定确实是这样的，根源就是我误用filter query。上篇文章暂且放下，这篇做个补充。如我上文所述，fq=fid:1这个条件匹配的文档数会很多，不过，如果开启了filter cache，那么只会在第一次调用时慢些，后续的调用都会命中cache而提升速度，而通过query预热是可以解决初次调用的低速问题。所以，如果要使用filter query，就要开启filter cache，并确保filter cache能容纳所有的filter query。这也需要对应用的查询特点做好分析。以fq=atm:[int_time1 TO int_time2]为例，我之前是将它放到filter query中，不过因为每次查询的int_time1和int_time2都几乎不相同，使得总不能命中filter cache，严重影响了查询性能。另一方面，我在做压力测试时也发现，当filter query结果充满了filter cache，最终使得程序内存耗尽。对filter query的使用，还有个注意点，就是solr是按每个fq参数缓存结果的，所以fq=fid:1、fq=fid:2、fq=(fid:1 OR fid:2) ...继续阅读 (25)

问题背景基于solr的新搜索系统已经使用了有段时间，不过之前上的几个库都很小，也没发现什么性能问题。最近上了thread和post库后，性能问题显现出来。这段时间解决的性能问题有好几个，本文只着重于SolrIndexSearcher的search问题。thread库索引大小有400M多，记录数有400多万，原来的基于lucene的系统的查询处理耗时一般在10-30ms，而同样的请求，新系统耗时在50-100ms。而post库索引大小有6G多，记录数有3000多万，旧系统的查询处理时间一般在30-80ms，而新系统往往需要400-800ms，性能差距还是很明显的。因为SolrIndexSearcher是基于lucene的IndexSearcher，想必应该是青出于蓝胜于蓝，并且其wiki上给出的性能数据也很不错，所以当我把新系统做完后并没有去细致的测试其性能。但现在系统的性能相比之下确实有些差，并且因为要做多个库的整合搜索，就要避免像thread这样耗时长的库就成为短板。总之，问题需要定位和解决。原因分析分析thread应用给搜索server发来的query，query除了包含用户输入的文本，还有两个filter query:1)是fq=fid:1，fid是int型，表示选择某个版块;2）是fq=atm:[int_time1 TO int_time2]，atm是int型，表示帖子发表 ...继续阅读 (19)

Scalable System Design Patterns一文概括了几种常见的系统设计模式。配图很漂亮，我就索性摘过来，推荐感兴趣的继续围观其博客。1、Load Balancer该模式中，一个分发器基于某种策略确定由哪个worker实例处理请求。应用最好是无状态的，以使任何一个worker实例都能同等处理请求。大量的网站都会用到负载均衡器这个模式的。2、Scatter and Gather该模式中，分发器将请求转发给多个worker实例，每个worker实例处理完返回给分发器，分发器将worker们返回的结果再加工后再返回给客户端。以搜索为例，通常得AS、BS架构就是这种典型模式。3、Result Cache承接上个模式，这个模式只是在分发器处理时加了一步查询结果缓存，这都能算是模式！4、Shared Space这个模式还有个更广泛的名字–“黑板模式”。实现来说，就是在处理流程中，存在一个全局传递的对象，它可能包含了请求参数、中间状态、响应结果等各种信息，供流程中的各个组件对其进行操作。在一些web框架和应用框架中，都可见这个模式的使用。5、Pipe and Filter这个模式又以“面向数据流编程”知名，是很通用的企业集成模式。6、Map Reduce因为google和hadoop，这个模式几乎都了解些，尽管多数人都没亲身应用过。7、Bulk Synchronou ...继续阅读 (16)

当习惯于粗略浏览google reader中的未读条目后便似完成任务般的“全部标记已读”，我就经常性的错过不错的精彩条目，比如这篇Twitter’s New Search Architecture。我是订阅了engineering.twitter.com的，但这并不影响我没有注意到它就把它mark过。今天看到这篇文章时，已经有别的网站将该文翻译成中文了，比如新 Twitter，新搜索，比如新 Twitter，新搜索，我在这也就算是炒冷饭了。twitter之前的搜索使用的是被它收购的Summize公司的技术，是基于mysql的搜索，具体技术细节不祥。Finding A Perfect Match有提到，Summize也是个初创公司，做的就是twitter搜索，而twitter看中了Summize的技术和团队，便收编它为正规军。不过，随着twitter数据量的激增及对实时搜索的高要求（每秒1000条推的索引更新和12000次查询，一天下来有10亿次查询），原有的技术架构越来越不能满足需求，所以twitter转向了lucene。这除了lucene拥有诸多的优点，也是因为twitter自家有人是lucene的commiter。当然，lucene也有缺点，文中有提到twitter对lucene的一些改进点如下，这些点已经或将被提到lucene代码中：（1）改进GC性能。（2）无锁 ...继续阅读 (21)

Terracotta最近推出了个新东西–BigMemory，使得Infoq上的这篇Terracotta’s BigMemory Aiming to Eliminate Garbage Collection for Java Caches文章引来长长的争论。像GigaSpaces、Infinispan等和Terracotta有竞争关系的商业或开源的对手，对BigMemory的诸多方面提出了疑问和质疑。如果BigMemory真的如Terracotta吹的那般好，那些竞争对手该情何以堪？就算它真的好，也要挑出它的不是，比如就有评论说现在都分布式年代了，还搞什么单JVM实例优化？暂且放下这些争论，看看BigMemory是个怎样的东西，值得大家如此大动神经。JVM GC的问题可以说是“臭名昭著”，尽管现在一台服务器的内存可以动辄几十G到上百G，但单个JVM实例并不能充分利用硬件提供的内存资源，因为JVM内存容量越大，由GC带来的应用“暂停”现象就越明显。所以，通常单个JVM实例的内存容量要控制在一定范围内。这也使得，为了能有效利用机器的内存，一台机器会部署多个JVM实例。而对于需要大规模内存的Java应用，比如Cache系统，想不分布式都不行。但Terracotta说了，他们的大多数客户并不需要分布式的Cache系统，单个Ehcache实例就够用了，只是客户们希望单个 ...继续阅读 (15)

Feng的Facebook 针对 MySQL 开源 Online Schema Change 代码介绍了Facebook最新开源的在线修改mysql schema的工具，并对该工具极尽赞扬之辞。于是乎，我这个有大半年没动过mysql的人翻看起该工具的文档Online Schema Change for MySQL，并简单的浏览了其代码OnlineSchemaChange.php。总的来说，尽管其实现思想很朴素，这个工具真的很实用，它借鉴的openark-kit似乎发布了很长时间，只是名头没有Facebook的guys响亮，知道的人似乎不多。openark上的其他工具也很不错，比如ycheckpoint，就是个很不错的监控mysql运行状态的工具。对于修改mysql schema的操作，我之前的经验是：在主从模式下，先对从库逐台做修改操作，操作期间该从库不用于提供服务（应用端排除对该从库的读操作，如果脏读在一定程度上可以接受，该从库也可以对外提供服务）;所有从库做完后，将主库切到一个从库，对主库进行修改，修改完成后再切换回去。这个过程看起来有些繁杂，但只要有清晰的操作步骤和熟练操作工种，对于大多数一般规模的主从来说，这个过程是可以接受的，毕竟不是经常修改schema。不过，对于像Facebook动辄上千台数据库的情况，这个过程就会耗时很长很折腾，而人家专业的DBA人数又比不上国内的大 ...继续阅读 (27)

highscalability.com上的Playfish’s Social Gaming Architecture – 50 Million Monthly Users and Growing是篇很不错的大杂烩，内容涉及全球第二大social game公司Playfish的技术架构、产品设计、团队协作、产品运营等诸多经验之谈，尤其对初创团队很有借鉴意义。我这里还只是对文中提到的一些技术经验做些汇总，也推荐大家去浏览原文，重点看看自己感兴趣的段落。但说起架构的事情，其实看多了，往往都是大方向上相似，细节上有自己的考量和特点，以形成自己的架构风格。SOASOA在企业应用中热火朝天，但在互联网应用中SOA被提及的很少。Playfish的SOA并不是使用SOA工业中的技术栈，其思想就是组件化设计。当系统变得复杂以后，松耦合的组件化是必然的趋势，系统内组件间通过约定的接口交互。对于复杂系统来说，组件间的低依赖性是很重要的，当一个组件不能正常提供服务，系统应该是优雅的降级，而不是雪崩般的集体挂掉。说起来简单，但相信很多平时跑的很健康的系统，往往只是在一个组件坏掉后，才发现系统原来并不是看起来的那样可靠。The Cloud从一开始，Playfish就使用Amazon的基础云服务，国外的很多初创公司都是这样做的。关于使用基础云服务的诸多优点，其实很多文章都有提到，对初创产 ...继续阅读 (18)

最近在做搜索的查询日志的统计分析，对每一条查询统计日志，我将其解析出来后以特定字段格式存在mongodb中，定时调度做些统计分析。其中有个需求是，统计某个时间段（每天、每周、每月）各个query的查询次数，展示上就是热门查询query了。考虑到处理的数据量不会很大，解决方法也可以简单来之。我现在使用的方法就是mongodb的MapReduce功能，其实这个需求也可以认为是个group操作，而mongodb的group功能就是基于MapReduce的，但group对结果集的大小是有限制的。本文就针对一个示例介绍一下mongodb MapReduce功能。语法介绍MapReduce是mongodb中的一个Command，它的语法格式如下：db.runCommand({mapreduce:,map:,reduce:[,query:][,sort:][,limit:][,out:][,keeptemp:][,finalize:][,scope:][,verbose:true]});对于该Command，必有的3个参数我就不解释了。对于可选参数，这里简要说明如下：(1) query是很常用的，它用来在map阶段过滤查询条件的以限定 ...继续阅读 (19)

Solr的searcher autowarm（预热）有两个时机，一个是系统启动时（firstSearcher），一个是使用新的searcher替换旧的searcher时（newSearcher）。Solr支持在solrconfig.xml中对SolrCore配置SolrEventListener来实现自定义的autowarm。通常来说，Solr提供的默认实现QuerySenderListener就够用了。在我的需求中，希望solrconfig.xml中配置的SolrEventListener是针对多个SolrCore的，这要是因为我的多个SolrCore共用了一个solrconfig.xml配置。就配置autowarm的查询query来说，简单的就是配置一个常见的query，但如果系统有排序查询（sort），可以配置适宜的sort条件以预热lucene的fieldCache。下面是我自定义的SolrEventListener，效果是，如果SolrCore没有配置query，就使用default的，否则使用自己的。实现代码修改自Solr的QuerySenderListener，代码如下：publicclassTubaQuerySenderListenerimplementsSolrEventListener{privatestaticfinalLogger logger=L ...继续阅读 (35)

重写公司的站内搜索。经过前期一段时间对lucene和solr的熟悉，最后决定使用Solr作为新系统的基础框架。现在已经是第一阶段开发的后期，核心代码行数有11000+（不包含admin及client等）。现已实现的功能要比已有系统要丰富些，但综合比较两个系统总的代码量，其实新系统并不多得太多。新系统使用Solr代替了已有系统实现的部分功能，这减少了新系统的代码量，同是新系统实现了已有系统不具有的功能，也增加了一些代码量。开发的这段时间，因为新系统中很多代码是独立于Solr的，所以和Solr的交互也是时断时续，以使得即便到了开发后期我还能发现Solr实现的一些细节带给我的困扰。抛开我所做的系统来说，如果要选择一个站内搜索解决方案，Solr在某些场景下可能是个很不错的选择。因为Solr提供了Web server支持通过Http来更新索引、重建索引、查询等功能，如果需求对上Solr，甚至可以不需要基于Solr做二次开发就直接满足需要。多美妙的事情阿。不过，如果你需要些高级功能，那么可能你需要基于Solr做些工作了。比如，如果索引库很大，可以将索引库拆成多个shard，查询时对多个shard进行，这个功能Solr是支持的；不过，建索引的事情就需要自己搞定了，比如在Solr前面加个Proxy（或者只是个库函数），在建索引时根据特定的策略提交到不同的shard上。这个其实也还好了，但如果我需要 ...继续阅读 (15)

使用HttpClient，总是报出“Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.”的WARN日志，定位到HttpClient的源码如下：publicbyte[]getResponseBody()throwsIOException{if(this.responseBody==null){InputStreaminstream=getResponseBodyAsStream();if(instream!=null){longcontentLength=getResponseContentLength();if(contentLength>Integer.MAX_VALUE){//guard below cast from overflowthrownewIOException("Content too large to be buffered: "+contentLength+" bytes");}intlimit=getParams ...继续阅读 (11)

本周遇到几篇和基准测试相关的不错的文章，如果不是因为上周末鼓弄了一下各种锁的性能测试，我或许就会错过它们。两篇文章来自dw，分别是Robust Java benchmarking, Part 1: Issues和Robust Java benchmarking, Part 2: Statistics and solutions，作者还有个专页Java benchmarking article提供一个Java基准测试的框架，感兴趣的可参考之。本文算是对Robust Java benchmarking, Part 1: Issues的一个简单的总结。在阅读Robust Java benchmarking两篇文章的过程中，我也看了些其中的参考文章，也有一些不错的可以拜读之。1、度量执行时间基准测试通常的过程是：1）记录开始时间，2）执行代码，3）记录结束时间，4）计算时间差。Java中记录时间程序员们经常使用System.currentTimeMillis，不过该方法在精度上有偏差，这个偏差依操作系统的不同而不同，比如Win98可能会偏差55ms，Linux2.6可能偏差1ms。如果测试的task执行时间在毫秒级别，这个偏差就会影响结果的正确性了。JDK1.5中引入的System.nanoTime就是更好的选择，它在精度和准确性方面表现得都更好。而这种偏差以及其他因素可能引起的偏差，都在 ...继续阅读 (12)

周末对Java中各种类型的锁做了基准评测。测试的条件有两个：1）是10、50、100个不同的并发线程，2）是读写比例近似1:1,10:1,100:1,1000:1。测试方法是，对各种加锁的Map方法做性能评测，它们都是实现了MapWrapper接口的封装，测试的就是Map的get和put方法。测试的锁类型有：1）hashtable：直接测试Hashtable，2）synclock：对HashMap的方法直接加synchronized（理论上性能应和Hashtable相当），3）mutexlock：对HashMap的方法显示加Lock锁，4）rwlock：对HashMap加读写锁，5）concrrent：直接使用ConcurrentHashMap的方法，6）对HashMap读操作不加锁，写操作加Lock。针对每种测试条件，起的每个线程执行特定次数（10万或100万）次读写操作，写入的内容是随机生成的整数，每种条件下一个线程要跑三遍，取总的处理时间的平均值作为计算结果。评测的代码如下：publicinterfaceMapWrapper{voidput(Objectkey,Objectvalue);Objectget(Objectkey);voidclear();StringgetName();}publ ...继续阅读 (14)

在[Solr 实践]Solr Cache使用介绍及分析一文我有对Solr的LRUCache和FastLRUCache做了一些介绍，本文在此基础对其实现做些补充。1、LRUCache的实现分析在分析LRUCache前先对LinkedHashMap做些介绍。LinkedHashMap继承于HashMap，它使用了一个双向链表来存储Map中的Entry顺序关系，这种顺序有两种，一种是LRU顺序，一种是插入顺序，这可以由其构造函数public LinkedHashMap(int initialCapacity,float loadFactor, boolean accessOrder)指定。所以，对于get、put、remove等操作，LinkedHashMap除了要做HashMap做的事情，还做些调整Entry顺序链表的工作。以get操作为例，如果是LRU顺序（accessOrder为true），Entry的recordAccess方法就调整get到的Entry到链表的头部去：publicV get(Objectkey){Entrye=(Entry)getEntry(key);if(e==null)returnnull;e.recordAccess(this);r ...继续阅读 (25)

在blogjava上看到一文谁能帮忙解释一下为什么这个程序会死锁？，激发了我那能害死猫的好奇，所以很费劲的琢磨了这个问题。由于涉及的内容较多，就单独发文阐述一下。文中提到的问题程序如下：publicclassTestLock{privatefinalHashMapmap=newHashMap();publicTestLock(){finalThreadt1=newThread(){@Overridepublicvoidrun(){for(inti=0;i<500000;i++){map.put(newInteger(i), i);}System.out.println("t1 over");}};finalThreadt2=newThread(){@Overridepublicvoidrun(){for(inti=0;i<500000;i++){map.put(newInteger(i), i);}System.out.println("t2 over ...继续阅读 (17)