JAVA面试大纲

Eden（默认8/10）

Survivor0（默认1/10）

Survivor1（默认1/10）

PERSISTENT（持久化目录节点）

PERSISTENT_SEQUENTIAL（持久化顺序编号目录节点）

EPHEMERAL（临时目录节点）

EPHEMERAL_SEQUENTIAL（临时顺序编号目录节点）

Container节点

TTL 节点

Leader

Follower

Observer

选举相关的概念

集群初始化启动时 Leader 选举

集群运行期间 Leader 重新选

分布式配置中心

分布式注册中心

分布式互斥锁

分布式共享锁

分布式队列

集群选举

负载均衡

消息广播

崩溃恢复

数据同步

String 字符串

Hash 哈希

List 列表

Set 集合

ZSet 有序集合

RDB（Redis DataBase）

AOF（Append Only File）

过期策略

淘汰策略

主从架构

哨兵架构

集群架构

为什么要用缓存？
-- 高性能（通过复杂耗时计算的结果，如果访问多，变动小，可以放缓存）
-- 高并发（内存天然支持高并发）
用了缓存之后会有什么不良后果？
-- 缓存雪崩、缓存穿透、缓存击穿、缓存与数据库双写不一致

Redis为什么会这么快？
1、纯内存中操作
2、单线程（避免创建销毁线程的开销、避免上下文切换、避免多线程的资源竞争引发的锁问题）
3、IO多路复用
注意：
-- 根据官方的数据，Redis 的 QPS 可以达到 10 万左右（每秒请求数）。
-- cpu并不会成为redis的瓶颈，redis的瓶颈最有可能是机器内存及网络带宽。

如何保证缓存与数据库双写时的数据一致性？
-- 先更新数据库，再删除缓存，再配合删除缓存重试机制（mq或者binlog）(可能短暂时间数据不一致)
1、先更新数据库，再更新缓存（多写高并发时，无法保证顺序，存在数据库缓存数据不一致的情况；存在浪费性能的情况）
2、先删除缓存，再更新数据库（读写高并发时，存在数据库缓存数据不一致的情况）
3、先删除缓存，再更新数据库，最后延时删除缓存（存在延长时间不好确认的情况）

什么是缓存穿透？
-- 单一热点key，缓存、数据库均不存在
解决方案是什么？
-- 缓存空对象并设置过期时间（缺点是浪费内存存储空对象，且会导致数据库与缓存数据不一致）
-- 布隆过滤器（缺点是没法删除元素，会影响其它key）
注：布隆过滤器判断不存在即一定不存在，但判断存在，不一定代表存在

什么是缓存击穿？
-- 单一热点key，缓存数据失效
解决方案是什么？
-- 设置key永不过期
-- 使用分布式锁
查询key失效时，对这个key进行加锁，只允许其中一个查询拿到锁直接查询数据库（其它的自旋等待），
等结果查询出来，存储到缓存，就释放锁，其它查询就可以直接从缓存获取了

什么是缓存雪崩？
-- 大量热点key，缓存数据同时失效
解决方案是什么？
-- 设置key永不过期
-- 将key的过期时间打乱
-- 在redis前面添加一个本地缓存
-- 限流组件，限制每秒请求数，未通过的请求走降级
-- 高可用集群

延时双删策略

删除缓存重试机制

读取biglog异步删除缓存

Ngnix缓存

本地缓存

Redis缓存

Broker
Kafka集群包含一个或多个服务器，这种服务器被称为broker。broker端不维护数据的消费状态，提升了性能。直接使用磁盘进行存储，线性读写，速度快：避免了数据在JVM内存和系统内存之间的复制，减少耗性能的创建对象和垃圾回收

Producer
消息生产者，负责发布消息到Kafka broker

Consumer
消息消费者，向Kafka broker读取消息的客户端，consumer从broker拉取(pull)数据并进行处理

Topic
每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic，属于逻辑上的概念

