NOTE
5.2 分布式系统分区之请求处理
路由组件把客户端的读写请求,路由到相应partition所在的node 1. 路由组件 路由组件 2. 请求处理 2.1. 新增数据 1. 客户端生成包含sharding key的数据 2. 客户端把新增请求发送给路由组件 3. 路由组件根据sharding key转发到相应的节点 4. 节点新增数
这是历史学习笔记,可能存在过时或不完整的理解。
路由组件把客户端的读写请求,路由到相应partition所在的node
1. 路由组件
2. 请求处理
2.1. 新增数据
- 客户端生成包含sharding key的数据
- 客户端把新增请求发送给路由组件
- 路由组件根据sharding key转发到相应的节点
- 节点新增数据
2.2. 删除数据
2.2.1. 包含sharding key
- 客户端根据sharding key删除数据
- 客户端把删除请求发送给路由组件
- 路由组件根据sharding key转发到相应的节点
- 节点删除数据
2.2.2. 不包含sharding key
- 客户端根据关键词删除数据
- 客户端把删除请求发送给路由组件
- 路由组件把请求转发到所有节点
- 各个节点删除数据
2.3. 查找数据
2.3.1. 包含sharding key
- 客户端根据sharding key查询数据
- 客户端把查询请求发送给路由组件
- 路由组件根据sharding key转发到相应的节点
- 节点查询数据
2.3.2. 不包含sharding key
- 客户端根据关键词查询数据
- 客户端把查询请求发送给路由组件
- 路由组件把请求转发到所有节点
- 各个节点查询数据
2.4. 修改数据
2.4.1. 包含sharding key
- 客户端根据sharding key修改数据
- 客户端把修改请求发送给路由组件
- 路由组件根据sharding key转发到相应的节点
- 节点修改数据
2.4.2. 不包含sharding key
- 客户端根据关键词修改数据
- 客户端把修改请求发送给路由组件
- 路由组件把请求转发到所有节点
- 节点修改数据
2.4.3. 举例
- MySQL的CRUD可以包含sharding key,也可以不包含sharding key
- Redis的CRUD包含sharding key
- Kafka的CRU包含sharding key,没有D
- Zookeeper没有使用分区
- Elasticsearch的CRUD可以包含sharding key,也可以不包含sharding key
3. 二级索引
- 数据分区不是按照二级索引拆分
- 但通过二级索引访问数据的时候,该读写请求发送给哪个分区是个问题
3.1. 本地索引(document based)
- 每个分区只维护当前分区的索引,存储在本地
- 缺点
- 读写请求路由的时候使用scatter/gather的方式
- 优点
- 写入速度快
3.2. 全局索引(term based)
- 所有分区的的索引维护在一起,同时对这个索引进行分区
- 缺点
- 写入速度慢
- 优点
- 读写请求路由的时候使用term路由到正确的分区(类似于主键索引)
3.3. 举例
- MySQL的二级索引使用本地索引
- Redis没有二级索引
- Kafka的的二级索引使用本地索引
- Zookeeper没有二级索引
- Elasticsearch的二级索引使用本地索引