Elasticsearch分布式架构原理，我们真的需要知道，很重要

2019-11-04 08:54:53 服务器 Elasticsearch用于构建高可用和可扩展的系统。扩展的方式可以是购买更好的服务器(纵向扩展(vertical scale or scaling up))或者购买更多的服务器(横向扩展(horizontal scale or scaling out))。

Elasticsearch用于构建高可用和可扩展的系统。扩展的方式可以是购买更好的服务器(纵向扩展(vertical scale or scaling up))或者购买更多的服务器(横向扩展(horizontal scale or scaling out))。

Elasticsearch虽然能从更强大的硬件中获得更好的性能，但是纵向扩展有它的局限性。真正的扩展应该是横向的，它通过增加节点来均摊负载和增加可靠性。

对于大多数数据库而言，横向扩展意味着你的程序将做非常大的改动才能利用这些新添加的设备。对比来说，Elasticsearch天生就是分布式的：它知道如何管理节点来提供高扩展和高可用。这意味着你的程序不需要关心这些。

ES 如何实现分布式

添加索引

es 中存储数据的基本单位是索引，我们为了将数据添加到ES中，就需要添加索引(index)

这里需要说一下ES中索引与分片(shard)的关系：一个分片(shard)是一个最小级别“工作单元(worker unit)”,它只是保存了索引中所有数据的一部分;所有的文档均存在分片中，而直接与应用程序进行交互的再而三索引。

下面我们以酒店搜索为例，添加所有酒店索引hotel_idx

我们启动三个ES节点，当前hotel_idx 分配3个主分片(primary shard)，每个主分片1个副本分片(replica shard)。

1，ES Client 会挑一个Node，上面挑选了NODE1，则成为协调节点，进行写入数据，此时ES怎么才能知道将一个文档(一条酒店数据)路由到哪个分片中呢，实际上，他是根据这个公式：

routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值，这里可以是酒店的hotel_id。routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards (主分片的数量)后得到 余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。

2，写完P0后就会同步到他的副本R0中去，同步成功则会返回给协调节点Node1,最后返回Client

3，ES client读取数据均可以读取主副分片

如何保证高可用

如何可扩展

ES在创建索引时就需要指定主分片的数量，所以主分片指定了是不能再扩充的，当存储容量超过了目前的ES节点，一般有些生产做法是，重新再建立了新索引比目前多一点shard，然后导入数据，但这种也是有些缺点的:这样做将消耗的时间是我们无法提供的;

我们一般的做法是事先进行预分配，通过事先规划，我们可以使用 预分配 的方式来完全避免这个问题。

其中，副本分片是可以动态扩展的，在读取很大的场景下，适当的扩充副本会增加吞吐量。

如何预估分片容量

其实这个是不好解释的，因为实在有太多相关的因素了：你使用的硬件、文档的大小和复杂度、文档的索引分析方式、运行的查询类型、执行的聚合以及你的数据模型等等。

生产中经验建议：

1，基于你准备用于生产环境的硬件创建一个拥有单个节点的集群。

2，创建一个和你准备用于生产环境相同配置和分析器的索引，但让它只有一个主分片无副本分片。索引实际的文档(或者尽可能接近实际)。

3，运行实际的查询和聚合(或者尽可能接近实际)。

基本来说，你需要复制真实环境的使用方式并将它们全部压缩到单个分片上直到它“挂掉。” 实际上 挂掉 的定义也取决于你：一些用户需要所有响应在 50 毫秒内返回;另一些则乐于等上 5 秒钟。

所以，一旦你定义好了单个分片的容量，很容易就可以推算出整个索引的分片数。用你需要索引的数据总数加上一部分预期的增长，除以单个分片的容量，结果就是你需要的主分片个数。

memcached和redis的区别

