数据复制模型 CRUD API

读写文档

复制组

  • 每个索引都分为多个分片，每个分片可以有多个副本，这些副本称为复制组，在添加或删除文旦时必须是保持同步的

    复制模型

  • 保持主分片和副本间，两两副本间的数据同步并提供读取服务的过程

  • 基于主备（priamary-backup）模型
  • 我们称主分片为 primary,副本为 replica
  • primary 用作索引所有操作的入口点，它负责验证它们并确保它们是正确的

  • 一旦索引操作被 primary 接受，它将负责将该操作复制到其他 replica（分发请求到其他replica）

    基本写模型

    primary 遵循如下基本流程

  • 验证传入操作，如果结构无效则拒绝该操作。例如：指定mapping模板的数据写入有字段类型不对

  • 在本地执行索引操作，及索引或删除相关文档
  • 将该操作转发到当前复制组，有多个 replica，该操作是并行完成的
  • 所有 replica 都成功执行了操作，并对 primary 做出响应，primary 就确认完成了请求并返回给用户

    由此可知，面对写操作频繁的索引，副本设置为0，后面将只提供查询时可再修改副本数 面对读写操作都频繁的索引你自己就看着办吧

note

写流程错误处理

  • primary 本身故障，master 将会将其中一个副本提升为新的 primary，操作转移到新 primary

  • repica 发生故障，master将会清理该副本，根据不变量并在其它节点构建一个新的副本，并与primary 完成数据同步

    基本读模型

    读取可以是一个非常轻量的按 ID 查找，也可以是一个具有复杂聚合繁重的搜索请求，这些聚合需要非常大的CPU能力。 主备模型的一个优点是他保持所有分片（replica、primary）是等同的，因此单个同步拷贝（相关分片组）就可以满足读取请求

  • 将读取请求解析到相关分片组，

  • 在同步副本组中选择一个相关 shard 的活动分片。可以是 primary 也可以时 replica
  • 向所选分片发送读取请求

  • 将结果整合

    note

    读流程错误处理

  • 当一个分片未能响应读取请求时，协调节点将请求发送到同步副本组的另一个分片。重复失败导致没有可用的分片

    总结

  • 在正常情况下，同一个分片组只需要一个分片完成读取操作，只有在失败情况下才会重复请求分片组其他

  • 由于 primary 首先完成写操作，然后复制分发请求到 replica ,所以在并发都的情况下可能在确认之前就看到了更改
  • 同时只维护的数据的两个分片就可以容错——容错最低要求

索引API