1. 多机优化
2. redis集群
- 2.1. 实现方式
- 2.2. redis的面试为什么快淘汰策略持久策略有什么区别使用场景怎么用
3. es集群

1. 多机优化

1.1. 分表

1.1.1. 垂直分表

1.垂直分表可以理解成按列分表，比如一个用户表中包括了用户登录相关信息，用户基本资料，用户账户信息等等信息，这个表字段太多变得非常庞大，查询的时候必定会有性能影响
2.宽表拆分成小表

1.1.2. 水平分表

数据量太大的表拆分成多张表
水平分表可以理解成按行分表，一个表中的数据量一千万行，查询注定慢，我们可以把这个表中的数据拆分成10个小表，每个表一百万行数据，每个小表拥有相同的列

原则：

id区间（id连续）
时间
业务（地区）

产生分布式id的方式

雪花算法

Snowflake，雪花算法是由Twitter开源的分布式ID生成算法，以划分命名空间的方式将 64-bit位分割成多个部分，每个部分代表不同的含义(1bit，不用，因为二进制中最高位是符号位，1表示负数，0表示正数 41bit位时间戳,10bit位工作机器id，12bit位序列号)

美团leaf

问题：跨表问题使用union解决

union 指令的目的是将两个 SQL 语句的结果合并起来

1.2. 分库

1.2.1. 垂直分库

1.微服务天然垂直分库
2.一个mysql数据处理不了就可以考虑使用多个mysql服务来分担压力，垂直分库就是把一个数据库中的N张表，按照模块/业务划分到多个Mysql数据库，每个数据库都有自己的服务器，进行分布式部署

1.2.2. 水平分库

即使做了水平分表，表太多也会影响数据库的效率，水平分库指定是把一个数据库中的表分到多个数据库中，数据库采用分布式部署，比如电商平台针对于商品库我们可以按照商户来分

1.3. 带来的问题

1.3.1. 分布式事务

多个人数据库实例，采用seata分布式事务

1.3.2. 跨表查询

1.3.3. 跨库查询

商品库和店铺库属于不同的库,想要查询商品库里面的商品信息,通过商品信息里面的店铺id到店铺库里面查询

1.4. 实现方案

1.4.1. shardingjdbc

1.导包
2.配置yml （配置数据源和分片规则）
sharding-jdbc定位为轻量级java框架,使用客户端直连数据库,以jar包的形式提供服务,未使用中间层,无需额外部署,并无其他依赖,,可以理解为增强版的JDBC驱动sharding-jdbc完整的实现了分库分表/读写分离/分布式主键功能,并实现了柔性事务
适用于任何基于Java的ORM框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。基于任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP等。支持任意实现JDBC规范的数据库。目前支持MySQL，Oracle，SQLServer和PostgreSQL。

2. redis集群

2.1. 实现方式

2.1.1. 主从

主从复制是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)，数据的复制是单向的，只能由主节点到从节点。默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点

Redis主从优缺

从是数据的一种备份；防止数据丢失读写分离，分担读的压力主从是哨兵，cluster集群的基石

Redis主从的缺点

不能分担写的压力主挂了集群不可用，没法自动主备切换存储得不到扩容，存储数据总量是主的数据总量

2.1.2. 哨兵

主从模式，当主服务器中断服务后，可以将一个从服务器升级为主服务器，以便继续提供服务，但是这个
过程需要人工手动来操作。为此，Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能

用于管理Redis集群,该系统执行以下三个任务：

1.监控(Monitoring) Sentinel会不断地检查你的主服务器和从服务器是否运作正常;
2.提醒(Notification) 当被监控的某个Redis服务器出现问题时,Sentinel可以通过API向管理员或者其他应用程序发送通知;
3.自动故障迁移(Automatic failover)：当主服务器不可用，Sentinel会自动选举一个从服务器作为新主服务器，并让其它的从服务器从新的主服务器复制数据，用户的请求会被变更为新的主服务器

哨兵的工作机制

主观下线

每个Sentinel（哨兵）进程以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其他Sentinel（哨兵）进程发送一个 PING 命令
如果一个Master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的所有 Sentinel（哨兵）进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态

客观下线

当有足够数量（半数以上）的 Sentinel（哨兵）进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN），则Master主服务器会被标记为客观下线（ODOWN）
若没有足够数量的 Sentinel（哨兵）进程同意 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel（哨兵）进程发送 PING 命令返回有效回复，Master 主服务器的主观下线状态就会被移除。

