Elasticsearch集群设计技巧
ES的基本架构
1.节点可以配置为不同角色，通过选举Master管理集群。
2.Coordinating：协调节点；Master：管理节点；Data：数据存储节点；
数据是按照索引分片的，而不是按照节点分片，每个分片可以有多个副本来保证高可用，例如图中P0有2个R0副本。
ES的选举
1.先根据节点的 clusterStateVersion 比较，clusterStateVersion 越大，优先级越高。
2.clusterStateVersion 相同时，进入 compareNodes，其内部按照节点的 ID 比较(ID 为节点第一次启动时随机生成)。
ES 的部署架构模式1 – Master 和 Data 混合部署
1. 节点同时配置为 Master 和 Data；
2. 每个节点都可以接收和处理客户端请求，写入操作会转发到数据主分片的 Node；
3. 适用于数据量不大的业务。
ES 的部署架构模式2 – Master 和 Data 分离部署
1. Master 节点和 Data 节点分离配置，Master 节点数量3个或者5个，Data 节点数量可以几十个；
2. Master 节点不处理读写请求，只负责集群管理，Data 节点处理读写请求和数据存储；
3. 适用于数据量比较大的业务。
ES 的部署架构模式3 – Coordinating 分离部署
1. Master 节点数量3个或者5个，Data 节点数量可以几十个，Coordinating(协调) 节点2个以上；
2. Master 节点不处理读写请求，只负责集群管理，Coordinating 负责读写聚合，Data 节点负责数据存储；
3. 适用于数据量比较大，读写请求比较复杂的业务。
Redis Cluster 基本架构
1. Cluster 分为多个分片，不同分片保存不同数据；
2. 每个分片内部通过主备复制来保证可用性；
3. 分片内部自动实现 Master 选举，但不依赖Sentinel，Cluster 本身具备分片选举的能力；
4. 客户端连接集群需要特定的实现，例如jedisCluster，因为 Cluster 有特有的 Redis 命令。
Redis 数据分布和路由
1. 所有 key 按照 Hash 算法分为16384个槽位，然后将槽位分配给分片；
2. 节点之间通过 Gossip 交换信息，节点变化的时候会自动更新集群信息；
3. 每个节点都有所有 key 的分布信息;
4. Client 连接任意节点，由节点用 move 指令来告诉实际的数据位置.
HDFS 架构
【NameNode】
集群管理节点，保存集群元数据，管理集群（平衡、分配等）。
【DataNode】
存储实际的数据，数据按照 block 存储。
【JournalNode】
1. 当 Active NameNode 修改集群状态后，会写日志到 JournalNode 集群里面；
2. StandBy NameNode 会监听 JournalNode，发生变化的时候会拉取日志；
3. JournalNode 至少3个，达到多数日志复制写入才算成功。
【FailoverController】
1. NameNode 节点内的一个独立进程，监控 NameNode 状态；
2. 依赖 ZooKeeper 做高可用。
MongoDB sharding 架构
【mongos】
1. 独立部署的代理程序，应用程序请求发给 mongos；
2. 可以和应用程序部署在一起，也可以和 Shard 服务器部署在一起；
3. 为了提升性能，mongos 会缓存 Config Server 上保存的 cluster
配置信息
【Config Server】
1. 存储集群的元数据；
2. 自身通过 replica set 保证高可用；
3. 当 Config Server 挂掉的时候，cluster 进入 read only。
【Shard】
1. 存储分片数据的服务器；
2. 自身通过 replica set 保证高可用，如果全部挂掉，分片就无访问了。
各个架构的简单分析对比
原文始发于微信公众号（二进制跳动）：分片架构设计技巧
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/166894.html
