对于几千万的注册用户,发布的朋友圈的数据是海量的,需要能够搜索,同时也要完成可用性。
对于几千万的注册用户,发布的朋友圈的数据是海量的,需要能够搜索,同时也要完成可用性。第一个要求是大量的朋友圈数据,需要存储到分布式集群中,给出解决方案。另外,在服务器突然宕机的情况,仍然能够保障搜索业务不中断,不少数据。同时要充分利用底层的数据同步原理,提高数据的稳定性。
路由文档到分片
1、文档路由到分片上:一个索引由多个分片构成,当添加(删除、修改)一个文档时,Elasticsearch就需要决定这个文档存储在哪个分片上,这个过程就称为数据路由(routing)。
2、路由算法:
shard = hash(routing) % number_of_primary_shards
示例:一个索引,3个 primary shard
增删改查时主分片与复制分片如何交互
假设有三个节点的集群。它包含一个叫做bblogs的索引并拥有两个主分片。每个主分片有两个复制分片。相同的分片不会放在同一个节点上,所以我们的集群是这样的:
我们能够发送请求给集群中任意一个节点。每个节点都有能力处理任意请求。每个节点都知道任意文档所在的节点,所以也可以将请求转发到需要的节点。下面的例子中,我们将发送所有请求给Node 1,这个节点我们将会称之为请求节点(requesting node)。
新建、 索引与删除一个文档
新建、索引和删除请求都是写(write)操作,它们必须在主分片上成功完成才能复制到相关的复制分片上。
1、客户端发送了一个索引或者删除的请求给node 1。
2、node 1通过请求中文档的 _id 值判断出该文档应该被存储在shard 0 这个分片中(node 1知道shard 0的primary shard位于node 3节点上),node 1会把这个请求转发到node 3。
3、node 3在shard 0 的primary shard上执行请求。如果请求执行成功,它node 3将并行地将该请求发给shard 0的其余所有replica shard上,也就是存在于node 1和node 2中的replica shard。如果所有的replica shard都成功地执行了请求,那么将会向node 3回复一个成功确认,当node 3收到了所有replica shard的确认信息后,则最后向用户返回一个Success的消息。
客户端接收到成功响应的时候,文档的修改已经被应用于主分片和所有的复制分片。此时修改已经生效。
有很多可选的请求参数允许你更改这一过程。你可能想牺牲一些安全来提高性能。这一选项很少使用因为Elasticsearch已经足够快,下面将一一阐述。