一、分布式数据库的核心功能
1、分布式存储
数据的存储不再受单机存储的制约，可以通过服务器的数量增加存储量
2、计算存储分离
数据量多了，对应的算例也多了，如果每一台分布式存储里面都有一个计算节点，那么就会造成浪费。存储和计算的需求对系统的要求可能是不同的。用计算存储相分离，当我们需要提高算力的时候增加计算几点，当我 们需要增加存储量的时候增加存储节点，而计算节点是无状态的。
3、分布式事务
因为我们把数据库通过分布式的形式分开了之后，事务就是一个很麻烦的事情。所以做一个高性能的、完全支持ACID原义的分布式事务引擎
4、弹性伸缩
可以随时随地动态地对数据节点进行扩容和缩容
5、多数据副本
自动将数据以强一致、高性能的方式复制至跨机多副本
6、HTAP
当我们先将数据以行存、列存的方式进行存储的时候，我们完全可以通过同样的一条sql去访问OLTP事务型和OLAP分析型查询。实现方案
- newsql(进取型)
国内的tidb。以更高的性能换取稳定性的缺失和运维经验的不足。newsql是属于重新设计的数据库的存储结构。需要经过时间的积累去验证。 - 中间件(稳定型)
牺牲部分性能以保证稳定性和运维经验的复用。存储仍然用的mysql或oracle，添加了中间件性能一定会有所下降，因为中间肯定会做一些事情。
newSQL的分类
- 新架构
- 透明化分片中间件
- 云数据库
二、实现与规划(4.x)
ShardingSphere由两个组件构成：Sharding-JDBC和Sharding-Proxy
-
Sharding-JDBC是和业务的应用端部署在一起的
-
Sharding-Proxy是一个独立的进程，是中心化的应用，是无状态的，跨语言的。dba可以把它当数据库去用。一般在管理端用。
-
注册中心里面包含了相关配置，所以proxy和jdbc是共享的。
1、数据分片
2、分布式事务
事务分为两种类型：
-
强一致性事务：XA，谷歌的BigTable论文：Percolator等两阶段方式的分布式事务(刚性事务)。
最大的问题就是：并发性能急剧下降，可用性急剧下降，提交阶段失败阶段 -
柔性事务：base，一阶段事务。强调最终一致性，不要求强一致性
问题：一致性和隔离性，业务侵入。
sharding-sphere提供了一个很好的事务管理:sharding-transaction
参考： blog.csdn.net/ShardingSph…
分布式事务解决方案： JDTX
MVCC引擎：JDTX的核心，基于内存的，比数据库要快。MVCC只会存当前事务的热数据 WAL模块：当事务已经进入了WAL模块之后，事务已经算是结束了，不用真正落到数据库去
JDTX设计亮点:
参考： wenku.baidu.com/view/218d5d…
JDTX自研了一个MVCC的引擎，不管是mysql还是其他，都是用的mvcc去做的事务的隔离级别。
事务有两种实现方式：
一种是多版本快照(MVCC)
另一种就是加锁
mysql是加锁+MVCC
3、弹性伸缩
分为两部分：
迁移引擎:把它当成了mysql的从库，迁移的时候有全量数据的迁移和增量数据的迁移，全量数据有一个历史数据迁移作业，它会把当前这一个位点的所有数据通过分布式调度迁移到新的库去，我们的业务数据还是写到旧库中去。通过订阅binlog的当时去把binlog伪装成一个mysql的从 库，通过ShardingScaling迁移到新库去。把应用切到新的数据库的访问去。调度引擎(用了elasticJob)
