SequoiaDB简介和初识

为什么需要一个分布式的数据库
因为需求的增加和对吞吐量的需求增加，所以发生了下述的转型
主要核心：每一组微服务都是一个可以弹性扩展的框架。
这种每组微服务都有一个数据库作为数据支撑，这样有一个缺陷：比如这组有20个微服务，但是数据库只要一个的话，这样会成为微服务扩张的瓶颈（弹性扩张）。第二个缺陷：从原来的一个数据库拆散到几十个数据库，那么如果进行跨库的分析就会对DBA和分析人员是一个巨大的挑战（数据碎片化）。

解决方法（1）：还是存放在一个大的集中式的关系型数据库里面

优点：方便开发人员理解
缺点：没法解决弹性扩张

解决方法（2）：每个微服务下面独立使用一个数据库

优点：如果添加微服务的话数据库也会相应添加
缺点：自身MySQL出现容量上限的问题

解决方法（3）：微服务都是面向数据库实例，数据是均匀的分布在很多很多的数据集群里面

（我自己的理解：就像是JVM，不同的实例那么就会有不同的映射方式，那么就可以解决了数据碎片化的问题）

需要什么样的分布式数据库呢？

现在流行的分布式交易性数据库技术的发展体系：
应用垂直分库：将一个大的应用切成一个个的小的服务，每个服务使用一个小的数据库。这样对整个集群的拓扑进行调整的时候，会对应用程序进行较大的修改。

分库分表：用应用到数据库有一个中间件，这个中间件的作用就是来解析所有用户发送的SQL请求，把其解析成底层数据库认识的格式，然后直接下发到数据库（标准的关系型数据库），这样应用的中间件对上层做不到完全透明（比如存储过程等），对弹性扩张的需求存在问题，碎片化管理也存在问题。
那么巨杉是如何做到计算存储分离的？

数据节点：存放用户数据的
编目节点：保存整个集群的数据信息
分布式事务的执行是由协调节点发起一个事务，然后由编目节点进行一个全局事务管理。

支持多种数据库实例：


关键特性：
数据分片能力：首先会把MySQL实例下发到协调节点，在协调节点中使用分布式Hash算法，根据每条记录的分区键进行散列，然后就计算除到底放在哪个分区，所以每个分区数据是完全隔离的
如果是主节点发生故障，那么就会快速的从从节点中选举出一个新的主节点来承担都需的任务。
如何发现主节点发生故障：主节点2轮接受不到超过半数节点心跳会自动降备，备节点2轮接受不到主节点心跳会发起选举投票
如何选举主节点：超过半数节点同意后从节点当选新的主节点（这个可能和网络状况和数据的更新度来判断）。