bazel远程缓存(Remote Cache)

原理

您可以将服务器设置为构建输出（即这些操作输出）的远程缓存。这些输出由输出文件名列表及其内容的哈希值组成。借助远程缓存，您可以重复使用其他用户的 build 中的构建输出，而不是在本地构建每个新输出。

增量构建极大的提升了本地研发的构建效率，但有些场合它的效果不是很好，例如 CI 环境通常采用“干净”的容器，此时没有上一次的构建数据，只能全量构建。

即使是本地研发，如果从远端同步代码时修改了全局参数，也会导致增量构建失效。

缓存 (Remote Cache) 与远程执行 (Remote Execution) 可以很好的解决这个问题。

前面聊到，Action 满足封闭性，即相同的 Action 信息一定产生相同的结果。因此可以建立 Action 到 ActionResult 的映射。为了便于索引，Bazel 把 Action 信息通过 sha256 哈希算法压缩成摘要 (Digest)，把 Digest 到 ActionResult 的映射存储在云端，就可以实现 Action 的跨构建共享。

Action 共享示意图

这里的 Storage 是完全基于内容寻址的，即“一个 Digest 唯一对应一个 ActionResult”，内容寻址的好处是不容易污染存储空间，因为修改任何一行代码会计算出不同的 Digest，不用担心污染别人的 ActionResult。内容寻址的存储引擎，被称为Content Addressable Storage(CAS)，如果没有特别强调，本文后续使用简称 CAS 来表述。

CAS 里存放的任何文件，无论是 Action 的 Meta 信息还是编译产物二进制，都被称为 Blob。

为保证 CAS 的存储空间被有效利用，通常会使用 LRU 算法管理 CAS 里存储的 Blob，当存储空间写满时，最久没被访问的 Blob 就会被自动淘汰，这样就保证了空间里的 Blob 是最活跃的。

部署

部署&运行

前面讲了Bazel的基本本地使用和原理，但是我们知道，Bazel最重要的是支持缓存和分布式（远程执行），那么这一节主要就是讲如何让bazel使用缓存。

要能够缓存Bazel每个action的输出，我们就要一个server来实现remote cache，用于存储action的输出。这些输出实际上是一堆文件输出对应的hash值。总体来说，我们需要满足三个前提：

• 设置一个server作为cache backend

• 配置Bazel build去使用cache

• Bazel版本要在0.10.0以上

Cache本身会存储两种数据：

• action cache，或者说实际上是一个acton->action result的map映射表

• 一个可寻址(addressable)的输出文件存储系统

https://docs.bazel.build/versions/master/remote-caching.html 中对Bazel Remote Cache的使用和工作有更详细的介绍，就不重复了。这里直接讲到底怎么设置一个Bazel Remote Cache Server. 在上面这个链接中提到了三种方式：

• NGINX的WebDAV模块

• 开源的bazel-remote

• Google Cloud Storage

这里我们直接选择第二种：开源的bazel-remote