上一篇讲到了ES的river数据导入，但是看起来这么简单的流程也还是有一些坑，比如在我导入我司的一个3kw表内容时就碰到了整个虚拟机都卡住，几乎无法登陆的问题。
因为es和river插件都是用java写的，这种时候感觉就有点手足无措。但是在es的日志里发现了频繁GC的信息。每次垃圾回收都会持续很长时间。这种现象在Java界还有一个很有意思的称谓：
> Stop the world
援引一下别人的说明：
Stop the world 机制简称STW,即,在执行垃圾收集算法时,Java应用程序的其他所有除了垃圾收集帮助器线程之外的线程都被挂起
说起STW，只要有GC的语言都会遇到这个问题。Go在1.5之前的GC也是一直为人所诟病，而且像STW这种情况就更严重了啊，整个一台机器直接就没办法向外提供服务了。之前看到360和小米工程师在go语言早期GC不给力的时候怎么解决这种问题呢~靠重启。。你没看错，就是靠重启。
再说到前面的问题，我们只看STW的描述的话会发现：额，
这两个概念其实很早之前就听说了，近一年也一直在查找相关的资料。并且有意无意地读了一些相关的书籍。
前几天在《程序员的呐喊》里看到亚马逊在2002年的时候，是贝索斯突然向公司程序员们发出以下指令：
1.从今天起，所有的团队都要以服务接口的方式提供数据和各种功能。
2.团队之间必须通过接口来通信。
3.不允许任何其他形式的互操作：不允许直接链接，不允许直接读其他团队的数据，不允许共享内存，不允许任何形式的后门。唯一许可的通信方式就是通过网络调用服务。
4.至于具体的技术不做规定。HTTP、Corba、Pubsub、自定义协议都可以，贝索斯不关心这个。
5.所有的服务接口，必须从一开始就要以可以公开为设计导向，没有例外。这就是说，团队必须在设计的时候就计划好，接口要可以对外面的开发人员开放，
虽然花了几天时间调研Solr，后来还是觉得Elasticsearch更靠谱呐，你看支持原生的分片、副本、集群分布式还不用借助zookeeper或者etcd，不用你自己去了解一大堆分布式系统的知识才能开始捣腾，而且还是开源界的新贵
当然其实都2.0了其实也不是很新。
总之就是看上去比apache基金会的那个靠谱，咳咳。如果你更关心它们具体的区别，可以参考这里
> http://solr-vs-elasticsearch.com/
elasticsearch的环境搭建其实都没什么好讲的，因为实在是对新人太友好了嗯，相比之下Solr就显得有那么一点神坑
其实也只是我没有认真读文档，急功近利想马上就搭起来用的原因啦。
搭建一个单机的es非常的简单。
step 1:
wget -c https://download.elasticsearch.org/elasticsearch/release/org/
先说说Solr来索引MySQL数据有什么优点~
我们的数据库表有很大的表，每天20w数据插入，表里已经累积了2900w的数据，而业务需求又需要一些比较实时的筛选count，遇到一些复杂的count的话MySQL返回结果都是以秒计算。严重拖慢了整个系统的性能。
所以有了搭建搜索引擎来索引MySQL里数据的需求。
之前虽然翻译了一篇5分钟搭建Solr的教程，然而到了导入MySQL这一步还是遇到了很多坑，泪。
因为Solr本身的文档写得不够美丽(滚，而且在网上搜导入MySQL数据的教程都是要么语焉不详，要么都是用的老版本的Solr，所以悲催地踩了两天坑，才终于搭好了基本功能。
下面做一下简单的记录：
1.安装
wget -c http://mirror.bit.edu.cn/apache/lucene/solr/5.3.1/
网站做大了以后，因为MySQL在较高的qps下表现比较差，如果是创业公司的话，那可能租用的都是公有云的机器来做自己的服务，也许就是个内存2GB，cpu两核的kvm，能够使用的资源非常非常的少，所以数据库的实例本身性能也不会好到哪里去。在整体qps达到一定量级之后必然会遇到性能低下的问题，至于这个临界值，是由具体的机器配置得到的，这里就不给出什么结果了，感兴趣的同学可以自己去搜索。
MySQL抗不住的情况下只能引入缓存来提升整体性能了，网站开发有一个比较著名的二八原则，就是80%的用户其实访问的都是20%的数据。所以实际上你只要把这20%的数据缓存好，就可以让网站整体的响应和吞吐量上一个等级。缓存为什么能比去读数据库快？原理也很简单，大多数的缓存会把数据存储在内存中，而数据库则是要去硬盘读取。这两种介质在速度上相差了好几个数量级。
缓存固然好，但假如你的网站变得越来越大的时候，可能会慢慢发现单台机器已经满足不了自己的需求了。这时候就涉及到缓存分布的问题，如果是一个在学校里没有接触过工程项目的人的话，很容易想出来按照请求@key，
