k3s之前的multi-master的支持 Mysql, PostgreSql, etcd 这3个方案,现在正在实验一个内嵌的multi-master方案,使用一个sqlite的HA版本-dqlitedqlite-顾名思义,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是这样的:

image

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

使用dqlite,则是这样的

image

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

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

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

image

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

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

image

如果用dqlite变成这样

image

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

image

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

image

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

image

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

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

  • cpu使用率高

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

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

参考:

  1. 作者的演讲

  2. go的binding和demo