Elasticsearch准实时性问题
目录
ES索引的不变性
ES索引结构组成
为什么要进行数据分段（segment）？
ES数据写入流程
ES如何解决宕机数据丢失的问题？
当我们更新数据至 ES 且返回成功提示，在返回后的一瞬间进行查询，会发现数据仍然不是最新的，背后的原因究竟是什么？想要真正搞清楚原因，就要求我们对数据索引的整个过程有所了解。
ES索引的不变性
倒排索引被写入磁盘后是 不可改变 的：它永远不会修改。
不变性有重要的价值：
- 不需要锁。如果你从来不更新索引，你就不需要担心多进程同时修改数据的问题。
- 一旦索引被读入内核的文件系统缓存，便会留在哪里，由于其不变性。只要文件系统缓存中还有足够的空间，那么大部分读请求会直接请求内存，而不会命中磁盘。这提供了很大的性能提升。
- 其它缓存(像filter缓存)，在索引的生命周期内始终有效。它们不需要在每次数据改变时被重建，因为数据不会变化。
- 写入单个大的倒排索引允许数据被压缩，减少磁盘 I/O 和 需要被缓存到内存的索引的使用量。
当然，一个不变的索引也有不好的地方。主要事实是它是不可变的! 你不能修改它。如果你需要让一个新的文档 可被搜索，你需要重建整个索引。这要么对一个索引所能包含的数据量造成了很大的限制，要么对索引可被更新的频率造成了很大的限制。
ES索引结构组成
ES 的一个索引集群可能有多个分片，每个分片又是一个 Lucene Index，每一个 Lucene Index 由多个 Segment 构成（Segment可以理解为是Index的子集），每个 Segment 由多个Document 构成。
为什么要进行数据分段（segment）？
我们知道索引是不可变的，而为了实现数据的更新，需要通过增加新的补充索引来反映新近的修改，而不是直接重写整个倒排索引。
ES数据写入流程
第一步：数据写入memory buffer
Shard 收到写请求时，请求会被写入 Translog（事务日志） 中，然后 Document 被存放到 memory buffer （注意：memory buffer 的数据并不能被搜索到）。
第二步：refresh
每隔 1 秒（默认设置），refresh 操作被执行一次，且 memory buffer 中的数据会被写入一个 Segment 并存放 filesystem cache 中（但还没有提交），这时新的数据就可以被搜索到了。下图中灰色的桶为新写入的 Segment，支持查询，memory buffer 同步完成后被清空，但 Translog不会立刻清空。
第三步：flush
数据最终会从 filesystem cache 提交到硬盘，这个提交过程并且截断 translog 的行为在 Elasticsearch 被称作一次 flush 。 分片默认每30分钟被自动 flush，或者在 translog 太大的时候也会 flush。flush后，段被全量提交，并且 translog 被清空。
总结一下数据写入的过程：
- 所有在内存缓冲区的文档都被写入一个新的段。
- 缓冲区被清空。
- 一个提交点被写入硬盘。
- 文件系统缓存通过
fsync被刷新（flush）。 - 老的 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的朋友可能发现，两者有很多相似之处。
ゝ一世哀愁。
灰太狼
小灰灰
分手后的思念是犯贱
还没有评论，来说两句吧...