【es】Elasticsearch如何保证数据不丢失？

我们大概已经知道了 Elasticsearch处理数据的流程，其中在Elasticsearch和磁盘之间还有一层称为FileSystem Cache的系统缓存，正是由于这层cache的存在才使得es能够拥有更快搜索响应能力。

我们都知道一个index是由若干个segment组成，随着每个segment的不断增长，我们索引一条数据后可能要经过分钟级别的延迟才能被搜索，为什么有种这么大的延迟，这里面的瓶颈点主要在磁盘。

持久化一个segment需要fsync操作用来确保segment能够物理的被写入磁盘以真正的避免数据丢失，但是fsync操作比较耗时，所以它不能在每索引一条数据后就执行一次，如果那样索引和搜索的延迟都会非常之大。

所以这里需要一个更轻量级的处理方式，从而保证搜索的延迟更小。

这就需要用到上面提到的FileSystem Cache，所以在es中新增的document会被收集到indexing buffer区后被重写成一个segment然后直接写入filesystem cache中，这个操作是非常轻量级的，相对耗时较少，之后经过一定的间隔或外部触发后才会被flush到磁盘上，这个操作非常耗时。但只要sengment文件被写入cache后，这个sengment就可以打开和查询，从而确保在短时间内就可以搜到，而不用执行一个full commit也就是fsync操作，这是一个非常轻量级的处理方式而且是可以高频次的被执行，而不会破坏es的性能。

如下图：

image.png
image.png

在elasticsearch里面，这个轻量级的写入和打开一个cache中的segment的操作叫做refresh，默认情况下，es集群中的每个shard会每隔1秒自动refresh一次，这就是我们为什么说es是近实时的搜索引擎而不是实时的，也就是说给索引插入一条数据后，我们需要等待1秒才能被搜到这条数据，这是es对写入和查询一个平衡的设置方式，这样设置既提升了es的索引写入效率同时也使得es能够近实时检索数据。

refresh的用法如下：

image.png

refresh操作相比commit操作是非常轻量级的但是它仍然会耗费一定的性能，所以不建议在每插入一条数据后就执行一次refresh命令，es默认的1秒的延迟对于大多数场景基本都可以接受。

当然并不是所有的业务场景都需要每秒都refresh一次，如果你短时间内要索引大量的数据，为了优化索引的写入速度，我们可以设置更大的refresh间隔，从而提升写入性能，命令如下：

image.png

上面的参数是可以随时动态的设置到一个存在的索引里面，如果我们正在插入超大索引时，我们完全可以先关闭掉这个refresh机制，等写入完毕之后再重新打开，这样以来就能大大提升写入速度。
命令如下：

image.png

注意refresh_interval的参数是可以带时间周期的，如果你只写了个1，那就代表每隔1毫秒刷新一次索引，所以设置这个参数时务必要谨慎。

我们已经知道在elasticsearch中每个shard每隔1秒都会refresh一次，每次refresh都会生成一个新的segment，按照这个速度过不了多久segment的数量就会爆炸，所以存在太多的segment是一个大问题，因为每一个segment都会占用文件句柄，内存资源，cpu资源，更加重要的是每一个搜索请求都必须访问每一个segment，这就意味着存在的segment越多，搜索请求就会变的更慢。

那么elaticsearch是如何解决这个问题呢？
实际上elasticsearch有一个后台进程专门负责segment的合并，它会把小segments合并成更大的segments，然后反复这样。
在合并segments的时候标记删除的document不会被合并到新的更大的segment里面，所有的过程都不需要我们干涉，es会自动在索引和搜索的过程中完成，合并的segment可以是磁盘上已经commit过的索引，也可以在内存中还未commit的segment：

（1）在索引时refresh进程每秒会创建一个新的segment并且打开它使得搜索可见

（2）merge进程会在后台选择一些小体积的segments，然后将其合并成一个更大的segment，这个过程不会打断当前的索引和搜索功能。

image.png

（3）一旦merge完成，旧的segments就会被删除，流程如下：

image.png
image.png

至此原来标记伪删除的document都会被清理掉，如果不加控制，合并一个大的segment会消耗比较多的io和cpu资源，同时也会搜索性能造成影响，所以默认情况下es已经对合并线程做了资源限额以便于它不会搜索性能造成太大影响。

api如下：

image.png

或者不限制：

image.png

es的api也提供了我们外部发送命令来强制合并segment，这个命令就是optimize，它可以强制一个shard合并成指定数量的segment，这个参数是：max_num_segments ，一个索引它的segment数量越少，它的搜索性能就越高，通常会optimize成一个segment。

