github.com/vicanso/pike@v1.0.1-0.20210630235453-9099e041f6ec/docs/questions.md (about)

     1  ---
     2  description: 对于pike的各类常见疑问
     3  ---
     4  
     5  ## 何时需要配置缓存持久化
     6  
     7  pike主要是用于缓存热点接口（可缓存），设计上保证了当缓存不存在或过期时，相同的请求只能有一个转发至后端。缓存也建议使用短缓存（不超过5分钟，甚至是1分钟以下），短缓存场景下持久化的效果不大，因此期望后端应用是可以支撑正常的请求量或者有熔断机制。
     8  
     9  对于新的实例无缓存时导致后端服务无法支持过大的请求量，可使用缓存持久化。现支持使用badger(文件)或redis的方式实现缓存持久化。若是机器内存不足，配置较小的LRU配合badger的方式以支持更大的接口缓存量，选择redis则可以多实例共享缓存但性能比badger差。而机器内存足够则建议不使用持久化，如果担心pike崩溃重新恢复时，后端服务无法支撑过大的请求量，可以启动多个pike实例，前置通过nginx转发至pike，而nginx的转发策略则使用url_hash，这样就算其中一个pike崩溃也只是部分缓存失效。
    10  
    11  ## 为什么缓存的数据使用单独的压缩配置
    12  
    13  如果数据是可缓存的，会单独使用配置为`bestCompression`的压缩配置（默认的配置为gzip:9, br:6)，虽然可以配置相同的配置覆盖，但不建议调整。由于缓存的数据都会被使用多次(如果缓存基本不会被重复使用，那么pike也无意义了)，因此数据仅压缩一次则被使用多次，而选择更高的压缩级别可减少与客户端的网络（公网）传输耗时，提升用户体验。br的压缩对CPU的占用特别大，而最高的压缩级别11占用了过多的CPU，而减少的数据并不非常明显。
    14  
    15  在实际环境中，由于机器资源可能为实体机等资源，一般CPU、内存等都是冗余的，而带宽则较为方便的动态调节，因此建议根据CPU的使用资源调整不同的压缩级别，以达到资源与性能的平衡（节约带宽也能节约成本）。
    16  
    17  ## 为什么缓存的有效期仅基于`Cache-Control`
    18  
    19  varnish对于接口缓存有效期判断主要基于`Cache-Control`，但它还支持`Expires`以及一些基于状态码(如307, 302响应码，则缓存时间为-1)来生成缓存有效期，此种处理符合RFC的各规范要求。由于规则较多，有不少的开发者并不清楚varnish的缓存有效期是怎么生成的，而且varnish还支持default ttl，更增加了使用风险(缓存了不应该缓存的数据有可能导致泄露客户数据)。
    20  pike的缓存只基于响应的`Cache-Control`，完全由接口开发人员控制缓存的处理，更准确高效（开发人员才清楚接口是否可缓存以及缓存时长），避免了在varnish使用中由开发者要求运维人员针对特别接口配置缓存（varnish也支持通过Cache-Control配置，但实际有不少使用者直接通过不同的url指定不同缓存的方式）。
    21  
    22  ## 管理后台为什么是基于flutter web
    23  
    24  pike的管理后台并没有太复杂的功能，都仅是一些表单的填写，而刚好以前学习了flutter，flutter web则是一种学习尝试，仅此而已。