Partition
Parition是物理上的概念，每个Topic包含一个或多个Partition

Consumer Group
每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）

消息分发策略？
1、指定具体partition
2、没有指定partition但有key的情况下，将key的hash值与topic的partition数进行取余得到partition
3、没有指定partition且无key的情况下，会随机选择一个分区并一直使用，直到设定的时间到期后（metadata.max.age.ms，默认10分钟），
会重新随机另外一个分区

重要参数

消息发送方式

数据的传递性语义

消费者消费原理？
1、一个partition里面的消息，只能被同一consumer group中的某一个consumer来消费
2、想要多个consumer来消费同一个partition，那这多个consumer必须要在不同的consumer group中
3、如果consumer多于partition，则多出的consumer处于空闲浪费状态

消费者分区分配策略？
1、Range（范围）默认：分区数/消费者数，多的按顺序分摊到前面几个消费者上面
2、RoundRobin（轮询）：轮询分区策略是把所有partition和所有consumer线程都列出来，然后按照hashcode进行排序。
最后通过轮询算法分配partition给消费线程。
3、Stricky（粘性）：它主要有两个目的（分区的分配尽可能的均匀分区的分配，尽可能和上次分配保持相同），初始采用轮询，后面变化。

consumer和partition的数量建议？
1、最好partition和consumer数量一致，或者partition是consumer的整数倍
2、consumer大于partition，会导致consumer浪费
3、consumer远小于partition，会导致吞吐量降低
consumer从多个partition读取数据，不保证数据间的顺序性，kafka只保证在一个partition
上数据是有序的

什么是rebalance机制？什么时候会触发该机制？
Rebalance 本质上是一种协议，规定了一个 Consumer Group 下的所有 consumer 如何达成一致，来分配订阅 Topic 的每个分区。
1、同一个consumer group内新增了消费者
2、消费者离开当前所属的consumer group，比如主动停机或者宕机
3、topic新增了分区（也就是分区数量发生了变化）

什么是coordinator？coordinator又是如何协调consumer group消费的（rebalance过程）？
coordinator是用来统筹管理consumer group消费的
1、确定coordinator：broker集群会将集群中负载最小的broker定为coordinator
2、获取coordinator：consumer会向集群中任意一个broker发送一个GroupCoordinatorRequest来获取coordinator
3、确定consumer leader：所有的consumer向coordinator发送joinGroup请求，coordinator会从中挑选一个来担任
consumer leader角色（如果没有leader，那么第一个请求的就是Leader；如果leader退出了消费组，则随机选举一个）
4、确定分区分配策略：每个consumer都可以有自己的分区分配策略，在上述joinGroup的过程中，consumer也会将自己的分区分配策略
发给coordinator，由coordinator组成一个侯选集，然后每个consumer都从中选举一个自己支持的策略并投票，最终票数多的为最终策略
5、确定消费partition方案：leader选举出来后，会根据最终策略，产生一个消费partition的方案，然后向coordinator发送一个
SyncGroupRequest请求，将方案同步给coordinator
6、同步方案给消费者：coordinator拿到方案后，将方案同步给其它consumer，除非发生rebalance，否则consumer只会消费对应的Partition

Rebalance期间，整个消费组无法消费消息

概念

Controller选举
优先到zookeeper上面创建/controller临时节点的broker为Controller

Partition副本Leader选举
Controller会从ISR列表（参数unclean.leader.election.enable=false的前提下）里挑第一个broker作为Leader（第一个broker最先放进ISR列表，可能是同步数据最多的副本），如果参数unclean.leader.election.enable=true，代表在ISR列表里所有副本都挂了的时候可以在ISR列表以外的副本中选Leader

Kafka数据同步方式？
Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制，而是半同步复制。
Kafka使用这种ISR的方式有效的权衡了数据可靠性和性能之间的关系

Kafka如何保存消费端的消费位置？
Kafka是通过offset来保存消费者的位置的。在kafka中，提供了一个consumer_offsets_* 的一个topic，把offset信息写入到这个topic中。
offset不跨分区，只保证同一分区的offset的顺序性

