Elasticsearch准实时性问题

灰太狼 2023-01-12 12:59 204阅读 0赞

**目录**

ES索引的不变性

ES索引结构组成

为什么要进行数据分段（segment）？

ES数据写入流程

ES如何解决宕机数据丢失的问题？

--------------------

当我们更新数据至 ES 且返回成功提示，在返回后的一瞬间进行查询，会发现数据仍然不是最新的，背后的原因究竟是什么？想要真正搞清楚原因，就要求我们对数据索引的整个过程有所了解。

## ES索引的不变性 ##

倒排索引被写入磁盘后是 *不可改变* 的：它永远不会修改。

不变性有重要的价值：

*  不需要锁。如果你从来不更新索引，你就不需要担心多进程同时修改数据的问题。
 *  一旦索引被读入内核的文件系统缓存，便会留在哪里，由于其不变性。只要文件系统缓存中还有足够的空间，那么大部分读请求会直接请求内存，而不会命中磁盘。这提供了很大的性能提升。
 *  其它缓存(像filter缓存)，在索引的生命周期内始终有效。它们不需要在每次数据改变时被重建，因为数据不会变化。
 *  写入单个大的倒排索引允许数据被压缩，减少磁盘 I/O 和 需要被缓存到内存的索引的使用量。

当然，一个不变的索引也有不好的地方。主要事实是它是不可变的! 你不能修改它。如果你需要让一个新的文档 可被搜索，你需要重建整个索引。这要么对一个索引所能包含的数据量造成了很大的限制，要么对索引可被更新的频率造成了很大的限制。

--------------------

## ES索引结构组成 ##

ES 的一个索引集群可能有多个分片，每个分片又是一个 Lucene Index，每一个 Lucene Index 由多个 Segment 构成（Segment可以理解为是Index的子集），每个 Segment 由多个Document 构成。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTEyMTIzOTQ_size_16_color_FFFFFF_t_70][]

--------------------

## 为什么要进行数据分段（segment）？ ##

我们知道索引是不可变的，而为了实现数据的更新，需要通过增加新的补充索引来反映新近的修改，而不是直接重写整个倒排索引。

--------------------

## ES数据写入流程 ##

**第一步：数据写入memory buffer**

Shard 收到写请求时，请求会被写入 Translog（事务日志） 中，然后 Document 被存放到 memory buffer （注意：memory buffer 的数据并不能被搜索到）。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTEyMTIzOTQ_size_16_color_FFFFFF_t_70 1][]

**第二步：refresh**

每隔 1 秒（默认设置），refresh 操作被执行一次，且 memory buffer 中的数据会被写入一个 Segment 并存放 filesystem cache 中（但还没有提交），这时新的数据就可以被搜索到了。下图中灰色的桶为新写入的 Segment，支持查询，memory buffer 同步完成后被清空，但 Translog不会立刻清空。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTEyMTIzOTQ_size_16_color_FFFFFF_t_70 2][]

**第三步：flush**

数据最终会从 filesystem cache 提交到硬盘，这个提交过程并且截断 translog 的行为在 Elasticsearch 被称作一次 *flush* 。 分片默认每30分钟被自动 flush，或者在 translog 太大的时候也会 flush。flush后，段被全量提交，并且 translog 被清空。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTEyMTIzOTQ_size_16_color_FFFFFF_t_70 3][]

**总结一下数据写入的过程：**

1.  所有在内存缓冲区的文档都被写入一个新的段。
2.  缓冲区被清空。
3.  一个提交点被写入硬盘。
4.  文件系统缓存通过 `fsync` 被刷新（flush）。
5.  老的 translog 被删除。

--------------------

## ES如何解决宕机数据丢失的问题？ ##

前面提到的 Translog 就是为了解决 ES flush 前宕机的问题。

translog 有两种持久化的方式，可以通过更低的代价把数据提前落到磁盘：

*  Index.translog.durability : request，每个请求都会 fsync，不过这样可能会影响 ES 性能。
 *  Index.translog.durability : fsync，每隔 Index.translog.sync\_interval （默认5s）后才会 fsync 一次。

当 Elasticsearch 宕机重启后， 它会从磁盘中使用最后一个提交点去恢复已知的段，并且会重放 translog 中所有在最后一次提交后发生的变更操作。

translog 也被用来提供实时 CRUD 。当你试着通过ID查询、更新、删除一个文档，它会在尝试从相应的段中检索之前， 首先检查 translog 任何最近的变更。这意味着它总是能够实时地获取到文档的最新版本。

熟悉MySQL redo log的朋友可能发现，两者有很多相似之处。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTEyMTIzOTQ_size_16_color_FFFFFF_t_70]: /images/20221119/492b5ef1afac41658d74c90d977ccfbe.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTEyMTIzOTQ_size_16_color_FFFFFF_t_70 1]: /images/20221119/a5fec14d06234f3da34cbf3cfbcffdbd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTEyMTIzOTQ_size_16_color_FFFFFF_t_70 2]: /images/20221119/72374ebd9f5a4435a393f2805a28d707.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTEyMTIzOTQ_size_16_color_FFFFFF_t_70 3]: /images/20221119/e3d29eb0c6e74dd4a2ad822dc7b51988.png