Bazel Remote Cache 缓存问题
简介
公司 iOS 项目使用 bazel 使用编译，同时 bazel 支持远程缓存。 使用远程缓存，可以加速编译速度，节省编译时间。
缓存服务器很简单，支持 GET、 PUT 操作，分别为获取和上传，官网有说明 Bazel Remote Cache。
build --remote_cache=http://mycache.com
但是在 CI 服务器上，偶尔会出现连接出现异常问题，如连接重置、断开、超时、dns无法解析等。大概有5%的概率。分析 bazel 源码，发现 bazel 底层使用 netty 进行http通信。远程服务器日志也没有发现问题。
和常规解决思路不一样，bazel 运行的时候无法进行抓包，因为是概率性的，并且 CI 机器有多台，无法统一进行排查。
解决
从错误信息来看，可能是因为 CPU 使用率过高，导致影响网络请求，出现连接超时、断开、重置、dns无法解析等。
调优连接
# 降低连接数，默认为100
--remote_max_connections=10
# 增加超时时长，默认为60s
--remote_timeout=100s
调优CPU
# 降低CPU与线程数
--loading_phase_threads=HOST_CPUS*.9
使用本地缓存降低请求量
bazel 自己是支持本地缓存的，并且同时支持本地和远程。但是不够智能，不能及时清理老的缓存文件，同时本地和远程是串行的。如上传，先写本地，再上传。还是无法降低网络请求的数量。
可参考官方源码 DiskAndRemoteCacheClient.java
结合微服务中的 SideCar 和 cdn 思路，可以在本地启动一个缓存服务。
上传的时候，直接先把缓存放在磁盘中，同时再异步上传到远程，同时控制异步上传的数据量，类似有个MQ进行异步处理，进行消峰操作。
下载的时候，如果本地有缓存，则直接返回。如果没有则先下载，再进行返回。控制下载线程数，合理规避超时与异常情况。
同时 bazel 有同一个时刻多次请求相同的缓存资源的情况，使用本地缓存，可以避免这样的问题。
build --remote_cache=http://127.0.0.1:8080/
总结
通过以上三种方式，暂时有效的解决编译时候出现 netty 异常问题。
第三种方式，使用本地缓存进行代理中间也是踩过许多坑。
第一次使用Spring Boot 启动一个服务，然后再使用 okhttp 进行远程服务的下载与上传，确实可以降低异常出现的概率，但是不够完美。
第二次换成了Spring Cloud Gateway，想采用nginx的那种方式，不过因为 Gateway 使用的是完全异步的方式，进行缓存本地化的时候有点吃力，可能是自己学艺不精。
第三次又回退到第一次的方式，并进行了一些列的优化，但是还是有小范围的概率。因为 Spring Boot 是基于 java 的，整个服务自己消耗有点高。
第四次，参照第三次的逻辑，使用go语言重新写了一遍，本地缓存服务自己消耗的资源确实有很大程度降低，JAVA 版本最高的时候，自己需要占2G内存，使用go版本最高时候只要100M，差距很明显。
第五次，按理说第四次方案已经很完美，但是还是有小概率的出现，通过查找资料。bazel 自己是支持代理的，但是不是普通的http与socks5 代理，是 unix domain socket。
结合第四种，把go的http版本改成 go的 unix domain socket的即可，修改成本比较低。已上线使用，目前效果良好
# 走自己的代理，代理会进行磁盘缓存。
build --remote_proxy=unix:/tmp/bazel-car-go-unix.socket
以上就是自己排查 bazel 打包问题的历程。经历3个月，收获颇多，尤其是go语言在网络方面的使用，设计真的是太好了。