Kafka为什么速度这么快？
1、利用 Partition实现数据分区存储，提高并发处理效率
2、利用页缓存技术，提高IO效率
3、顺序写，在刷盘时，将数据追加到文件的末尾，性能不比写内存差多少
4、零拷贝（读）：减少了从os cache拷贝到应用缓存和从应用缓存拷贝到socket缓存。
Socket缓存中仅仅会拷贝一个描述符过去，不会拷贝数据到Socket缓存
5、消息批量发送，提高吞吐量
6、数据压缩：Kafka还支持对消息集合进行压缩，Producer可以通过GZIP、Snappy、LZ4格式对消息集合进行压缩

操作系统本身有一层缓存，叫做page cache，是在内存里的缓存，我们也可以称之为os cache，意思就是操作系统自己管理的缓存。

Kafka如何快速读取指定offset的消息？
1、Partition的数据是分段（Segment）存储的，每个分段都包含log、index、timeindex三个文件。
2、首先通过offset根据二分法定位到index稀疏索引文件
3、然后根据索引文件中的[offset,position]（position为物理偏移地址）去log中获取指定offset的message数据。

Kafka如何保证消息不丢失？
1、设置 ack=-1，保证ISR所有副本全部写日志成功才返回；producer.type=sync，设置成同步模式
2、设置 replication.factor>=3，并且 min.insync.replicas>=2，保证ISR中副本集至少大于等于2
3、设置 unclean.leader.election.enable=false，关闭跟不上Leader的follower副本的选举
4、设置 enable.auto.commit=false，消费者改为手动提交
第1点是生产端，第2、3点是服务端，第4点为消费端
-- min.insync.replicas：ISR里面的最小副本数
-- replication.factor：这个参数用来表示分区的副本数

Kafka 是怎么去实现负载均衡的？
1、生产者：消息分发策略（具体见上面描述）
2、消费者：分区分配策略（具体见上面描述）

为什么Kafka不支持读写分离？
1、读写分离（主写从读）会存在数据一致性和延时问题
2、Kafka本身采取了分区的策略，天然提高了并发效率，不需要进一步采用读写分离来提升效率

Kafka 分区数可以增加或减少吗？为什么？
1、支持分区增加，增加后会重新rebalance就好了
2、不支持分区减少，因为会丢失上面的消息

Kafka消息是采用Pull模式，还是Push模式？
1、Push：当消息生产速率远大于消费速率，消费者容易崩溃
2、Pull：可以根据自己的消费能力拉取数据，但是如果没有消息时，会不断轮询，可以在消费端设置轮询间隔

Kafka的分区数是不是越多越好？ -- 不是
1、生产者缓存占用内存会更多（一个分区会有一个batch.size的开销）
2、消费者线程数也会更多（一个分区需要一个线程来处理）
3、服务端的很多组件都在内存中维护了分区级别的缓存，比如controller，FetcherManager等，因此分区数越多，这种缓存的成本就越大
4、文件句柄的开销会更多（.index和.log文件数量会更多）

谈谈你对Kafka生产者幂等性的了解？
Kafka精确一次性（Exactly-once）保障之一
为了实现Producer的幂等性，Kafka引入了Producer ID（即PID）和Sequence Number。

• PID。每个新的Producer在初始化的时候会被分配一个唯一的PID，这个PID对用户是不可见的。
• Sequence Numbler。对于每个PID，该Producer发送数据的每个都对应一个从0开始单调递增的Sequence Number
• Broker端在缓存中保存了这seq number，对于接收的每条消息，如果其序号比Broker缓存中序号大于1则接受它，
  否则将其丢弃，这样就可以实现了消息重复提交了。但是只能保证单个Producer对于同一个的Exactly Once语义

