原理

您可以将服务器设置为构建输出（即这些操作输出）的远程缓存。这些输出由输出文件名列表及其内容的哈希值组成。借助远程缓存，您可以重复使用其他用户的 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，以便可能的定制及更好理解内部实现。

buchgr/bazel-remote

这里我们不用去重新编译运行，直接下载对应的docker镜像并运行即可

$docker pull buchgr/bazel-remote-cache

bazel-remote支持grpc和http的接口调用，但注意docker内部应用的http接口应该是8080而不是9090（官方文档有误）。

创建一个目录cache, 然后启动docker容器如下

path=`pwd`;docker run -v $path/cache:/data -p 9090:8080 -p 9092:9092 buchgr/bazel-remote-cache

备注：

需要提前创建cache目录或者失败后对目录加777权限，并用-u指定当前用户的uid和gid，否则会报mkdir /data/cas.v2:permission denied。即docker run -u $uid:$gid -v xxx
建议用--max_size限制缓存目录的大小。一般在命令最后加上 --maz_size=50

我们可以看到一堆输出：

2020/10/13 16:12:20 bazel-remote built with go1.14.5 from git commit cc9030667416ab63d89b9fbf543f0243292009b4.
2020/10/13 16:12:20 Initial RLIMIT_NOFILE cur: 1048576 max: 1048576
2020/10/13 16:12:20 Setting RLIMIT_NOFILE cur: 1048576 max: 1048576
2020/10/13 16:12:21 Migrating files (if any) to new directory structure: /data/ac
2020/10/13 16:12:21 Migrating files (if any) to new directory structure: /data/cas
2020/10/13 16:12:21 Loading existing files in /data.
2020/10/13 16:12:23 Sorting cache files by atime.
2020/10/13 16:12:23 Building LRU index.
2020/10/13 16:12:23 Finished loading disk cache files.
2020/10/13 16:12:23 Loaded 0 existing disk cache items.
2020/10/13 16:12:23 Starting HTTP server on address :8080
2020/10/13 16:12:23 HTTP AC validation: enabled
2020/10/13 16:12:23 Starting HTTP server for profiling on address :6060
2020/10/13 16:12:23 Starting gRPC server on address :9092
2020/10/13 16:12:23 gRPC AC dependency checks: enabled
2020/10/13 16:12:23 experimental gRPC remote asset API: disabled

然后可以通过其/status接口来查看是否正常启动

$curl http://localhost:9090/status
{"CurrSize": 0,"MaxSize": 5368709120,"NumFiles": 0,"ServerTime": 1602605641,"GitCommit": "cc9030667416ab63d89b9fbf543f0243292009b4"
}

另外我们也可以查看cache目录下是否生成了对应文件：

这时就可以在运行bazel build的时候指定remote cache server的地址：

$bazel build //src/main:app --remote_cache=http://localhost:9090
INFO: Invocation ID: a9a389d2-1e9f-4878-b65b-586e7b70fa35
INFO: Analyzed target //src/main:app (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //src/main:app up-to-date:bazel-bin/src/main/app_deploy.jarbazel-bin/src/main/app_unsigned.apkbazel-bin/src/main/app.apk
INFO: Elapsed time: 3.271s, Critical Path: 3.02s
INFO: 12 processes: 9 darwin-sandbox, 3 worker.
INFO: Build completed successfully, 13 total actions

备注：

为了避免本地缓存对远程缓存的影响，在执行构建前清理本地缓存。运行以下命令可删除输出文件，并可选择停止服务器。：

bazel clean

检查缓存命中率

在 Bazel 运行的标准输出结果中，查看列出进程的 INFO 行，该进程大致对应于 Bazel 操作。运行操作所在的行详细信息。查找 remote 标签，该标签表示远程执行的操作、linux-sandbox 在本地沙盒内执行的操作，以及用于其他执行策略的其他值。操作来自远程缓存的操作会显示为 remote cache hit。

例如：

INFO: 11 processes: 6 remote cache hit, 3 internal, 2 remote.

在此示例中，有 6 次远程缓存命中，有 2 项操作没有缓存命中，且远程执行了这些命中。这 3 个内部部分可以忽略。它通常是微小的内部操作，例如创建符号链接。此摘要不包含本地缓存命中。如果获得 0 个进程（或低于预期的数字），请运行 bazel clean，后跟构建/测试命令。

在docker一侧，我们可以看到输出

可以看到cache主要是通过http put/get，并使用hash作为key来进行对应结果的查找。

我们重复几次bazel build后可以看到耗时很短，只有不到0.3秒:

INFO: Analyzed target //src/main:app (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //src/main:app up-to-date:bazel-bin/src/main/app_deploy.jarbazel-bin/src/main/app_unsigned.apkbazel-bin/src/main/app.apk
INFO: Elapsed time: 0.286s, Critical Path: 0.03s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action

这显然是cache的作用，我们也可以在BUILD文件中禁止cache。这实际上是对rule的tags设置（我们在以后再讲如何定义rule），我们在这里可以尝试对java_library这个rule添加tag，禁止cache。修改src/main/java/com/example/bazel/util/BUILD中的java_library属性如下：

