㈠ spring boot动态修改es的连接地址
在项目启动后，使用修改配置文件+restart（）连接/连接池对象的方法解决。
使用读写锁，给restart（）、setUrl（）等代码块加写锁，给数据库操作方法加读锁。这样就可以在修改数据库连接信息时，先获取写锁，保证数据库操作方法不能执行。而在不修改连接时，数据库操作方法之间获取的是读锁，不会影响线程彼此之间的操作。
㈡ 求大神解答安卓手机es管理器加密原理
因为文件已经被加密，你需要解密才行
㈢ ES - 并发冲突问题
ES基于自身乐观锁进行并发控制
ES基于Document中的version字段进行并发控制，初始创建version为1
每次需要带上version进行更新，该步骤需要多次，特别是在多线程环境下
基于external version进行并发控制
ES提供了一个插件，可以不用它提供的version，可以基于自己维护的一个版本号进行控制, 详细语法
这里需要关注两点
1.ES提供的version需要与ES中的version一摸一样的时候才可以进行修改
2.external version提供的version比ES中的version大的时候才可以进行修改
partial update 部分修改
释义：每次传递需要发生修改的Field，不需要将全量的document传递过去
语法如下
Partial Update内部原理和传统PUT方式内部原理是一样的，会将老的Document标记为deleted，然后创建一个新的Document。
Partial Update相较于全量替换的优点如下
1.所有的查询，修改和写入操作，都发生在ES中的一个shard 内部，避免了网络数据传输开销（减少两次网络请求），大大的提升了性能
2.减少了查询和修改的时间间隔，可以减少并发冲突的情况
Partial Update的并发控制
Retry策略,语法如下
上面语法的意思是重新拿到版本号进行更新，最多重试五次
㈣ Oracle数据库锁的常用类型有哪些
Oracle数据库的锁类型
根据保护的对象不同，Oracle数据库锁可以分为以下几大类：DML锁（data locks，数据锁），用于保护数据的完整性；DDL锁（dictionary locks，字典锁），用于保护数据库对象的结构，如表、索引等的结构定义；内部锁和闩（internal locks and latches），保护数据库的内部结构。
DML锁的目的在于保证并发情况下的数据完整性，本文主要讨论DML锁。在Oracle数据库中，DML锁主要包括TM锁和TX锁，其中TM锁称为表级锁，TX锁称为事务锁或行级锁。
当Oracle执行DML语句时，系统自动在所要操作的表上申请TM类型的锁。当TM锁获得后，系统再自动申请TX类型的锁，并将实际锁定的数据行的锁标志位进行置位。这样在事务加锁前检查TX锁相容性时就不用再逐行检查锁标志，而只需检查TM锁模式的相容性即可，大大提高了系统的效率。TM锁包括了SS、SX、S、X等多种模式，在数据库中用0－6来表示。不同的sql操作产生不同类型的TM锁。如表1所示。
在数据行上只有X锁（排他锁）。在 Oracle数据库中，当一个事务首次发起一个DML语句时就获得一个TX锁，该锁保持到事务被提交或回滚。当两个或多个会话在表的同一条记录上执行DML语句时，第一个会话在该条记录上加锁，其他的会话处于等待状态。当第一个会话提交后，TX锁被释放，其他会话才可以加锁。
当Oracle数据库发生TX锁等待时，如果不及时处理常常会引起Oracle数据库挂起，或导致死锁的发生，产生ORA-60的错误。这些现象都会对实际应用产生极大的危害，如长时间未响应，大量事务失败等。
TX锁等待的分析
在介绍了有关地Oracle数据库锁的种类后，下面讨论如何有效地监控和解决锁等待现象，及在产生死锁时如何定位死锁的原因。
监控锁的相关视图 数据字典是Oracle数据库的重要组成部分，用户可以通过查询数据字典视图来获得数据库的信息。和锁相关的数据字典视图如表2所示。
TX锁等待的监控和解决在日常工作中，如果发现在执行某条SQL时数据库长时间没有响应，很可能是产生了TX锁等待的现象。为解决这个问题，首先应该找出持锁的事务，然后再进行相关的处理，如提交事务或强行中断事务。
死锁的监控和解决在数据库中，当两个或多个会话请求同一个资源时会产生死锁的现象。死锁的常见类型是行级锁死锁和页级锁死锁，Oracle数据库中一般使用行级锁。下面主要讨论行级锁的死锁现象。
当Oracle检测到死锁产生时，中断并回滚死锁相关语句的执行，报ORA-00060的错误并记录在数据库的日志文件alertSID.log中。同时在user_mp_dest下产生了一个跟踪文件，详细描述死锁的相关信息。
在日常工作中，如果发现在日志文件中记录了ora-00060的错误信息，则表明产生了死锁。这时需要找到对应的跟踪文件，根据跟踪文件的信息定位产生的原因。
如果查询结果表明，死锁是由于bitmap索引引起的，将IND_T_PRODUCT_HIS_STATE索引改为normal索引后，即可解决死锁的问题。
表1 Oracle的TM锁类型
锁模式 锁描述 解释 SQL操作
0 none
1 NULL 空 Select
2 SS(Row-S) 行级共享锁，其他对象只能查询这些数据行 Select for update、Lock for update、Lock row share
3 SX(Row-X) 行级排它锁，在提交前不允许做DML操作 Insert、Update、Delete、Lock row share
4 S(Share) 共享锁 Create index、Lock share
5 SSX(S/Row-X) 共享行级排它锁 Lock share row exclusive
6 X(Exclusive) 排它锁 Alter table、Drop able、Drop index、Truncate table 、Lock exclusive
表2 数据字典视图说明
视图名 描述 主要字段说明
v$session 查询会话的信息和锁的信息。 sid,serial#：表示会话信息。
program：表示会话的应用程序信息。
row_wait_obj#：表示等待的对象。
和dba_objects中的object_id相对应。
v$session_wait 查询等待的会话信息。 sid：表示持有锁的会话信息。
Seconds_in_wait：表示等待持续的时间信息
Event：表示会话等待的事件。
v$lock 列出系统中的所有的锁。 Sid：表示持有锁的会话信息。
Type：表示锁的类型。值包括TM和TX等。
ID1：表示锁的对象标识。
lmode,request：表示会话等待的锁模式的信
息。用数字0－6表示，和表1相对应。
dba_locks 对v$lock的格式化视图。 Session_id：和v$lock中的Sid对应。
Lock_type：和v$lock中的type对应。
Lock_ID1： 和v$lock中的ID1对应。
Mode_held,mode_requested：和v$lock中
的lmode,request相对应。
v$locked_object 只包含DML的锁信息，包括回滚段和会话信息。 Xisn,xidslot,xidsqn：表示回滚段信息。和
v$transaction相关联。
Object_id：表示被锁对象标识。
Session_id：表示持有锁的会话信息。
Locked_mode：表示会话等待的锁模式的信
息，和v$lock中的lmode一致。
col owner for a12
col object_name for a16
select b.owner,b.object_name,l.session_id,l.locked_mode
from v$locked_object l, dba_objects b
where b.object_id=l.object_id;
select t2.username,t2.sid,t2.serial#,t2.logon_time
from v$locked_object t1,v$session t2
where t1.session_id=t2.sid order by t2.logon_time;
如果有长期出现的一列，可能是没有释放的锁。我们可以用下面SQL语句杀掉长期没有释放非正常的锁：
alter system kill session 'sid,serial# ';
如果出现了锁的问题, 某个DML操作可能等待很久没有反应。
当你采用的是直接连接数据库的方式，也不要用OS系统命令 $kill process_num 或者 $kill -9 process_num来终止用户连接，因为一个用户进程可能产生一个以上的锁, 杀OS进程并不能彻底清除锁的问题
Oracle锁表(死锁) 2011-05-03 17:46:41| 分类： Java技术 | 标签： |字号大中小 订阅 .
数据库与操作系统一样，是一个多用户使用的共享资源。 当多个用户并发地存取数据时，在数据库中就会发生多个事务同时存取同一数据地情况。 若对并发操作不加控制就可能会读取和存储不正确地数据，破坏数据库地一致性。 加锁时实现数据库并发控制地一个非常重要地技术。 在实际应用中经常会遇到地与锁相关地异常情况，当两个事务需要一组有冲突的锁，而不能将事务继续下去的话，就会出现死锁，严重影响应用的正常执行。
在数据库中有两种基本的锁类型：排它锁（Exclusive Locks，即X锁）和共享锁（即S锁）。当数据对象被加上排它锁时，其他的事务不能不能对它读取和修改。加了共享锁的数据对象可以被其他事务读取，但不能修改。数据库利用这两种基本的锁类型来对数据库的事务进行并发控制。
死锁的第一种情况：
一个用户A访问表A（锁住了表A），然后又访问表B； 另一个用户B访问表B（锁住了表B），然后企图访问表A；这时用户A由于用户B已经锁住表B，它必须等待用户B释放表B才能继续，同样用户B要等用户A释放表A才能继续，这就死锁产生了。
解决方法：
这种死锁比较常见，是由于程序的BUG产生的，除了调整程序的逻辑没有其它的办法。仔细分析程序的逻辑，对于数据库的多表操作时，尽量按照同样的顺序进行处理，尽量避免同时锁定两个资源，如操作A和B两张表时，总是按先A后B的顺序处理，必须同时锁定两个资源时，要保证在任何时刻都应该按照相同的顺序来锁定资源。
死锁的第二种情况
用户A查询一条记录，然后修改该条记录；这时用户B修改该条记录，这时用户A的事务里锁的性质由查询的共享锁企图上升到独占锁，而用户B里的独占锁由于A有共享锁存在必须等A释放掉共享锁，而A由于B的独占锁而无法上升到独占锁也就不可能释放共享锁，于是出现了死锁。这种死锁比较隐蔽，但在稍大点的项目种经常发生，如在某项目中，页面上的按钮点击后，没有使按钮立刻失效，使得用户会多次快速点击同一按钮，这样同一段代码对数据库同一条记录进行多次操作，很容易就出现这种死锁的情况。
解决方法：
1、对于按钮等控件，点击后使其立刻失效，不让用户重复点击，避免对同时对同一条记录操作。
2、使用乐观锁进行控制。乐观锁大多是基于数据版本（version）记录机制实现。即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库增加一个“version”字段来实现。读取处数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交的数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。乐观锁机制避免了长事务中的数据库加锁开销（用户A和用户B操作过程中，都没有对数据库加锁），大大提升了大并发量下的系统整体性表现。 Hibernate在其数据访问引擎中内置了乐观锁实现。需要注意的是，由于乐观锁机制是我们的系统中实现，来自外部系统的用户更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。
3、使用悲观锁进行控制。悲观锁大多数情况下依靠数据库的锁机制实现，如Oracle的select.......for update语句，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。如一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时（如更改用户帐户余额），如果采用悲观锁机制，也就意味整个操作过程中（从操作员读出数据、开始修改直至提交修改结果的全过程，甚至还包括操作员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对成百上千个并发，这样的情况将导致灾难性的结果。所以，采用悲观锁进行控制时一定要考虑清楚。
死锁的第三种情况
如果在事务种执行了一条不满足条件的update语句，则执行全表扫描，把行级锁上升为表级锁，多个这样的事务执行之后，就很容易发生死锁和阻塞。类似的情况还有当表种的数据量非常庞大而索引建的过少或不合适的时候，使得经常发生全表扫描，最终应用系统会越来越慢，最终发生阻塞或死锁。
解决方法：
SQL语句中不要使用太复杂的关联多表的查询；使用“执行计划”对SQL语句进行 分析，对于有全表扫描的SQL语句，建立相应的索引进行优化。
***查询死锁表以及解锁表***
通过select * from v$locked_object
可以获得被锁的对象的object_id及产生锁的会话sid，通过查询结果中的object_id，可以查询到具体被锁的对象。
锁有以下几种模式:
0：none
1：null 空
2：Row-S 行共享(RS / S锁)：共享表锁
3：Row-X 行专用(RX / X锁)：用于行的修改
4：Share 共享锁(S)：阻止其他DML操作
5：S/Row-X 共享行专用(SRX)：阻止其他事务操作
6：exclusive 专用(X)：独立访问使用
数字越大锁级别越高, 影响的操作越多。
一般的查询语句如select ... from ... ;是小于2的锁, 有时会在v$locked_object出现。
select ... from ... for update; 是2的锁。
当对话使用for update子串打开一个游标时，
所有返回集中的数据行都将处于行级(Row-X)独占式锁定，
其他对象只能查询这些数据行，不能进行update、delete或select...for update操作。
insert / update / delete ... ; 是3的锁。
没有commit之前插入同样的一条记录会没有反应,
因为后一个3的锁会一直等待上一个3的锁, 我们必须释放掉上一个才能继续工作。
创建索引的时候也会产生3,4级别的锁。
locked_mode为2,3,4不影响DML(insert,delete,update,select)操作,
但DDL(alter,drop等)操作会提示ora-00054错误。
有主外键约束时 update / delete ... ; 可能会产生4,5的锁。
DDL语句时是6的锁。
以DBA角色, 查看当前数据库里锁的情况可以用如下SQL语句：
select object_id,session_id,locked_mode from v$locked_object;
select t2.username,t2.sid,t2.serial#,t2.logon_time
from v$locked_object t1,v$session t2
where t1.session_id=t2.sid order by t2.logon_time;
如果有长期出现的一列，可能是没有释放的锁。
我们可以用下面SQL语句杀掉长期没有释放非正常的锁：
㈤ 用es文件浏览器加密的文件密码忘了，怎么解锁
只能不断地输入密码，直到输入正确，不然解不开的
加密过程如下所示：
1、点击左上方的“本地”图标。
2、久按要加密的文件，点击下方“更多”图标。
3、点击“加密”按钮即可。
㈥ 怎么理解数据库的锁 一般锁分别哪几种
数据库是一个多用户使用的共享资源。当多个用户并发地存取数据时，在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据，破坏数据库的一致性。
加锁是实现数据库并发控制的一个非常重要的技术。当事务在对某个数据对象进行操作前，先向系统发出请求，对其加锁。加锁后事务就对该数据对象有了一定的控制，在该事务释放锁之前，其他的事务不能对此数据对象进行更新操作。
在数据库中有两种基本的锁类型：排它锁（Exclusive Locks，即X锁）和共享锁（Share Locks，即S锁）。当数据对象被加上排它锁时，其他的事务不能对它读取和修改。加了共享锁的数据对象可以被其他事务读取，但不能修改。数据库利用这两种基本的锁类型来对数据库的事务进行并发控制。
(6)es数据库锁扩展阅读：
排它锁和共享锁的不同之处：
1、共享锁（S锁）：如果事务T对数据A加上共享锁后，则其他事务只能对A再加共享锁，不能加排他锁。获准共享锁的事务只能读数据，不能修改数据。
排他锁（X锁）：如果事务T对数据A加上排他锁后，则其他事务不能再对A加任任何类型的封锁。获准排他锁的事务既能读数据，又能修改数据。
2、共享锁下其它用户可以并发读取，查询数据。但不能修改，增加，删除数据，资源共享。
3、共享锁又称为读锁（Share lock,简记为S锁），若事务T对数据对象A加上S锁，则其它事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。
㈦ es索引有哪几种常见状态的
ES新手入门学习的时候，经常会和MySQL做对比，一个索引可以理解为一个数据库，分片就可以理解为一张表被分割了shards_numbers - 1次，文档类型为type类型，在高版本中在逐渐被剔除。
ES官方也给出了答案：作者不希望不同类型的相同字段在同一个Lucene中。
索引的状态有：红色、黄色、绿色和黑色四种（ES插件可以看出来）。
green：健康状态，代表所有的主分片和副本分片都可用；
yellow：所有的主分片可用，部分副本分片不可用；
red：部分主分片不可用；
black：索引处于关闭状态，不对外进行交互，一般磁盘空间不足时ES会自动设置。
ES是一款近实时的搜索引擎，而非实时的搜索引擎。ES每秒产生一个新分段，新段先写入文件系统缓存（对读取可见），稍后再执行刷盘操作。由于新段不会立即刷盘，这个过程如果出现意外情况，存在数据丢失的风险，通常做法是记录事务日志。
分片的目的不只是为了分割巨大的索引，还可以并发读。一个索引包含多个分片，一个分片是一个Lucene索引，一个Lucene索引又由很多分段组成，每一个分段都是一个倒排索引。
段合并：ES会选择大小相似的段进行合并，ES每次refersh都会生成一个Lucene段，每次查询都会轮流检查每一个段，查询完对结果进行合并，段越多，搜索也就越慢。由于分段的不变性（访问不需要加锁），更新删除操作本质是标记删除，在段合并的过程中，标记删除的数据并不会写入到新段中，这样就达到了删除的目的。写操作先写Lucene段，再写translog，如果先写translog，写入Lucene段失败，则还需要对translog进行回滚处理。
ES的只读和删除设置，是对索引和磁盘的一种保护机制，当然也可以手动设置索引的只读和删除，以下是ES自动触发的：
索引的别名操作，比如要对一个月的所有索引（每天创建一个索引）进行处理，就可以为索引创建别名，一个索引可以有多个别名，一个别名也可以指向多个索引。
数据库
文章转载自李宇涛L，如果涉嫌侵权，请发送邮件至：[email protected]进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
相关阅读
202
㈧ oracle--对锁机制的理解-
1 引言—数据库锁的基本概念
为了确保并发用户在存取同一数据库对象时的正确性（即无丢失修改、可重复读、不读“脏”数据），数据库中引入了锁机制。基本的锁类型有两种：排它锁（Exclusive locks记为X锁）和共享锁（Share locks记为S锁）。
排它锁：若事务T对数据D加X锁，则其它任何事务都不能再对D加任何类型的锁，直至T释放D上的X锁；一般要求在修改数据前要向该数据加排它锁，所以排它锁又称为写锁。
共享锁：若事务T对数据D加S锁，则其它事务只能对D加S锁，而不能加X锁，直至T释放D上的S锁；一般要求在读取数据前要向该数据加共享锁，所以共享锁又称为读锁。
2 Oracle 多粒度封锁机制介绍
根据保护对象的不同，Oracle数据库锁可以分为以下几大类：
(1) DML lock（data locks，数据锁）：用于保护数据的完整性；
(2) DDL lock（dictionary locks，字典锁）：用于保护数据库对象的结构（例如表、视图、索引的结构定义）；
(3) internal locks 和l a t c h es（内部锁与闩）：保护内部数据库结构；
(4) distributed locks（分布式锁）：用于OPS（并行服务器）中；
(5) PCM locks（并行高速缓存管理锁）：用于OPS（并行服务器）中。
本文主要讨论DML（也可称为data locks，数据锁）锁。从封锁粒度（封锁对象的大小）的角度看，Oracle DML锁共有两个层次，即行级锁和表级锁。
2.1 Oracle的TX锁（行级锁、事务锁）
许多对Oracle不太了解的技术人员可能会以为每一个TX锁代表一条被封锁的数据行，其实不然。TX的本义是Transaction（事务），当一个事务第一次执行数据更改（Insert、Update、Delete）或使用SELECT… FOR UPDATE语句进行查询时，它即获得一个TX（事务）锁，直至该事务结束（执行COMMIT或ROLLBACK操作）时，该锁才被释放。所以，一个TX锁，可以对应多个被该事务锁定的数据行。
在Oracle的每行数据上，都有一个标志位来表示该行数据是否被锁定。Oracle不象其它一些DBMS（数据库管理系统）那样，建立一个链表来维护每一行被加锁的数据，这样就大大减小了行级锁的维护开销，也在很大程度上避免了其它数据库系统使用行级封锁时经常发生的锁数量不够的情况。数据行上的锁标志一旦被置位，就表明该行数据被加X锁，Oracle在数据行上没有S锁。
2.2 TM锁（表级锁）
2.2.1 意向锁的引出
表是由行组成的，当我们向某个表加锁时，一方面需要检查该锁的申请是否与原有的表级锁相容；另一方面，还要检查该锁是否与表中的每一行上的锁相容。比如一个事务要在一个表上加S锁，如果表中的一行已被另外的事务加了X锁，那么该锁的申请也应被阻塞。如果表中的数据很多，逐行检查锁标志的开销将很大，系统的性能将会受到影响。为了解决这个问题，可以在表级引入新的锁类型来表示其所属行的加锁情况，这就引出了“意向锁”的概念。
意向锁的含义是如果对一个结点加意向锁，则说明该结点的下层结点正在被加锁；对任一结点加锁时，必须先对它的上层结点加意向锁。如：对表中的任一行加锁时，必须先对它所在的表加意向锁，然后再对该行加锁。这样一来，事务对表加锁时，就不再需要检查表中每行记录的锁标志位了，系统效率得以大大提高。
2.2.2 意向锁的类型
由两种基本的锁类型（S锁、X锁），可以自然地派生出两种意向锁：
意向共享锁（Intent Share Lock，简称IS锁）：如果要对一个数据库对象加S锁，首先要对其上级结点加IS锁，表示它的后裔结点拟（意向）加S锁；
意向排它锁（Intent Exclusive Lock，简称IX锁）：如果要对一个数据库对象加X锁，首先要对其上级结点加IX锁，表示它的后裔结点拟（意向）加X锁。
另外，基本的锁类型（S、X）与意向锁类型（IS、IX）之间还可以组合出新的锁类型，理论上可以组合出4种，即：S+IS，S+IX，X+IS，X+IX，但稍加分析不难看出，实际上只有S+IX有新的意义，其它三种组合都没有使锁的强度得到提高（即：S+IS=S，X+IS=X，X+IX=X，这里的“=”指锁的强度相同）。所谓锁的强度是指对其它锁的排斥程度。
这样我们又可以引入一种新的锁的类型
共享意向排它锁（Shared Intent Exclusive Lock,简称SIX锁） ：如果对一个数据库对象加SIX锁，表示对它加S锁，再加IX锁，即SIX=S+IX。例如：事务对某个表加SIX锁，则表示该事务要读整个表（所以要对该表加S锁），同时会更新个别行（所以要对该表加IX锁）。
这样数据库对象上所加的锁类型就可能有5种：即S、X、IS、IX、SIX。
具有意向锁的多粒度封锁方法中任意事务T要对一个数据库对象加锁，必须先对它的上层结点加意向锁。申请封锁时应按自上而下的次序进行；释放封锁时则应按自下而上的次序进行；具有意向锁的多粒度封锁方法提高了系统的并发度，减少了加锁和解锁的开销。
㈨ 【ES】ElasticSearch 深入分片
@[toc]
分片是 Elasticsearch 在集群中分发数据的关键。
把分片想象成数据的容器。文档存储在分片中，然后分片分配到集群中的节点上。当集群扩容或缩小，Elasticsearch 将会自动在节点间迁移分片，以使集群保持平衡。
一个分片(shard)是一个最小级别“工作单元(worker unit)”，它只是保存了索引中所有数据的一部分。
这类似于 MySql 的分库分表，只不过 Mysql 分库分表需要借助第三方组件而 ES 内部自身实现了此功能。
分片可以是 主分片(primary shard) 或者是 复制分片(replica shard) 。
在集群中唯一一个空节点上创建一个叫做 blogs 的索引。默认情况下，一个索引被分配 5 个主分片，下面只分配 3 个主分片和一个复制分片（每个主分片都有一个复制分片）：
在一个多分片的索引中写入数据时，通过路由来确定具体写入哪一个分片中，大致路由过程如下：
routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到余数 。这个在 0 到 number_of_primary_shards 之间的余数，就是所寻求的文档所在分片的位置。
这解释了为什么要在创建索引的时候就确定好主分片的数量并且永远不会改变这个数量： 因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了 。
索引中的每个文档属于一个单独的主分片，所以 主分片的数量决定了索引最多能存储多少数据 （实际的数量取决于数据、硬件和应用场景）。
复制分片只是主分片的一个副本，它可以 防止硬件故障导致的数据丢失，同时可以提供读请求，比如搜索或者从别的 shard 取回文档 。
每个主分片都有一个或多个副本分片，当主分片异常时，副本可以提供数据的查询等操作。主分片和对应的副本分片是不会在同一个节点上的，所以副本分片数的最大值是 n -1（其中 n 为节点数）。
当索引创建完成的时候，主分片的数量就固定了，但是复制分片的数量可以随时调整，根据需求扩大或者缩小规模。如把复制分片的数量从原来的 1 增加到 2 ：
分片本身就是一个完整的搜索引擎，它可以使用单一节点的所有资源。 主分片或者复制分片都可以处理读请求——搜索或文档检索，所以数据的冗余越多，能处理的搜索吞吐量就越大。
对文档的新建、索引和删除请求都是写操作，必须在主分片上面完成之后才能被复制到相关的副本分片，ES 为了提高写入的能力这个过程是并发写的，同时为了解决并发写的过程中数据冲突的问题，ES 通过乐观锁的方式控制，每个文档都有一个 _version （版本）号，当文档被修改时版本号递增。一旦所有的副本分片都报告写成功才会向协调节点报告成功，协调节点向客户端报告成功。
ES 集群中每个节点通过路由都知道集群中的文档的存放位置，所以每个节点都有处理读写请求的能力。
在一个写请求被发送到某个节点后，该节点即为协调节点，协调节点会根据路由公式计算出需要写到哪个分片上，再将请求转发到该分片的主分片节点上。假设 shard = hash(routing) % 4 = 0 ，则过程大致如下：
写入磁盘的倒排索引是不可变的，优势主要表现在：
当然，不可变的索引有它的缺点：
在全文检索的早些时候，会为整个文档集合建立一个大索引，并且写入磁盘。只有新的索引准备好了，它就会替代旧的索引，最近的修改才可以被检索。这无疑是低效的。
因为索引的不可变性带来的好处，那如何在保持不可变同时更新倒排索引？
答案是，使用多个索引。 不是重写整个倒排索引，而是增加额外的索引反映最近的变化。 每个倒排索引都可以按顺序查询，从最老的开始，最后把结果聚合。
这就引入了 段 （segment） ：
分片下的索引文件被拆分为多个子文件，每个子文件叫作 段 ， 每一个段本身都是一个倒排索引，并且段具有不变性，一旦索引的数据被写入硬盘，就不可再修改。
段被 写入到磁盘 后会生成一个 提交点 ，提交点是一个用来记录所有提交后段信息的文件。一个段一旦拥有了提交点，就说明这个段只有读的权限，失去了写的权限。相反，当段在内存中时，就只有写的权限，而不具备读数据的权限，意味着不能被检索。
在 Lucene 中的索引（Lucene 索引是 ES 中的分片，ES 中的索引是分片的集合）指的是段的集合，再加上提交点(commit point)，如下图：
在底层采用了分段的存储模式，使它在读写时几乎完全避免了锁的出现，大大提升了读写性能。
索引文件分段存储并且不可修改 ，那么新增、更新和删除如何处理呢？
ES 是怎么做到 近实时 全文搜索？
磁盘是瓶颈。提交一个新的段到磁盘需要 fsync 操作，确保段被物理地写入磁盘，即时电源失效也不会丢失数据。但是 fsync 是昂贵的，严重影响性能，当写数据量大的时候会造成 ES 停顿卡死，查询也无法做到快速响应。
所以 fsync 不能在每个文档被索引的时就触发，需要一种更轻量级的方式使新的文档可以被搜索，这意味移除 fsync 。
为了提升写的性能，ES 没有每新增一条数据就增加一个段到磁盘上，而是采用 延迟写 的策略。
每当有新增的数据时，就将其先写入到内存中，在内存和磁盘之间是文件系统缓存，当达到默认的时间（1秒钟）或者内存的数据达到一定量时，会触发一次刷新（Refresh），将内存中的数据生成到一个新的段上并缓存到文件缓存系统 上，稍后再被刷新到磁盘中并生成提交点 。
这里的内存使用的是ES的JVM内存，而文件缓存系统使用的是操作系统的内存。新的数据会继续的被写入内存，但内存中的数据并不是以段的形式存储的，因此不能提供检索功能。由内存刷新到文件缓存系统的时候会生成了新的段，并将段打开以供搜索使用，而不需要等到被刷新到磁盘。
在 Elasticsearch 中，这种写入和打开一个新段的轻量的过程叫做 refresh （即内存刷新到文件缓存系统）。默认情况下每个分片会每秒自动刷新一次。 这就是为什么说 Elasticsearch 是近实时的搜索了：文档的改动不会立即被搜索，但是会在一秒内可见。
也可以手动触发 refresh。 POST /_refresh 刷新所有索引， POST /index/_refresh 刷新指定的索引：
没用 fsync 同步文件系统缓存到磁盘，不能确保电源失效，甚至正常退出应用后，数据的安全。为了 ES 的可靠性，需要确保变更持久化到磁盘。
虽然通过定时 Refresh 获得近实时的搜索，但是 Refresh 只是将数据挪到文件缓存系统，文件缓存系统也是内存空间，属于操作系统的内存，只要是内存都存在断电或异常情况下丢失数据的危险。
为了避免丢失数据，Elasticsearch添加了 事务日志（Translog） ，事务日志记录了所有还没有持久化到磁盘的数据。
有了事务日志，过程现在如下：
事务日志记录了没有 flush 到硬盘的所有操作。当故障重启后，ES 会用最近一次提交点从硬盘恢复所有已知的段，并且从日志里恢复所有的操作。
在 ES 中，进行一次提交并删除事务日志的操作叫做 flush 。分片每 30 分钟，或事务日志过大会进行一次 flush 操作。 flush API 也可用来进行一次手动 flush ， POST/ _flush 针对所有索引有效， POST /index/_flush 则指定的索引：
通常很少需要手动 flush ，通常自动的就够了。
总体的流程大致如下：
由于自动刷新流程每秒会创建一个新的段 ，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。每一个段都会消耗文件句柄、内存和 cpu 运行周期。更重要的是，每个搜索请求都必须轮流检查每个段然后合并查询结果，所以段越多，搜索也就越慢。
ES 通过后台合并段解决这个问题。小段被合并成大段，再合并成更大的段。这时旧的文档从文件系统删除的时候，旧的段不会再复制到更大的新段中。合并的过程中不会中断索引和搜索。
段合并在进行索引和搜索时会自动进行，合并进程选择一小部分大小相似的段，并且在后台将它们合并到更大的段中，这些段既可以是未提交的也可以是已提交的。
合并结束后老的段会被删除，新的段被 flush 到磁盘，同时写入一个包含新段且排除旧的和较小的段的新提交点，新的段被打开可以用来搜索。
1. 全文搜索引擎Elasticsearch，这篇文章给讲透了
2.ElasticSearch 权威指南》
㈩ 用es文件浏览器加密的文件密码忘了，怎么解锁
用es文件浏览器加密的文件密码忘了，如果忘记密码只能不断进行尝试，找回密码。没有其他的方法能够解锁。
文件加密忘记密码的话，工作人员也没有办法解开。如果可以随意找到密码，这就成了功能漏洞。目前只能不断尝试去解开密码。没有其他的路径来找回密码。
如果更改了编码还是显示乱码，建议在电脑端下载ftp客户端来访问。
注意ES的加密是一次性的，一旦解密后就失效了。选项“下次加密使用这个密码”，是针对同一文件来说的，并且退出软件后就会失效。