Kafka如何保证消息的有序性？
单分区可以保证有序性，多分区不可以
1、将max.in.flight.requests.per.connection设置为1，消息队列中只允许有一个请求，
这样消息失败后，可以第一时间发送，不会产生乱序，但是会降低网络吞吐量。
2、开启生产者幂等性设置（Exactly-once）

Kafka缺点？

1. 由于是批量发送，数据并非真正的实时；
2. 对于mqtt协议不支持；
3. 不支持物联网传感数据直接接入；
4. 仅支持同一分区内消息有序，无法实现全局消息有序；
5. 监控不完善，需要安装插件；
6. 依赖zookeeper进行元数据管理；3.0版本去除

Broker
-- RocketMQ集群包含一个或者多个服务器，这种服务器被称为Broker。Broker的作用是存储和转发消息， 单机大约能承受 10 万 QPS 的请求。
-- RocketMQ集群的Broker节点都保存总数据的一部分，可以实现横向扩展。为了提升可靠性（防止数据丢失），每个 Broker 可以有自己的副本（slave）
-- 默认情况下，读写都发生在 master上。在slaveReadEnable=true 的情况下，slave 也可以参与读负载。但是只有 Brokerld=1的 slave 才会参与读负载
注：Broker 会向所有的Name Server注册

Master
-- 主节点，通过配置来设置，一经设置，不会改变，即Master挂了后，从节点不会选举变成主节点
注：4.5以后，基于dledger技术可以进行选举，推举一个slave成master。

Slave
-- 从节点，用于数据的备份，通过配置来设置，一经设置，不会改变，即Master挂了后，从节点不会选举变成主节点

Producer
-- Producer 跟 Name Server 的任意一个节点（随机）建立长连接，定期从 Name Server 拉取 Topic 路由信息
-- 根据Topic路由信息与指定的 Broker 建立 TCP长连接
-- 发送逻辑一致的Producer 可以组成一个 Group
-- RocketMQ的生产者同样支持批量发送，不过 List要自己传进去
-- Producer写数据只能操作 master 节点

Consumer
-- Consumer 跟 Name Server 的任意一个节点（随机）建立长连接，定期从 Name Server 拉取 Topic 路由信息
-- 根据Topic路由信息与指定的 Master和Slave 建立 TCP长连接
-- 消费逻辑一致的 Consumer可以组成一个Group
-- 在slaveReadEnable=true 的情况下，slave 也可以参与读负载

NameServer
-- NameServer 可以理解为是RocketMQ的路由中心
-- Producer 和 Consumer都是通过NameServer拿到Topic的相关信息的
-- NameServer之间不做数据通信，每一个NameServer 节点都保存着全量的路由信息

Topic
Topic用于将消息按主题做划分，在 RocketMQ中，Topic是一个逻辑概念，消息不是按 Topic 划分存储的

Message Queue
类似于Kafka里面的Partition分片的概念，topic的数据是分片存储的

发送方式

消息的存储结构是怎么样的？
-- CommitLog：存储消息的元数据。所有消息都会顺序存入到CommitLog文件当中。CommitLog
由多个文件组成，每个文件固定大小1G。以第一条消息的偏移量为文件名。
-- ConsumerQueue：存储消息在CommitLog的索引。一个MessageQueue一个文件，记录当前
MessageQueue被哪些消费者组消费到了哪一条CommitLog。
-- IndexFile：为了消息查询提供了一种通过key或时间区间来查询消息的方法，这种通过IndexFile来
查找消息的方法不影响发送与消费消息的主流程

刷盘机制是怎么样的？
-- 同步刷盘，消息写入内存的PAGECACHE后，立刻通知刷盘线程刷盘， 然后等待刷盘完成，
刷盘线程执行完成后唤醒等待的线程，返回消息写成功的状态
-- 异步刷盘，消息可能只是被写入了内存的PAGECACHE就返回消息成功了，何时刷盘由操作系统自己决定
注：配置方式，Broker配置文件里的flushDiskType（SYNC_FLUSH、ASYNC_FLUSH）

