Kinto 5.3.4 发布，轻量级 JSON 存储服务

Kinto 是一个轻量级 JSON 存储服务，支持同步和分享功能，很容易使用和自托管。

Kinto 已经在 Mozilla 中使用。

用例

• 前端应用的通用 Web 数据库

• 构建细粒度权限协作应用 

• 在本地存储加密数据

• 在不同设备中同步应用数据

特性

• 同步

• 离线优先 JS 客户端

• 细粒度权限

• 可插入多个客户端

• 开源，可自托管

• 开放设计

Kinto是个提供了同步与分片功能的轻量级JSON存储服务，并且易于使用。它在Mozilla内部得到了广泛的应用，基于Apache v2许可。

基本上，Kinto是个服务，客户端应用可以通过它存储和获取JSON数据。为了对这些数据提供同步与共享特性，Kinto引入了一些基本概念。

• Bucket：可以将bucket看作是命名空间：如果存储在不同的bucket中，那么集合名之间是不会出现冲突的。
• Collection：记录的集合。
• Record：实际存储的数据。
• Group：定义权限的具名principal列表。

Record是数据的最小单元。默认情况下是无模式的，JSON可以包含任何数据。Collection是一组Record。我们以列表的形式操纵Record，可以对其进行过滤和排序。Bucket是个抽象的概念，用于组织集合及其权限。Kinto提供了一个名为default的Bucket，其集合与记录只可由当前用户访问。

Kinto所操纵的每一种对象都共享一些公用的属性：

• 一个唯一标识符
• 一个版本号，有修改时会自增
• 一组权限

这些概念非常类似于磁盘，其中的Bucket就是分区、Collection是目录，而Record则是文件！

Kinto拥有一个用户组的概念。一个组会有一个成员列表，他们属于一个Bucket。权限引用的是组而非单个用户，这使得我们可以轻松定义“角色”，特别是在将同一组权限应用到几个对象的时候。为了控制记录的查看、创建、修改与删除操作，Kinto可以在Bucket、Group、Collection与单个Record上定义权限。既然在Bucket、Collection与Record之间存在着继承的概念，因此Kinto考虑到了从父对象继承权限的问题。比如说，如果一个Bucket定义了一个权限，允许匿名用户读取，那么该Bucket中的每个Collection的每一条Record就都可以读取，这都是继承的结果。创建新对象的权限定义在父对象中。比如说，创建Record的权限定义在Collection中，创建Collection或是Group的权限定义在Bucket中。不过，创建新Bucket的权限则是通过服务器配置来控制的。

Kinto的主要应用场景如下所示：

• 为前端应用提供了通用的Web数据库
• 构建带有细粒度权限控制的协作式应用
• 可存储加密数据
• 在不同设备间同步应用数据

值得一提的是，Kinto目前在Firefox与Firefox OS上得到了广泛的应用，主要用于对设置与各种信息进行全局同步；此外，它还是浏览器扩展与Web应用中个人数据存储的首选解决方案。

Kinto的主要特性如下所示：

• 数据同步
• 细粒度权限控制
• JSON Schema验证
• 通用且多客户端支持
• 开源、自托管
• 良好的设计

Kinto的亮点有：

• 充分利用了HTTP最佳实践
• 可插拔的认证机制
• 可插拔的存储、缓存与权限支持
• 可通过INI文件或是环境变量进行配置
• 内建的监控支持
• 缓存控制

双向的记录同步是个非常困难的事情。Kinto走了一些捷径，它只对并发控制与变更轮询提供了一些基本保障手段，而且不会自动解决冲突问题。基本上，每个对象都有一个版本号，每次修改后该版本号都会增加。Kinto并不会保存对象老的版本号。客户端可以获取到自某个特定的版本号以来记录集合所发生的变更列表，Kinto还可以通过它防止对象的意外更新。Kinto同步功能是由Mozilla Firefox Sync团队进行设计并开发的。

在开始构建自己的数据存储服务前，我们先来看看市场上已经存在的产品。Kinto团队一开始的想法是使用并扩展已有的社区项目，并没有打算重新发明轮子。不过，经过了一些尝试后，团队发现既有的这些解决方案都无法很好地解决团队所面临的问题，比如说细粒度权限控制等。因此，团队基于开发Firefox Sync所积累的经验开始构建自己的数据存储服务。

下表展示了Kinto与市场上同类产品的功能比较，这有助于读者了解Kinto相对于其他竞品来说有哪些优势。

[1] 目前，Hoodie的用户插件会自动让用户认证通过，不过他们正在解决这个问题。

[2] CouchDB将Map/Reduce作为查询机制，这对于新人来说不太好理解。

[3] Remote Storage可以对目录使用“ls”，不过内容项并不是排好序的，也没有分页。

[4] 对于冲突处理来说，Kinto使用了与Remote storage相同的机制。

[5] Remote Storage支持OAuth2.0 Implicit Grant Flow。

[6] 对去中心化的发现支持在计划当中，不过尚未实现。

[7] Remote Storage并未定义任何默认实现（因为它是个协议），不过可以通过JavaScript与Node.js轻松上手。

感兴趣的读者还可以通过这里了解到创建Kinto背后的种种抉择与动机。

下面是关于Kinto的一些FAQ，可以帮助读者更好地了解这款轻量级JSON存储的设计原理与具体使用场景。

Kinto可以对数据进行加密么？

Kinto服务器会将传递过来的任何数据存储起来，无论数据是否加密都如此。我们认为加密应该是客户端做的事情，你可以通过我们提供的Kinto.js客户端轻松实现对数据的加密处理。

对于我所使用的操作系统来说，Kinto是否提供了包下载工具？

没有，不过这个想法很不错。为几个平台维护包是一件非常耗时间的事情，况且我们现在还是个小团队。目前，你可以通过我们提供的Makefile或是Dockerfile轻松运行服务器。可以通过pip轻松安装Kinto，在Docker hub也有镜像。不过，如果你愿意帮助我们在你所喜欢的操作系统上维护Kinto包，那么我们将万分感激！

为何会选择使用Python而不是其他语言？

我们喜欢Python，因为它是门简洁且富于表现力的语言，同时又提供了强大的数据结构，而且易于学习。因此，开发团队选择了使用Python。

此外，Mozilla的运维团队也对在生产环境下部署和管理Python应用驾轻就熟。不过，Python本身只是个实现细节而已。Kinto是由HTTP协议定义的，可以使用任何语言实现。

可否在Kinto中存储文件？

现在还不行，不过我们已经设计了一个文件存储特性，现在正在实现中，预计将于明年发布。与此同时，如果想要尝试最新版，我们很期待你的反馈。

何为Cliquet？Cliquet与Kinto存在哪些差别？

Cliquet是个用于设计微服务的工具集；Kinto则是通过该工具集构建的服务器。

我遇到了Exception错误，哪里出错了呢？

可以通过Troubleshooting了解关于错误的详细信息。

感兴趣的读者可以尝试Kinto，这里是Kinto的文档说明。