Dqlite,基于sqlite 高可用(HA)数据库
k3s之前的multi-master的支持 Mysql, PostgreSql, etcd 这３个方案，现在正在实验一个内嵌的multi-master方案，使用一个sqlite的HA版本-dqlite，dqlite-顾名思义，distibution sqlite,以后稳定的话，可能会成为官方推荐的HA方案。
Dqlite用主要做了几个事情:
提供一个基于raft的解决方案，基于一个叫 c-raft 的 raft轻量级实现,
把sqlite封装起来，给它存储层注册一个定制driver来操作数据
CAP理论里，和绝大多分布式数据库一样，dqlite选择了(CP without A), 就是选择了Consistency（一致性）、Partition tolerance（分区容错性），而不保证 Availability（可用性），也即是:
保证了数据一致性
保持强一致性，用户请求需要在服务器中所有的分区里面完成了一致性才返回
但是，不保证每个请求都能得到没有报错的响应
一般，我们用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这种程序还是有点太重了
参考：