Redis哨兵模式和Cluster集群以及ES

Redis哨兵模式

哨兵模式是主从的升级版。解决了主从无法自动将从服务器升级为主服务器的问题。
他主要有三个功能分别是监控、提醒、自动故障迁移
监控:他会不断地检查你的主从服务器是否运行正常,其主要方式就是通过不断地ping你的主从服务器
提醒:当被监控的Redis服务器出现问题时就会给管理员发消息,通知该服务器出问题了
自动故障迁移:当主服务器挂掉时,从服务器就会自动提升为主服务器,从而维持整个项目的正常运行

主观下线:当有一个从服务器在规定时间内没有回应就会被判定为主观下线状态
客观下线:当有半数以上的哨兵进程在指定时间范围内判定该主服务器进入了主观下线状态,则该主服务器就为客观下线
故障转移当前哨兵虽然发现了主数据客观下线,需要故障恢复,但故障恢复需要由领头哨兵来完
成。这样来保证同一时间只有一个哨兵来执行故障恢复,选出领头哨兵后,领头哨兵将会
开始对主数据库进行故障恢复。
首先是从主服务器的从服务器中选出一个从服务器作为新的主服务器。选出之后通过
slaveif no ont将该从服务器升为新主服务器。

Redis-Cluster集群

为什么要Redis-Cluster:redis的哨兵模式基本已经可以实现高可用,读写分离 ,但是在这种模式下每台redis服务器都存储相同的数据,很浪费内存,所以在redis3.0上加入了cluster模式, 实现的redis的分布式存储,也就是说每台redis节点上存储不同的内容 。

数据分散存储

Redis 集群没有并使用传统的一致性哈希来分配数据,而是采用另外一种叫做 哈希槽
(hash slot) 的方式来分配的。redis cluster 默认分配了 16384 个slot,当我们set一个key
时,会用 CRC16 算法来取模得到所属的 slot ,然后将这个key 分到哈希槽区间的节点
上,具体算法就是: CRC16(key) % 16384 。

容错机制-投票

为了防止主节点数据丢失,可以为每个主节点可以准备特点数目的备节点,主节点挂掉从
节点可以升级为主节点(哨兵模式) 。
容错机制指的是,如果半数以上master节点与故障节点通信超过(cluster-node-timeout),认
为该节点故障,自动触发故障转移操作. 故障节点对应的从节点自动升级为主节点 , 如
果某个主挂掉,而没有从节点可以使用,那么整个Redis集群进入宕机状态

ElasticSearch

ES的特点

  • 分布式的实时文件存储

  • 分布式全文搜索引擎,每个字段都被索引并可被搜索

  • 能在分布式项目/集群中使用

  • 本身支持集群扩展,可以扩展到上百台服务器

  • 处理PB级结构化或非结构化数据

  • 简单的 RESTful API通信方式

  • 支持各种语言的客户端

  • 基于Lucene封装,使操作简单

ES和lucene的区别

  • Lucene只支持Java,ES支持多种语言
  • Lucene非分布式,ES支持分布式
  • Lucene非分布式的,索引目录只能在项目本地 , ES的索引库可以跨多个服务分片存储
  • Lucene使用非常复杂 , ES屏蔽了Lucene的使用细节,操作更方便
  • 单体/小项目使用Lucene ,大项目,分布式项目使用ES

其他全文搜索引擎

Solr(重量级对手)

Apache Lucene项目的开源企业搜索平台。其主要功能包括全文检索、命中标示、分面搜索、动态聚类、数据库集成,以及富文本(如Word、PDF)的处理。Solr是高度可扩展的,并提供了分布式搜索和索引复制。Solr是最流行的企业级搜索引擎,Solr4 还增加了NoSQL支持。

Solr和ES比较:

Solr 利用 Zookeeper(注册中心) 进行分布式管理,支持更多格式的数据(HTML/PDF/CSV),官方提供的功能更多在传统的搜索应用中表现好于 ES,但实时搜索效率低。

ES自身带有分布式协调管理功能,但仅支持json文件格式,本身更注重于核心功能,高级功能多有第三方插件提供,在处理实时搜索应用时效率明显高于 ES。

Katta

基于 Lucene 的,支持分布式,可扩展,具有容错功能,准实时的搜索方案。

优点:开箱即用,可以与 Hadoop (大数据)配合实现分布式。具备扩展和容错机制。

缺点:只是搜索方案,建索引部分还是需要自己实现。在搜索功能上,只实现了最基本的需求。成功案例较少,项目的成熟度稍微差一些。

HadoopContrib

大数据相关的东西 (大数据工程师)

Map/Reduce 模式(云计算)的,分布式建索引方案,可以跟 Katta 配合使用。

优点:分布式建索引,具备可扩展性。

缺点:只是建索引方案,不包括搜索实现。工作在批处理模式,对实时搜索的支持不佳。

ES的核心概念

几个基本概念

Near Realtime(NRT)

近实时,两个意思,从写入数据到数据可以被搜索到有一个小延迟(大概1秒);基于es执行搜索和分析可以达到秒级

Index:索引库

包含一堆有相似结构的文档数据,比如可以有一个客户索引,商品分类索引,订单索引,索引有一个名称。一个index包含很多document,一个index就代表了一类类似的或者相同的document。比如说建立一个product index,商品索引,里面可能就存放了所有的商品数据,所有的商品document。

Type:类型

每个索引里都可以有一个或多个type,type是index中的一个逻辑数据分类,一个type下的document,都有相同的field,比如博客系统,有一个索引,可以定义用户数据type,博客数据type,评论数据type。

Document&field

文档,es中的最小数据单元,一个document可以是一条客户数据,一条商品分类数据,一条订单数据,通常用JSON数据结构表示,每个index下的type中,都可以去存储多个document。一个document里面有多个field,每个field就是一个数据字段。

集群相关概念

Cluster:集群

包含多个节点,每个节点属于哪个集群是通过一个配置(集群名称,默认是elasticsearch)来决定的,对于中小型应用来说,刚开始一个集群就一个节点很正常

Node:节点

集群中的一个节点,节点也有一个名称(默认是随机分配的),节点名称很重要(在执行运维管理操作的时候),默认节点会去加入一个名称为"elasticsearch"的集群,如果直接启动一堆节点,那么它们会自动组成一个elasticsearch集群,当然一个节点也可以组成一个elasticsearch集群

shard(分片)

单台机器无法存储大量数据,es可以将一个索引中的数据切分为多个shard,分布在多台服务器上存储。有了shard就可以横向扩展,存储更多数据,让搜索和分析等操作分布到多台服务器上去执行,提升吞吐量和性能。每个shard都是一个lucene index。

replica(复制品)

任何一个服务器随时可能故障或宕机,此时shard可能就会丢失,因此可以为每个shard创建多个replica副本。replica可以在shard故障时提供备用服务,保证数据不丢失,多个replica还可以提升搜索操作的吞吐量和性能。primary shard(建立索引时一次设置,不能修改,默认5个),replica shard(随时修改数量,默认1个),默认每个索引10个shard,5个primary shard,5个replica shard,最小的高可用配置,是2台服务器。

你可能感兴趣的:(搜索引擎)