各存储系统分片和副本

ES：
构建集群：每个node配置cluster.name和node.name，启动后通过自动发现IP机制加入集群，或者discovery.zen.ping.unicast.hosts在每个node上都指定IP列表
默认，每个node都有三种角色（可成为master节点，是数据节点，是协调节点），通过node.master和node.data可控制
master节点：选举可得，负责创建或删除索引，添加或删除节点等集群范围的变更，不管文档的变更搜索
协调节点：接收客户端请求、转发请求，汇总数据
创建索引：请求由协调节点转发到master节点，master节点分配各主从分片到数据节点中
索引或删除文档：协调节点计算出在文档在哪个shard，根据元数据将请求转发给主分片所在节点，主分片执行且请求分发给各副本分片，主分片收到各副本分片执行成功应答返回给协调节点最终返回客户端
检索文档：协调节点将请求转发给各分片（可主可副）
分片数量不可变（牵扯到路由），副本数可变，主分片挂了，副本分片可成为主分片

ZK：
Leader，Follower，Observer都可接收执行读请求，Leader执行写请求并广播，新加节点先和Leader同步

Mongodb：
1 master-slave：固定的主从，启动时指定–master 和–slave --source 太垃圾已经不用了
2 replica set：选举的primary,secondary，各Server之间不断心跳，某Server挂掉，一直会显示心跳报错直到恢复，primary挂掉某secondary为新primary，客户端可连接到当前primary上进行新增节点，修改数据，连接到secondary最多只有查询功能，如我们使用java驱动，默认会将读写请求给到当前primary，readPreference可修改读请求的处理方式（如发往secondary），secondary轮询primary获取oplog进行本地操作
3 shard：collection数据允许分开存储，客户端只需要连接mongos路由（可指定多个），其余工作由mongos来完成

Redis：
支持分片和主从

Redis主从复制集群: Slave可读但不建议读（若未开启tcp的NO_DELAY会带来脏读，数据有点过期），不用读写分离，全走master即可，内存读写很快的，slave作为高可用，slaveof搭建，slave初始全量复制，后续部分复制，PSYNC
手动故障转移：麻烦，找一个slave变成master(slaveof no one)，其他slave（slaveof ip port），修改各节点redis.conf
自动故障转移（Sentinel）：哨兵对各节点心跳，若超过指定个数哨兵认为某master故障，则由哨兵完成转移

Redis数据分片集群：Slave不可读，默认分片不按照一致性hash（分散性不好可能导致负载不均衡），通过CRC16[key]&16383映射到某个slot，你需要提前将slot和具体shard server的映射关系定义好，redis-cli连接某Server，但是访问的key不在此Server，会返回重定向错误，这样你必须连接到另一Server进行访问，或者redis-cli加-c以集群模式连接可自动重定向，通过cluster-enabled yes和cluster-config-file进行搭建，cluster meet进行握手（即加入集群），cluster addslots分配槽，cluster replicate配主从（分片集群的主从和主从复制集群的主从不一样），某节点的Master和Slave都挂了集群下线，
可用性和同步都是通过PING完成（每个节点都需和其他所有节点进行PING），新节点加入互相PING达到最终一致性，Master投票决定某节点是否故障（需半数认为），某Master挂了Slave顶上，一半的Master同时失效那就无法投票集群不可用

客户端分片如CRedis：由客户端自己定义路由策略决定访问哪台Server

Mysql：无传统意义的分片，DAL分库或分表加上客户端路由来实现分片
分区：就是一张表，只是多个文件来存储单表的数据，还是单点模式
主从（复制）：master的log dump thread发送binlog，slave的io thread 接收binlog写到relay log，slave的sql thread应用relay log的内容，很明显master开启binlog，slave开启relay log，master和slave不同的server-id,master创建含复制权限的用户，slave使用此用户去连接master