消息主从复制是怎么样的？
-- 同步复制，Master和Slave都写入消息成功后才反馈给客户端写入成功的状态
-- 异步复制，异步复制是只要master写入消息成功，就反馈给客户端写入成功的状态。然后再异步的将消息复制给
Slave节点。
注：配置方式，Broker配置文件里的brokerRole（ASYNC_MASTER、 SYNC_MASTER、SLAVE）

消息模式

消费形式

NameServer 作为路由中心到底怎么工作的呢？
-- 每个Broker节点在启动时，都会根据配置的NameServer列表，与每个NameServer建立TCP长连接，并注册自己的信息
-- 每个Broker（包含master和slave）每隔30s发送心跳信息，表示自己正常存活
-- 每个NameServer每隔10s检查一下各个Broker 的最近一次心跳时间，如果发现某个Broker超过120s都没发送心跳，
就认为这个Broker 已经挂掉了，会将其从路由信息里移除。

NameServer 之间是互相不通信的，也没有主从之分，它们是怎么保持一致性的？
-- 服务注册，每个Broker都会向所有NameServer进行注册，并且每隔30s发送心跳
-- 服务剔除，Broker正常关闭（连接断开），Netty的通道关闭监听器会监听到连接断开事件；
Broker异常关闭，NameServer每隔10s检查，某个Broker120s都没有发送心跳，则可以剔除
-- 路由发现，生产者在发送第一条消息的时候，根据Topic从NameServer 获取路由信息，
消费者一般是订阅固定的Topic，在启动的时候就要获取 Broker 信息
注：
-- NameServer 不会主动推送服务信息给客户端（指生产端和消费端），
-- 客户端也不会发送心跳到Nameserver
-- 客户端会每隔30s到NameServer拉取最新信息，缓存在本地
-- NameServer 是AP，只保证最终一致性，Zookeeper是CP

如果作为路由中心的 NameServer 全部挂掉了，而且暂时没有恢复呢？
-- 客户端会缓存路由信息在本地，不完全依赖于 NameServer

如果 Broker 刚挂，怎么处理数据？
-- 重试
-- 把无法连接的 Broker 隔离掉，不再连接
-- 优先选择延迟小的节点，就能避免连接到容易挂的 Broker 了

RocketMQ磁盘保存文件慢吗？
-- 顺序写，保证了消息存储的速度。高性能磁盘顺序写速度可以达到600MB/s
-- 零拷贝，减少了2次数据在内存中的复制（内核空间到用户空间及用户空间到内核socket）
-- 页缓存，利用页缓存技术，提高IO效率
注：
-- RocketMQ采用的是mmap技术，Kafka采用的是sendfile技术
-- 关于零拷贝，JAVA的NIO中提供了两种实现方式，mmap和sendfile，其中mmap适合比较小的文
件（1.5~2G），而sendfile适合传递比较大的文件

RocketMQ延时消息是怎么实现的？
1、producer 要将一个延迟消息发送到某个 Topic 中
2、Broker 判断这是一个延迟消息后，将其通过临时存储进行暂存
3、Broker 内部通过一个延迟服务（delay service）检查消息是否到期，将到期的消息投递到目标 Topic 中
4、消费者消费目标 topic 中的延迟投递的消息
注：
对外非商业的版本，延时设置有18个级别：1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h

RocketMQ事务消息实现原理？即怎么保证数据一致性？
注：half消息对消费者是不可见的

RocketMQ如何保证消息不丢失？
1、同步发送+重试机制，尽可能减小消息丢失的可能性（或者回答生产者使用事务消息机制？）
2、Broker配置同步刷盘+Dledger主从架构 + 多个master节点
3、消费者不要使用异步消费 + 消费消息重试机制

RocketMQ如何保证消息顺序消费？
1、发送端：同步发送（保证消息发送顺序） + 自定义投放策略（保证消息存储在同一个MessageQueue）
2、消费端：使用有序消费模式MessageListenerOrderly，MessageListenerOrderly是通过加分布式锁和本地锁
保证同时只有一条线程去消费一个队列上的数据。

