es文件浏览器读取小米路由器外接移动硬盘

你好！es文件浏览器读取小米路由器外接移动硬盘具体步骤如下：

1、首先打开“小米WiFi”app，点右下角的“工具箱”，选择“更多工具”。

2、打开“SAMBA”，并启用。

3、接着打开ES文件浏览器，点右上角的三个点，然后在出来的选项中点“新建”。

4、点击“类型”并选择“samba局域网”。

5、在路径栏输入 192.168.31.1，再点“确定”。

6、这时已经可以看到小米路由器硬盘中的内容了。

7、为了方便以后再次访问，可以把路径添加到桌面。首先要对ES文件浏览器的权限进行设置，把“桌面快捷方式”设为“允许”。

8、然后回到ES文件浏览器，长按“XiaoMi”文件夹，点右下角的“更多”，在出现的选项中选择“添加到桌面”，这样就可以通过桌面快捷方式方便地访问路由器中的文件啦。，

本节主要深入一些原理型的知识，包括document路由原理，写一致性，读取以及增删改等请求的原理

（1）document路由到shard上是什么意思？

一个index的数据会被分为多个shard中。所以说一个document，只能存在于一个shard中。当客户端创建document的时候，es此时就需要决定这个document是放在这个index的哪个shard上。这个过程,就称之为document routing，即数据路由。

（2）路由算法：shard = hash(routing) % number_of_primary_shards

举个例子，一个index有3个primary shard，P0，P1，P2

每次增删改查一个document的时候，都会带过来一个routing number，默认就是这个document的id（可能是手动指定，也可能是自动生成）ES会将这个routing值，传入一个hash函数中，产出一个routing值的hash值，hash(routing) = 21。然后将hash函数产出的值对这个index的primary shard的数量求余数，21 % 3 = 0。ES就把这个document就放在P0上。（由这个就可以知道primary_shards的数量为什么是固定的了）

（3）手动指定routing： _id or custom routing value

默认的routing就是_id，也可以在发送请求的时候，手动指定一个routing，比如说

具体 *** 作参见官方文档

_routing field | Elasticsearch Reference [7.6] | Elastic https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-routing-field.html

手动指定routing value是很有用的，可以保证说，某一类document一定被路由到一个shard上去，那么在后续进行应用级别的负载均衡，以及提升批量读取的性能的时候，是很有帮助的

（1）客户端选择一个node发送请求过去，这个node就是coordinating node（协调节点）

（2）coordinating node，对document进行路由，将请求转发给对应的node（有primary shard）

（3）实际的node上的primary shard处理请求，然后将数据同步到replica node

（4）coordinating node，如果发现primary node和所有replica node都搞定之后，就返回响应结果给客户端

consistency已经废弃了。

使用 wait_for_active_shards进行设置，默认值为1，即只要求主分片处于活动状态， 还可以设置为2，3等，就是大于0，小于number_of_replicas+1的正整数。

wait_for_active_shards=all表示number_of_replicas+1，即该索引所有分片的总数。

具体说明参见官方文档：

Index API | Elasticsearch Reference [7.6] | Elastic https://www.elastic.co/guide/en/elasticsearch/reference/7.6/docs-index_.html#index-wait-for-active-shards

1、客户端发送请求到任意一个node，成为coordinate node

2、coordinate node对document进行路由，将请求转发到对应的node，此时会使用round-robin随机轮询算法，在primary shard以及其所有replica中随机选择一个，让读请求负载均衡

3、接收请求的node返回document给coordinate node

4、coordinate node返回document给客户端

5、特殊情况：document如果还在建立索引过程中，可能只有primary shard有，任何一个replica shard都没有，此时可能会导致无法读取到document，但是document完成索引建立之后，primary shard和replica shard就都有了

1、bulk中的每个 *** 作都可能要转发到不同的node的shard去执行

2、如果采用比较良好的json数组格式

允许任意的换行，整个可读性非常棒，读起来很爽，es拿到那种标准格式的json串以后，要按照下述流程去进行处理

（1）将json数组解析为JSONArray对象，这个时候，整个数据，就会在内存中出现一份一模一样的拷贝，一份数据是json文本，一份数据是JSONArray对象

（2）解析json数组里的每个json，对每个请求中的document进行路由

（3）为路由到同一个shard上的多个请求，创建一个请求数组

（4）将这个请求数组序列化

（5）将序列化后的请求数组发送到对应的节点上去

3、耗费更多内存，更多的jvm gc开销

我们之前提到过bulk size最佳大小的那个问题，一般建议说在几千条那样，然后大小在10MB左右，所以说，可怕的事情来了。假设说现在100个bulk请求发送到了一个节点上去，然后每个请求是10MB，100个请求，就是1000MB = 1GB，然后每个请求的json都copy一份为jsonarray对象，此时内存中的占用就会翻倍，就会占用2GB的内存，甚至还不止。因为弄成jsonarray之后，还可能会多搞一些其他的数据结构，2GB+的内存占用。占用更多的内存可能就会积压其他请求的内存使用量，比如说最重要的搜索请求，分析请求，等等，此时就可能会导致其他请求的性能急速下降.

另外的话，占用内存更多，就会导致java虚拟机的垃圾回收次数更多，跟频繁，每次要回收的垃圾对象更多，耗费的时间更多，导致es的java虚拟机停止工作线程的时间更多

4、现在的奇特格式

（1）不用将其转换为json对象，不会出现内存中的相同数据的拷贝，直接按照换行符切割json

（2）对每两个一组的json，读取meta，进行document路由

（3）直接将对应的json发送到node上去

5、最大的优势在于，不需要将json数组解析为一个JSONArray对象，形成一份大数据的拷贝，浪费内存空间，尽可能地保证性能

膜拜一下大神的文章：

Day1: 大规模Elasticsearch集群管理心得 - Elastic 中文社区 https://elasticsearch.cn/article/110

---