Elasticsearch 写原理:
写数据原理: 和其它分布式一样, 先 hash 取余, 先定位数据分片, 请求再写入 trandslog (5s fsync translog) 和内存缓冲区, 内存缓冲区每秒同步到文件缓存, 当文件缓冲区 30 分钟或者 translog 比较大时 (500M), 同步到磁盘.
如果没有协调节点, 那么轮询访问数据节点, 当我们向协调节点发送请求以索引新文档时, 将执行一下操作:
a. 所有在 Elasticsearch 集群中的节点都包含: 有关哪个分片存在于哪个节点上的元数据. 协调节点 (coordinating node) 使用文档ID (默认) 将文档路由到所对应的分片. Elasticsearch 将文档 ID 以 murmur3 作为散列函数进行散列. 并通过索引中的主分片数量进行取模运算, 以确定文档应被索引到哪个分片. 跟 MySQL 分库分表一样, hash 取模
shard = hash (document_id) % (num_of_primary_shards)
b. 当节点接收到来自协调节点的请求时, 请求被写入到 translog, 并将该文档添加到内存缓冲区. 如果请求到主分片上成功, 则请求将并行发送到副本分片. 只有在所有主分片和副本分片上的 translog 被 fsync' ed (未被写入文件系统) 后, 客户端才会收到请求成功的确认.
c. 内存缓冲区以固定的间隔刷新 (默认为 1 秒), 并将内容写入文件系统缓存中的新段. 此分段的内容更尚未被 fsync' ed (未被写入文件系统), 分段是打开的. 内容可用于搜索.
d. translog 被清空, 并且文件系统缓存每隔 30 分钟进行一次 fsync, 或者当 translog 变得太大时进行一次 fsync. 这个过程在 Elasticsearch 被称为 flush. 在刷新过程中, 内存缓冲区被清除, 内容被写入新的文件分段 (segment). 当文件分段被 fsync' ed (未被写入文件系统) 并且刷新到磁盘, 会创建一个新的提交点 (其实就是会更新文件偏移量, 文件系统会自动做这个操作). 旧的 translog 被删除, 一个新的开始.