需要注意的是optimize命令不要用在一个频繁更新的索引上面，针对频繁更新的索引es默认的合并进程就是最优的策略，optimize命令通常用在一个静态索引上，也就是说这份索引没有写入操作只有查询操作的时候是非常适合用optimize来优化的，比如说我们的一些日志索引，基本都是按天，周，或者月来索引的，只要过了今天，这周或这个月就基本没有写入操作了，这个时候我们就可以通过optimize命令，来强制合并每个shard上索引只有一个segment，这样查询性能就能大大提升。

api如下：

image.png

注意，由外部发送的optimize命令是没有限制资源的，也就是你系统有多少IO资源就会使用多少IO资源，这样可能导致某一段时间内搜索没有任何响应，所以如果你计划要optimize一个超大的索引，你应该使用shard allocation功能将这份索引给移动到一个指定的node机器上，以确保合并操作不会影响其他的业务或者es本身的性能。

在elasticsearch和磁盘之间还有一层cache也就是filesystem cache，大部分新增或者修改，删除的数据都在这层cache中，如果没有flush操作，那么就不能100%保证系统的数据不会丢失，比如突然断电或者机器宕机了，但实际情况是es中默认是30分钟才flush一次磁盘，这么长的时间内，如果发生不可控的故障，那么是不是必定会丢失数据呢？

很显然es的设计者早就考虑了这个问题，在两次full commit操作（flush）之间，如果发生故障也不能丢失数据，那么es是如何做到的呢？

在es里面引入了transaction log（简称translog），这个log的作用就是每条数据的任何操作都会被记录到该log中，非常像Hadoop里面的edits log和hbase里面的WAL log，如下图：

image.png

transaction log的工作流程如下：

（1）当一个文档被索引时，它会被添加到内存buffer里面同时也会在translog里面追加

（2）当每个shard每秒执行一次refresh操作完毕后，内存buffer会被清空但translog不会。

过程如下：

image.png

上面过程如下图：

image.png

（3）随着更多的document添加，内存buffer区会不断的refresh，然后clear，但translog数量却越增越多，如下图：

image.png

（4）当达到默认的30分钟时候，translog也会变得非常大，这个时候index要执行一次flush操作，同时会生成一个新的translog文件，并且要执行full commit操作，流程如下：

image.png

如下图：

image.png

tanslog的作用就是给所有还没有flush到硬盘上的数据提供持久化记录。

当es重启时，它首先会根据上一次停止时的commit point文件把所有已知的segments文件给恢复出来，然后再通过translog文件把上一次commit point之后的所有索引变化包括添加，删除，更新等操作给重放出来。

除此之外tanslog文件还用于提供一个近实时的CURD操作，当我们通过id读取、更新或者删除document时，es在从相关的segments里面查询document之前，es会首先从translog里面获取最近的变化，这样就意味着es总是近实时的优先访问最新版本的数据。

我们知道执行flush命令之后，所有系统cache中的数据会被同步到磁盘上并且会删除旧的translog然后生成新的translog，默认情况下es的shard会每隔30分钟自动执行一次flush命令，或者当translog变大超过一定的阈值后。

flush命令的api如下：

image.png

flush命令基本不需要我们手动操作，但当我们要重启节点或者关闭索引时，最好提前执行一下flush命令作为优化，因为es恢复索引或者重新打开索引时，它必须要先把translog里面的所有操作给恢复，所以也就是说translog越小，recovery恢复操作就越快。

我们知道了tangslog的目的是确保操作记录不丢失，那么问题就来了，tangslog有多可靠？

默认情况下，translog会每隔5秒或者在一个写请求（index，delete，update，bulk）完成之后执行一次fsync操作，这个进程会在所有的主shard和副本shard上执行。

这个守护进程的操作在客户端是不会收到200 ok的请求。

在每个请求完成之后执行一次translog的fsync操作还是比较耗时的，虽然数据量可能比并不是很大。

默认的es的translog的配置如下：

image.png

如果在一个大数据量的集群中数据并不是很重要，那么就可以设置成每隔5秒进行异步fsync操作translog，配置如下：

image.png

上面的配置可以在每个index中设置，并且随时都可以动态请求生效，所以如果我们的数据相对来说并不是很重要的时候，我们开启异步刷新translog这个操作，这样性能可能会更好，但坏的情况下可能会丢失5秒之内的数据，所以在设置之前要考虑清楚业务的重要性。

如果不知道怎么用，那么就用es默认的配置就行，在每次请求之后就执行translog的fsycn操作从而避免数据丢失。

参考

为什么说Elasticsearch搜索是近实时的？
https://mp.weixin.qq.com/s/Xqmty7S1heVDkRfrALoxBg

Elasticsearch如何保证数据不丢失？
https://mp.weixin.qq.com/s/zGbuft5vYJAvHGLYv4QR7w

Elasticsearch里面的segment合并
https://mp.weixin.qq.com/s/kzLgAvq2jIZDxLXp-Hk_2A

© 著作权归作者所有,转载或内容合作请联系作者