1. 停下来
这不意味着我不再学习研究RadonDB了，相反，我是很喜欢这样一个基于MySQL的分布式数据库的。
我的意思是写了那么多源码分析难免会让自己陷入一个又一个的坑里，最后变成了“不识庐山真面目，只缘身在此山中”，一叶障目，毕竟难见泰山。
2. RadonDB的一些原理
这里的图我都是盗来的，来自吴炳锡老师的主页。
整体结构
从整体结构上来看，我最近分析的部分囿于最上面的Distributed SQL Nodes，其实就是模仿的mysqld。
分库规则
其实想做分布式数据库，一定要实现Raft协议，这已经是一个共识了。那么如何去实现Raft呢？其实无非是数据多副本，每个副本分散在一个节点上，当分片集群中有一个节点挂掉，Raft会自动进行选主操作，保证了服务的可用性，同时也保证了数据不丢失。
咱们分开来说，假定现在只有三台MySQL去Raft集群，应该如何？其实我们这个时候可以参考MongoDB的副本集结构。一份数据，三个节点同时持有，就有了三个副本——当然MongoDB有一个不持有数据的仲裁节点——这三个节点组成了一个Raft Group。
现在搞得复杂一点，参考一下MongoDB的Sharding Cluster，此时集群里有了大于等于两个副本集，也就是说数据可以开始分片了。那么这个时候每个副本集持有的数据就是原来数据/n了。其实此时的Raft还是每个副本集自己玩自己的，只是持有的数据量降低了。
RadonDB是怎么做的，当我新建一张表，并指定分片算法是hash的时候，RadonDB会把我的表分成4096个slots，然后分片去均分这4096个slots。
看看代码：
// HashRange tuple.
// [Start, End)
type HashRange struct {
Start int
End int
}
根据这段代码是可以知道slot的切分规则的，就是按照片键增序分开的，左闭右开区间。
4096在代码中的config.go中有写明，是一个default值，但是图中的子表配置成32我还没发现在哪里。
看到这里我们就可以知道了下面几点：
- 每一个副本集都用Raft协议来实现高可用，高可靠；
- 指定了片键的表会被默认分为4096个slots，均匀的分布在每个分片上；
- 一个分片持有若干个slot，slot的开始和结束区间是连续的，没有空洞。
这个时候也不难理解insert_plan中的range是为什么了：
tuple := xcontext.QueryTuple{
Query: buf.String(),
Backend: v.backend,
Range: v.rangi,
}
3. 小结
我写的这一系列我相信很不完美，也应该有不少错误，不过我想我每隔一段时间停下来回头看看，站在另外的角度上看看，应该会受益良多。
其实我还是想说那句话，学而不思则罔。
网友评论