[TOC]

如何保证数据写入过程中不丢

数据写入申请达到时，以须要的数据格式组织并写入磁盘的过程叫做数据提交，对应es就是创立倒排索引，保护segment文件
如果咱们同步的形式，来解决上述过程，那么零碎的吞吐量将很低
如果咱们以异步的形式，先写入内存，而后再异步提交到磁盘，则有可能因为机器故障而而失落还未写入到磁盘中的数据

为了解决这个问题，个别的存储系统都会设计transag log (事务日志)或这write ahead log(预写式日志)。它的作用时，将最近的写入数据或操作以日志的模式间接落盘，从而使得即使零碎解体后，仍然能够基于这些磁盘日志进行数据恢复。

Mysql有redo undo log ，而HBASE、LevelDB，RockDB等采纳的LSM tree则提供了write ahead log 这样的设计，来保证数据的不失落

间接落盘的 translog 为什么不怕升高写入吞吐量？

上述阐述中，数据以同步形式落盘会有性能问题，为什么将translog和wal间接落盘不影响性能？起因如下：

  • 写的日志不须要保护简单的数据结构，它仅用于记录还未真正提交的业务数据。所以体量小
  • 并且以程序形式写盘，速度快

es默认是每个申请都会同步落盘translog ，即配置index.translog.durability 为request。当然对于一些能够丢数据的场景，咱们能够将index.translog.durability配置为async 来晋升写入translog的性能，该配置会异步写入translog到磁盘。具体多长时间写一次磁盘，则通过index.translog.sync_interval来管制

后面说了，为了保障translog足够小，所以translog不能有限扩张，须要在一定量后，将其对应的实在业务数据以其最终数据结构(es是倒排索引)提交到磁盘，这个动作称为flush ，它会理论的对底层Lucene 进行一次commit。咱们能够通过index.translog.flush_threshold_size 来配置translog多大时，触发一次flush。每一次flush后，原translog将被删除，从新创立一个新的translog

elasticsearch自身也提供了flush api来触发上述commit动作，但无非凡需要，尽量不要手动触发

如何保障已写数据在集群中不丢

对每个shard采纳正本机制。保障写入每个shard的数据不丢

in-memory buffer

前述translog只是保证数据不丢，为了其记录的高效性，其自身并不保护简单的数据结构。 理论的业务数据的会先写入到in-memory buffer中，当调用refresh后，该buffer中的数据会被清空，转而reopen一个segment,使得其数据对查问可见。但这个segment自身也还是在内存中，如果零碎宕机，数据仍然会失落。须要通过translog进行复原

其实这跟lsm tree十分类似，新写入内存的业务数据寄存在内存的MemTable（对应es的in-memory buffer），它对应热数据的写入，当达到一定量并保护好数据结构后，将其转成内存中的ImmutableMemTable(对应es的内存segment)，它变得可查问。

总结

  • refresh 用于将写入内存in-memory buffer数据，转为查问可见的segment
  • 每次一次写入除了写入内存外in-memory buffer，还会默认的落盘translog
  • translog 达到一定量后，触发in-memory buffer落盘，并清空本人，这个动作叫做flush
  • 如遇以后写入的shard宕机，则能够通过磁盘中的translog进行数据恢复

LSM Tree的具体介绍

https://www.cnblogs.com/nices...

参考资料

https://ezlippi.com/blog/2018...
https://stackoverflow.com/que...
https://qbox.io/blog/refresh-...
https://www.elastic.co/guide/...
https://www.elastic.co/guide/...

欢送关注我的集体公众号"东南偏北UP"，记录代码人生，行业思考，科技评论