知识总结--其他应用组件(转载)

强大的搜索引擎框架：elastaticsearch

elastaticsearch设计之初的目标就是：让每个公司可以轻松搭建自己的搜索引擎，它的确做到了。它可以用于全文搜索、结构化搜索以及数据分析，它基于Lucene框架 ，Lucene是当今世上最高效、最先进的搜索引擎框架。Elasticsearch使用Lucene作为内部引擎，但是在使用它做全文搜索时，只需要使用统一开发好的API即可，而不需要了解其背后复杂的Lucene的运行原理。

当然Elasticsearch并不仅仅是Lucene这么简单，它不但包括了全文搜索功能，还可以进行以下工作:

• 分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索。

• 实时分析的分布式搜索引擎。

• 可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。

Elasticsearch上手简单，只需简单的安装以及修改普通参数即可使用，几乎不需要修改参数配置，它的默认参数配置大都比较合理。但elasticsearch支持的数据结构简单：仅支持json格式，拓展起来比较费事，需要各种插件来实现。elasticsearch非常适合需要建立实时索引的场景，当建立索引后它的搜索效率极高，完全可以与搜索引擎相媲美，而且效率较为稳定，不会随着数据量的增加造成大幅度波动。

老牌搜索框架：solr

solr是一个老牌搜索框架，其功能强大、支持多种索引格式：PDF、HTML、XML、JSON、CSV等，并支持定制化，使用更灵活，服务稳定，在不考虑建索引的消耗时其搜索速度要优于elasticsearch，但是它的搜索效率随着数据量的增加下降比较明显。

总的来讲对于实时变动的并且数据量较大的场景用es，而对于已有数据搜索的数据量并不是很大的场景用solr更好。

zookeeper

zookeeper是一个分布式的开源的分布式场景协调服务。zookeeper设计之初是用来作为文件系统，因此它的数据结构就是类似于文件目录，根节点是/每增加一个节点便增加一个/来区分。随着研究深入zookeeper目前常用于配置维护、分布式机器协调、域名服务、分布式同步、服务发现等等，是Hbase的重要组件，它提供java和C接口使用。zookeeper并不是为了高可用分布式协调而设计的因此他的，因此zookeeper有很多的局限性。

1、zookeeper集群只会选举出一个master，对于多机房一旦出现机房出错所有的流量都会留到一台zk上会造成系统crasher。

2、zk的选举过程很慢，zk对网络波动极其敏感，一旦有波动就要重新选举master机器，每次选举大概要消耗30秒以上。不可用状态的时间较多

3、zk的性能不高，单台tps不过1W，是无法撑起类似JD、TB这样的场景，因此虽然ZK的目录结构非常适合分布式锁但网络流量高的公司都不会使用zk做分布式锁。

4、zk的权限控制很弱，一般在使用zk时都需要单独开发一个权限系统。

5、由于它的性能一般、网络敏感因此在实际使用中经常会出现master与client数据不一致的情况，一旦发生这种情况会很棘手。

由于以上几个缺点，zk一般不会用于系统的一致性保证即分布式锁实现，常用于机器监控、机器发现和系统配置管理等访问不会太频繁的场景。

nginx

nginx是一个高性能的http和反向代理用C语言开发的开源工具。它稳定高效功能丰富、资源消耗极低、并发能力极强可以支持高达50000并发请求的负载均衡，除了硬件负载均衡（如F5）之外，nginx目前几乎是互联网公司实现负载均衡首选工具。nginx常用于前后端分离和负载均衡。最早开发这一服务的目的是作为邮件服务器。安装简单、配置简洁即便是没有基础的人也可以轻松上手，它可以7*24小时数月不重启运行，并且支持不停机更新。