这样bazel就不会对该BUILD的结果进行缓存，读者可以自行尝试对比，这里就不过多展示实验结果。

排查缓存命中问题

如果您没有获得预期的缓存命中率，请执行以下操作：

确保重新运行相同的构建/测试命令会生成缓存命中

1.运行您希望填充缓存的构建和/或测试。首次在特定堆栈上运行新 build 时，应该不会有任何远程缓存命中。在远程执行过程中，操作结果会存储在缓存中，后续运行结果应该会提取这些结果。

2.运行 bazel clean。此命令会清理您的本地缓存，这样一来，您便可以调查远程缓存命中，而结果不会被本地缓存命中遮盖。

3.（在同一机器上）运行调查的 build 和测试。

4.请查看 INFO 行，了解缓存命中率。如果您看到除 remote cache hit 和 internal 以外的任何进程，则表明您的缓存已正确填充和访问。在这种情况下，请跳到下一部分。

5.可能的差异来源是 build 中非封闭的内容，导致操作在两次运行中接收不同的操作键。如需找到这些操作，请执行以下操作：

a.重新运行相关 build 或测试以获取执行日志：

bazel clean
bazel --optional-flags build //your:target --execution_log_binary_file=/tmp/exec1.log

b. 在两次运行之间比较执行日志。确保两个日志文件中的操作完全相同。通过差异，您可以了解两次运行之间的变化。请更新您的 build 以消除这些差异。

如果您能够解决缓存问题，并且现在重复运行会生成所有缓存命中，请跳到下一部分。

如果您的操作 ID 相同，但没有任何缓存命中，则表示配置中有某项内容阻止了缓存。继续完成此部分，检查是否存在常见问题。

如果您不需要区分执行日志，则可以改用直观易懂的 --execution_log_json_file 标志。它包含执行时间，并且不能保证顺序，因此无法用于稳定差异比较。

6.检查执行日志中的所有操作是否均将 cacheable 设置为 true。如果指定操作的执行日志中未显示 cacheable，则表示相应规则在 BUILD 文件的定义中可能有 no-cache 标记。查看执行日志中直观易懂的 progress_message 字段，以帮助确定操作的来源。

7.如果操作相同且为 cacheable 但没有缓存命中，则您的命令行中可能包含针对 build 停用缓存查询的 --noremote_accept_cached。如果难以确定实际命令行，请使用 Build Event Protocol 中的规范命令行，如下所示： a.将 --build_event_text_file=/tmp/bep.txt 添加到 Bazel 命令中，以获取日志的文本版本。 b. 打开日志的文本版本，然后使用 command_line_label: "canonical" 搜索 structured_command_line 消息。展开之后会列出所有选项。 c.搜索 remote_accept_cached 并检查其是否已设置为 false。 d. 如果 remote_accept_cached 为 false，请确定它位于 false 的位置：在命令行中或在 bazelrc 文件中。

确保可以跨机器进行缓存

在同一台计算机上按预期执行缓存命中后，在其他机器上运行相同的构建/测试。如果您怀疑缓存未在机器间运行，请执行以下操作：

1.对构建稍作修改，以避免命中现有缓存。

2.在第一台机器上运行构建：

bazel clean
bazel ... build ... --execution_log_binary_file=/tmp/exec1.log

3.在第二台机器上运行 build，确保包含第 1 步中所做的修改：

bazel clean
bazel ... build ... --execution_log_binary_file=/tmp/exec1.log

4.比较两次运行的执行日志。如果日志不相同，请调查构建配置是否存在差异，以及主机环境中是否存在泄露到任一 build 中的属性。

比较执行日志

执行日志包含构建期间执行的所有操作的记录。每个操作都有一个 SpawnExec 元素，其中包含操作键中的所有信息。因此，如果日志相同，则操作缓存键也相同。

如需比较两个未按预期共享缓存命中的构建的日志，请执行以下操作：

1.从每个 build 中获取执行日志，并将其存储为 /tmp/exec1.log 和 /tmp/exec2.log。

2. 下载 Bazel 源代码，然后使用以下命令导航到 Bazel 文件夹。您需要使用源代码来使用 execlog 解析器解析执行日志。

git clone https://github.com/bazelbuild/bazel.git
cd bazel

3.使用执行日志解析器将日志转换为文本。以下调用还会对第二个日志中的操作进行排序，以匹配第一个日志中的操作顺序，以方便比较。

bazel build src/tools/execlog:parser
bazel-bin/src/tools/execlog/parser \--log_path=/tmp/exec1.log \--log_path=/tmp/exec2.log \--output_path=/tmp/exec1.log.txt \--output_path=/tmp/exec2.log.txt

4.使用您最喜欢的文本，差异为 /tmp/exec1.log.txt 和 /tmp/exec2.log.txt。

实际上，remote caching只是最基本的一个结果缓存机制，部署和使用都很简单，这里也只是对此进行快捷说明。小团队完全可以用这种方式来部分提升效率。而远程执行(Remote Execution)往往集成了缓存功能，因此在实际大型团队部署中一般不会专门对Remote Cache创建server。我们在下一节来介绍Remote Execution.

本文属于如下文章中的子章节

bazel学习系列章节汇总_m0_74043383的博客-CSDN博客