故障转移

当前哨兵虽然发现了主数据客观下线，需要故障恢复，但故障恢复需要由领头哨兵来完成。
这样来保证同一时间只有一个哨兵来执行故障恢复，选出领头哨兵后，领头哨兵将会开始对主数据库进行故障恢复。
首先是从主服务器的从服务器中选出一个从服务器作为新的主服务器。选出之后通过slaveif no ont将该从服务器升为新主服务器。
所有在线的从数据库中，选择优先级最高的从数据库。优先级通过replica-priority参数设置，优先级相同，
则复制的命令偏移量越大(复制越完整)越优先，如果以上都一样，则选择运行ID较小的从数据库
选出一个从数据库后，领头哨兵将向从数据库发送SLAVEOF NO ONE命令使其升格为主数据库，
而后领头哨兵向其他从数据库发送 SLAVEOF命令来使其成为新主数据库的从数据库，最后一步则是更新内部的记录，将已经停止服务的旧的主数据库更新为新的主数据库的从数据库，使得当其恢复服务时自动以从数据库的身份继续服务

哨兵的优点

1.哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。2.主从可以自动切换，系统更健壮，可用性更高。

哨兵的缺点

1.哨兵依然是主从模式，没法解决写的压力，只能减轻读的压力2.存储得不到扩容，存储数据总量是主的数据总量

当主服务器宕机后，从服务器切换成主服务器的那段时间，服务是不能用的。

2.1.3. cluster

无中心

redis的哨兵模式基本已经可以实现高可用，读写分离，但是在这种模式下每台redis服务器都存储相同的数据，很浪费内存，所以在redis3.0上加入了cluster模式，实现的redis的分布式存储，也就是说每台redis节点上存储不同的内容

什么是Redis-Cluster

Redis-Cluster采用无中心2结构，集群中的每个节点都是平等的关系，都是对等的，每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据

2.2. redis的面试为什么快淘汰策略持久策略有什么区别使用场景怎么用

3. es集群

3.1. 目的

单节点故障
支持高并发
海量数据存储

脑裂问题：脑裂问题的出现就是因为从节点在选择主节点上出现分歧导致一个集群出现多个主节点从而使集群分裂，使得集群处于异常状态

3.2. 核心概念

3.2.1. Cluster集群

包含多个节点，每个节点属于哪个集群是通过一个集群名称（集群名称，默认是elasticsearch）来决定的，对于中小型应用来说，刚开始一个集群就一个节点很正常

3.2.2. Node节点

主节点master

node.master=true,代表该节点有成为主资格，主节点的主要职责是和集群操作相关的内容，如创建或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。一般会把主节点和数据节点分开，node.master=true , node.data=false

数据节点data

node.data=true,数据节点主要是存储索引数据的节点，主要对文档进行增删改查操作，聚合操作等,数据节点对CPU,IO,内存要求较高，优化节点的时候需要做状态监控，资源不够时要做节点扩充。配置：mode.master=false,mode.data=true

负载均衡节点client

当主节点和数据节点配置都设置为false的时候，该节点只能处理路由请求，处理搜索，分发索引操作等，从本质上来说该客户节点表现为智能负载平衡器。配置：mode.master=false,mode.data=false

3.2.3. shard分片

主分片primary shard

单台机器无法存储大量数据，es可以将一个索引中的数据切分为多个shard，分布在多台服务器上存储。有了shard就可以横向扩展，存储更多数据，让搜索和分析等操作分布到多台服务器上去执行，提升吞吐量和性能。每个shard都是一个lucene index

复制分片replica shard

任何一个服务器随时可能故障或宕机，此时shard可能就会丢失，因此可以为每个shard创建多个replica副本。replica可以在shard故障时提供备用服务，保证数据不丢失，多个replica还可以提升搜索操作的吞吐量和性能。primary shard（建立索引时一次设置，不能修改，默认5个），replica shard（随时修改数量，默认1个），默认每个索引10个shard，5个primary shard，5个replica shard，最小的高可用配置，是2台服务器

3.3. 健康状况

Green

所有的primary shard和replica shard 都是active活动状态 - 集群健康

Yellow

所有的primary shard处于active活动状态，有部分的replica shard不处于active状态 - 集群能用

Red

至少有一个primary shard不处于active活动状态就会出现red - 集群不健康

多机优化&redis集群&es集群