medis与Memcached的区别传统MySQL+ Memcached架构遇到的问题　实际MySQL是适合进行海量数据存储的，通过Memcached将热点数据加载到cache，加速访问，很多公司都曾经使用过这样的架构，但随着业务数据量的不断增加，和访问量的持续增长，我们遇到了很多问题：　需要不断进行拆库拆表，Memcached也需不断跟着扩容，扩容和维护工作占据大量开发时间。 与MySQL数据库数据一致性问题。 数据命中率低或down机，大量访问直接穿透到DB，MySQL无法支撑。 4.跨机房cache同步问题。 众多NoSQL百花齐放，如何选择　最近几年，业界不断涌现出很多各种各样的NoSQL产品，那么如何才能正确地使用好这些产品，最大化地发挥其长处，是我们需要深入研究和思考的问题，实际归根结底最重要的是了解这些产品的定位，并且了解到每款产品的tradeoffs，在实际应用中做到扬长避短，总体上这些NoSQL主要用于解决以下几种问题　1.少量数据存储，高速读写访问。 此类产品通过数据全部in-momery 的方式来保证高速访问，同时提供数据落地的功能，实际这正是Redis最主要的适用场景。 2.海量数据存储，分布式系统支持，数据一致性保证，方便的集群节点添加/删除。 3.这方面最具代表性的是dynamo和bigtable 2篇论文所阐述的思路。 前者是一个完全无中心的设计，节点之间通过gossip方式传递集群信息，数据保证最终一致性，后者是一个中心化的方案设计，通过类似一个分布式锁服务来保证强一致性,数据写入先写内存和redo log，然后定期compat归并到磁盘上，将随机写优化为顺序写，提高写入性能。 free，auto-sharding等。 比如目前常见的一些文档数据库都是支持schema-free的，直接存储json格式数据，并且支持auto-sharding等功能，比如mongodb。 面对这些不同类型的NoSQL产品,我们需要根据我们的业务场景选择最合适的产品。 Redis适用场景，如何正确的使用　前面已经分析过，Redis最适合所有数据in-momory的场景，虽然Redis也提供持久化功能，但实际更多的是一个disk-backed的功能，跟传统意义上的持久化有比较大的差别，那么可能大家就会有疑问，似乎Redis更像一个加强版的Memcached，那么何时使用Memcached,何时使用Redis呢?如果简单地比较Redis与Memcached的区别，大多数都会得到以下观点：　1Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。 2Redis支持数据的备份，即master-slave模式的数据备份。 3Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。 抛开这些，可以深入到Redis内部构造去观察更加本质的区别，理解Redis的设计。 在Redis中，并不是所有的数据都一直存储在内存中的。 这是和Memcached相比一个最大的区别。 Redis只会缓存所有的 Key的信息，如果Redis发现内存的使用量超过了某一个阀值，将触发Swap的操作，Redis根据“swappability = age*log(size_in_memory)”计 算出哪些key对应的value需要swap到磁盘。 然后再将这些key对应的value持久化到磁盘中，同时在内存中清除。 这种特性使得Redis可以 保持超过其机器本身内存大小的数据。 当然，机器本身的内存必须要能够保持所有的key，毕竟这些数据是不会进行swap操作的。 同时由于Redis将内存 中的数据swap到磁盘中的时候，提供服务的主线程和进行swap操作的子线程会共享这部分内存，所以如果更新需要swap的数据，Redis将阻塞这个 操作，直到子线程完成swap操作后才可以进行修改。 使用Redis特有内存模型前后的情况对比：　VM off: 300k keys, 4096 bytes values: 1.3G used　VM on:300k keys, 4096 bytes values: 73M used　VM off: 1 million keys, 256 bytes values: 430.12M used　VM on:1 million keys, 256 bytes values: 160.09M used　VM on:1 million keys, values as large as you want, still: 160.09M used当 从Redis中读取数据的时候，如果读取的key对应的value不在内存中，那么Redis就需要从swap文件中加载相应数据，然后再返回给请求方。 这里就存在一个I/O线程池的问题。 在默认的情况下，Redis会出现阻塞，即完成所有的swap文件加载后才会相应。 这种策略在客户端的数量较小，进行 批量操作的时候比较合适。 但是如果将Redis应用在一个大型的网站应用程序中，这显然是无法满足大并发的情况的。 所以Redis运行我们设置I/O线程 池的大小，对需要从swap文件中加载相应数据的读取请求进行并发操作，减少阻塞的时间。 如果希望在海量数据的环境中使用好Redis，我相信理解Redis的内存设计和阻塞的情况是不可缺少的。

JAVA专业主要针对些什么样的工作？

1.熟练掌握Java各种常用设计模式； 2.能够熟练应用Spring的Ioc(控制反转)机制，熟悉AOP编程； 3.熟悉Hibernate框架及其映射原理，能够熟练使用jsp,servlet,jstl,jdbc,jndi,JavaBean,Ajax进行编程，能够运用SSH(Struts+Spring+Hibernate)进行开发，实现复杂的MVC架构； 4.熟练使用Tomcat,Weblogic等J2EE应用服务器；服务器的安装配置、连接池、数据源、JNDI技术、JAVA分布式平台技术、Weblogic—EJB—Oracle企业级应用； 5.熟悉UML，能够使用Rational Rose进行系统的建模和设计； 6.精通SQL语言，熟练应用Oracle,MySql数据库； 7.能够熟练使用Eclipse进行开发

背板带宽是什么？

1、背板带宽和交换架构有什么区别？交换架构是指数据穿越设备的方式。 主要有：总线型：数据包通过总线达到所有端口，然后由中央处理器告诉每个端口是继续转发还是丢弃该数据包。 共享内存型：数据包被放到共享内存中，然后中央处理器告诉应该转发数据的端口/模块到指定位置读取数据。 交叉矩阵型：数据通过交叉矩阵开关直接送往该去的模块/端口。 可以由中央处理器决定送往方向，也可以由输入模块自己决定。 后者也就是分布式处理。 一般只有交叉矩阵型可以做到完全的分布式处理。 背板带宽是指数据包穿越设备时可以用到的带宽总和。 总线型就是总线的宽度，共享型是每个模块到达中央处理器的总线宽带的总和，交叉矩阵型是每个模块连接到矩阵的总线带宽的总和。