公司连个制热空调都不给配，很快就会变成面对辞职报告编程了吧

@Showfom
干货数据库本身确实可能很小。
之前做的一个七百多万用户的项目， MYSQL 文件压缩后也不过 20MB

鼓动开发把所有的低版本测试设备都升级到 9 ，产品就没话说了……

你们的备份呢？
另外，延时删除？多占用的时间付费了么……

logo 嘛 你要猪八戒水准就是 500 左右市场价
我家设计师随便接个私活单 logo 就是五千起步

业务都全球了，直接加钱上 CDN 吧……

出差前去财务写借条借钱……
额度为预算的 70%

看楼主的网络知识，最省事的办法前面接个交换机，然后一个口出来做一个……

给店铺找个接盘侠呗……
这玩意要是能快速卖掉，就算一折，那搞艺术的早都发家致富了

@iceiceberg
看你们的可用性要求了……

反正总不能 cache 挂了就直接把乱七八糟的 error 抛给用户了……
我以前给人做东西时候，各种变态测试就是去把数据库内容删了啊，把 cache 弄坏啊什么的，就算没法正常提供数据，服务也不能崩，好歹给友好的错误提示给用户，有条件保证的数据还是要给出的。


从设计方式角度，首先 cache 里一般有这么几种数据：

后面有 backend 的，为了提升性能，这种 cache 的封装访问，一定是自带 cache 不在了，从 backend 读取重建 cache 。
这种基本逻辑就是，首先去 cache 里面 fetch ，如果 fetch 到 false ，那么去 backend 读，然后写 cache ，如果 cache server 不可用，那么记录 warning 给管理员，然后流程继续。

另外一种，纯热数据，属于可以清空不影响逻辑的，后面没有 backend ，比如一个实时热词排序这种，数据如果清空是不影响前台展示，只能导致具体不准确。这种 cache server 挂掉，基本就等于一个无数据的新系统，应该也不会功能错乱。

一般我都是一次完整查询，结果主键写 cache 里，有效期 7200 ，给个 entry id 。

以前发生过这种事儿……后来都改自建了……
不过应该吐槽一下，你的程序竟然没有 cache server 崩溃的 failsafe 么？哪怕数据库直读呢