index（索引）
es 中存储数据的基本单位是索引，类似于表

document（文档）
document就相当于表中的一条记录

field（列）
field相当于表中的字段

mapping（映射）
相当于表结构

shard（分片）
类似于kafka中的partition分片，一般来说，shard最好在一个机房

replica（副本）
类似于kafka中的follow副本

primary（主副本）
类似于kafka中的leader副本

node（节点）
类似于kafka中的节点服务器broke

master
类似于kafka中的controller，选举出来的，master选举采用Raft算法

IK分词器

HanL分词器

AP架构（默认）
1、集群节点之间的数据同步是异步同步的
2、服务列表信息不会持久化到本地，只会存在内存中
临时节点

CP架构
1、利用raft协议保证集群节点间的数据一致性及节点之间的选举
2、数据会持久化到本地，可以防止数据丢失
非临时节点

固定窗口算法

滑动窗口算法

漏桶算法

令牌桶算法

二叉数

红黑树

B树

B+树

hash表

表锁（MYISAM与INNODB支持）
表锁开销小，加锁快，无死锁，锁定粒度大，发生锁冲突的概率最高，并发最低

行锁（InnoDB默认）
行锁开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高
-- InnoDB是基于索引来完成行锁
-- 索引未生效或查询条件没有建立索引，会导致行锁变表锁

页锁（BDB支持）
开销和加锁时间界于表锁和行锁之间：会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般

Record Lock（记录锁）
锁住一条索引记录
例：10，20

Gap Lock（间隙锁） -- 解决当前读的幻读问题
注：只发生在事务隔离级别为RR(Repeatable Read)的情况下，所以RC才会有幻读的问题
不包含索引本身的开区间范围 (index1,index2)
例：(negative infinity, 10)，(10, 20)，(20, positive infinity)

Next-key Lock（临键锁）-- 解决当前读的幻读问题
InnoDB默认，Record Lock + Gap Lock
注：只发生在事务隔离级别为RR(Repeatable Read)的情况下，所以RC才会有幻读的问题
左开右闭 ，除了最后一个锁区间，是全开区间
例：(negative infinity, 10]，(10, 20]，(20, positive infinity)

读锁（共享锁，Share Lock）
若事务T对数据对象A加上读锁，则事务T只能读A；其他事务只能再对A加读锁，而不能加写锁，直到事务T释放A上的读锁

写锁（排它锁，Exclusive Lock）
若事务T对数据对象A加上写锁，则只允许事务T读取和修改A，其它任何事务都不能再对A加任何类型的锁，直到T释放A上的锁

悲观锁
-- 一种用来解决 读-写冲突 和 写-写冲突 的加锁并发控制（利用数据库锁机制）
-- 可以解决脏读，幻读，不可重复读，更新丢失的问题

乐观锁
-- 是一种用来解决 写-写冲突 的无锁并发控制
-- 方式一：使用数据版本（version）实现
-- 方式二：使用时间戳（timestamp）实现
-- 无法解决脏读，幻读，不可重复读，但是可以解决更新丢失问题

MVCC（多版本并发控制）
-- 是一种主要解决 读-写冲突 的无锁并发控制
-- 可以解决脏读，幻读（RR级别），不可重复读等事务问题，但不可以解决更新丢失问题

3个隐式字段（DB_ROW_ID，DB_TRX_ID，DB_ROLL_PTR）

undo日志版本链

Read View（一致性视图）

读取未提交（READ-UNCOMMITTED）
含义：允许读取尚未提交的数据变更
与锁关系：读取数据不需要加共享锁，这样就不会跟被修改的数据上的排他锁冲突
问题：脏读、幻读或不可重复读

读取已提交（READ-COMMITTED）
含义：允许读取并发事务已经提交的数据
与锁关系：读操作需要加共享锁，但是在语句执行完以后释放共享锁
问题：幻读或不可重复读

