闲扯kafka mq
本文主要讲解关于kafka mq的设计思想及个人理解。关于kafka的详细信息，大家可以参考官网的文献document:http://kafka.apache.org/documentation.html这是一篇相当不错的文章，值得仔细研读。
第一个问题：消息队列（Message Queue）是干嘛用的？
首先，要对消息队列有一个基本的理解。不少人虽然在用消息队列，却并没有搞清楚消息队列是干嘛的。
寄生兽 TV版
三天把《寄生兽》追到最新的18集，意犹未尽。一开始只它当作一部讲述畸形怪物的血腥惊悚动漫来看。后来发现，这居然还是一部感情细腻，画风时常美得让人窒息，人物塑造丰满的佳作。该漫最凶残的地方绝不是对怪物噬人的描绘，而是对几个主要女性角色的命运刻画。当你发现一个角色刚被刻画得无比丰满，你开始无条件爱上她的时候，恰恰就是作者让她死的时刻，一切来得太突然，凄美得让人眼睛流汗，心碎一地。
关于solr build search分离的讨论以及re-indexing的实现
场景需求与分析
我们的做法，一般将索引构建大致分为两类操作，一为全量索引构建，二为增量索引构建。使用solr建索引，一般会在初始状态的时候，进行一次全量构建，根据当前数据源的整体数据生成一套完整索引，可提供服务，但为了保证索引数据的完整且最新，还需要增量索引，使得数据源的改变（包括记录的增加，修改，与删除）体现在这套索引之上。
Solr源码掘金之 SolrCloud中的zookeeper使用分析
上一周，对公司搜索引擎工作流程的做改造工作。涉及到不同角色服务器之间的沟通工作。我们试图应用zookeeper到我们的场景，实现应用模块之间的解耦。本文深入到solr源码，从中掘金，看看solr是如何使用zookeeper的。
在做本次改造的时候，公司同事对于zookeeper的使用，提供了很好的建议，其中一个重要原则就是“谁创建，谁修改”，也就是各个服务应用自己创造自己的结点，自己去修改配置自己的最新状态。一般情况下，对结点的修改是结点的创建者，而不应该是其它对些结点数据的关注者，不然会增加操作复杂度与不确定性。
如何对10亿数据量级的mongoDB作高效的全表扫描
一、正常情况下，不应该有这种需求
首先，大家应该有个概念，标题中的这个问题，在大多情况下是一个伪命题，不应该被提出来。要知道，对于一般较大数据量的数据库，全表查询，这种操作一般情况下是不应该出现的，在做正常查询的时候，如果是范围查询，你至少应该要加上limit。
说一下，我的应用场景：用于全量建立搜索引擎的索引。这就是一种需要用到全表扫描的非一般情况。对于全表扫描的结果，我们没有排序要求。