Dqlite,基于sqlite 高可用(HA)数据库

k3s之前的multi-master的支持 Mysql, PostgreSql, etcd 这３个方案，现在正在实验一个内嵌的multi-master方案，使用一个sqlite的HA版本-dqlite，dqlite-顾名思义，distibution sqlite,以后稳定的话，可能会成为官方推荐的HA方案。

Dqlite用主要做了几个事情:

1. 提供一个基于raft的解决方案，基于一个叫 c-raft 的 raft轻量级实现,

2. 把sqlite封装起来，给它存储层注册一个定制driver来操作数据

3. CAP理论里，和绝大多分布式数据库一样，dqlite选择了(CP without A),　就是选择了Consistency（一致性）、Partition tolerance（分区容错性），而不保证 Availability（可用性），也即是:

4. 保证了数据一致性

5. 保持强一致性，用户请求需要在服务器中所有的分区里面完成了一致性才返回

6. 但是，不保证每个请求都能得到没有报错的响应

一般，我们用sqlite是这样的：

应用程序直接调用一个单节点的sqlite实例

使用dqlite,则是这样的

应用程序不直接操作sqlite的接口，调用的是dqlite提供的接口，dqlite通过c-raft来保证数据一致性和容错行

目前官方提供了一个go的binding, 可以直接在go里使用dqlite的接口

作者有一个demo的演讲，演示了一个go写的分布式氧饱和度检测仪的例子

这段代码很简单，模拟插入氧饱和度的数据，然后提供一个http接口查询平均饱和度返回给调用者

其中getDatabase方法，如果用单实例的sqlite，它是这样的:

如果用dqlite变成这样

startEngine实际上是调用dqlite的接口创建一个新的dqlite节点

然后调用dqlite client这个接口连到集群

往sqlite的存储层注入一个dqlite定制的driver

可以看到，用go来使用这HA方案，还是挺方便易用。

目前k3s的dqlite HA版本目前还是实验状态，不要在生产环境使用，还有一些问题，比如:

• cpu使用率高

• 第一个启动的节点如果崩溃了，leader选举不出来

总的来讲，这个k3s的嵌入式HA方案还是非常值得期待，毕竟在IOT这种蝇级设备里面包mysql或者etcd这种程序还是有点太重了

参考：

1. 作者的演讲

2. go的binding和demo