可重复读（REPEATABLE-READ）
含义：对同⼀字段的多次读取结果都是⼀致的，除⾮数据是被本身事务⾃⼰所修改
与锁关系：读操作需要加共享锁，但是在事务提交之前并不释放共享锁，也就是必须等待事务执行完毕以后才释放共享锁。
问题：幻读
InnDB默认隔离级别，通过MVCC来实现可重复读，
在RR级别下，通过MVCC解决快照读的幻读问题，通过临间锁解决当前读的幻读问题

可串⾏化（SERIALIZABLE）
含义：所有的事务依次逐个执⾏，这样事务之间就完全不可能产⽣⼲扰
与锁关系：该级别锁定整个范围的键，并一直持有锁，直到事务完成
问题：性能差

脏读（DirtyReads）

更新丢失（LostUpdate）或脏写

不可重复读（Unrepeatableread）

幻读（Phantom read）

sharding-jdbc
优点：这种client 层方案的优点在于不用部署，运维成本低，不需要代理层的二次转发请求，性能很高
缺点：如果遇到升级啥的需要各个系统都重新升级版本再发布，各个系统都需要耦合sharding-jdbc 的依赖
中小公司使用

mycat
优点：这种proxy 层方案的优点在于对于各个项目是透明的，如果遇到升级之类的都是自己中间件那里搞就行了
缺点：需要部署，自己运维一套中间件，运维成本高
大公司使用

垂直拆分
把一个有很多字段的表给拆分成多个表，或者是多个库上去。一般来说，访问频率高的字段放一张表，访问频率低的字段放一张表

水平拆分
把一个表的数据给弄到多个库的多个表里去，但是每个库的表结构都一样，只不过每个库表放的数据是不同的，所有库表的数据加起来就是全部数据

水平拆分 -- range
一种是按照range 来分，就是每个库一段连续的数据，这个一般是按比如时间范围来的。
优点：扩容时很简单，因为你只要预备好，给每个月都准备一个库就可以了，到了一个新的月份的时候，自然而然，就会写新的库了。
缺点：很容易产生热点问题，因为大部分的请求，都是访问最新的数据

水平拆分 -- hash
按照某个字段hash 一下均匀分散，这个较为常用。
优点：可以平均分配每个库的数据量和请求压力
缺点：扩容起来比较麻烦，会有一个数据迁移的过程，之前的数据需要重新计算hash 值重新分配到不同的库或表

停机迁移方案

双写迁移方案
1、所有写表的地方，老库和新库（通过中间件）都写
2、同步历史数据，但是不允许覆盖新库的数据，除非旧库的数据比新库更新
3、将程序切换成分库分表的最新代码即可

利用单台数据库自增主键
可适用：并发不高，数据量大
不适用：并发高，数据量大

利用Redis生成ID
-- 使用Redis集群（如5台），每台步长一样，使用原子操作INCR来增加
优点：性能高，单机顺序递增
缺点：不能再扩展，但5台已经够使用了

Twitter的snowflake算法
生成一个64位的long型的ID
-- 1 bit 恒为0，保证生成的ID为正整数
-- 41 bit 作为日期毫秒数 - 41位的长度可以使用69年
-- 10 bit 作为机器编号 （5个bit是数据中心，5个bit的机器ID） - 10位的长度最多支持部署1024个节点
-- 12 bit 作为毫秒内序列号。12位的计数顺序号支持每个节点每毫秒产生4096个ID序号
优点：分布式，性能高，单机递增
缺点：分布式环境，可能由于服务器时间不一致，导致生成的ID不是全局递增；时钟回拨，就是服务器上的时间突然倒退回之前的时间
注：时钟回拨解决方案
1、回拨时间小的时候，不生成 ID，循环等待到时间点到达
2、可以提前在机器ID或者序列号中留出拓展位置0，当出现时钟回拨时，将拓展位置1，这样也可以保证生成ID的唯一性。