这几年O2O火爆，10个创业公司里就有9个是O2O的电商，相信支付抢购什么的以前听起来高大上的东西现在很多码农都会需要自己去实现。
说到支付，就一定会涉及到事务。说到事务，肯定很多码农泪千行。
在原来的数据库单机时代，你写一个事务并没有什么关系，我的支付逻辑涉及的所有表可能都在同一个数据库里，MySQL原生支持这些东西，学校里的老师也会跟你讲，事务是保证数据完整性的重要手段。
然而到了SOA时代，网站服务化，可能你的账户表和流水表都不在一个数据库里了(只是举例，不要太较真)。这种时候就有了分布式事务的概念。然后就有了各种二阶段提交，分布式CAP的取舍，基于消息队列实现的分布式事务等等等等。
扯远了，本文并不是想讲这些东西。
在大厨工作的时候听同事介绍过乐观锁这个概念，一开始以为是Java还是什么语言的语言特性，后来发现其实是一种写入、更新数据库时的逻辑特性。。
具体是这样的：
1.在需要加乐观锁的表中加入version字段
2.update时，
上一篇讲到了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/
