先不说成本问题，主要是自己维护太麻烦了。我之前做了两地三中心，来备份自己的数据，每隔几个月，都有突然断网与断电的问题。后来加了 UPS ，写了一堆自动化脚本，来处理这种问题，情况好一些。但是家宽的带宽问题一直是个难题。每次备份前都要先计算

但是，由于我追求性价比，买的是二手服务器，几乎每隔半年，都要去处理各种服务器蓝屏死机的问题，比如内存条 memtest 、磁盘表面测试、全量数据的可用性检测（ HASH 检测）、增量同步甚至全量同步的麻烦事情。由于家宽带宽小，全量同步非常费时，一次需要至少半个月。

后来别人送了我一台联想工作站笔记本，64GB 内存，11 代 i7 。然后我直接摆烂，之前的系统全扔了，重新搞。我在这台笔记本上面，安装 Win11 + VMwareWorkstationPro ，然后买了 2 台 ORICO 5 盘位 USB 磁盘柜，里面有好几块 12TB 二手日立机械盘。VMware Workstation 上安装 Debian 12 + OpenZFS ，OpenZFS 管理磁盘柜，做了 RAID Z1 + 1 块热备盘，没用 SSD 做缓存，关闭了 OpenZFS 的实时去重与压缩功能。

OpenZFS 服务器的 Samba 接受家里的电脑备份，OpenZFS 的 SSH 的 SFTP 接受公司电脑的备份。公网安全是用 IP 白名单，IPTABLES 对公司的 IPv4 的 C 段做了白名单 + fail2ban ，公网不用 Samba 改用 SSH 保护的 SFTP 。

自动化备份，Windows 用最强大的企业级备份软件，SyncBack Pro ，百度上有学习版。Linux 上是自己用 Python 写脚本，来操控 rsync 进行备份，加入了备份前的日志写入，备份过程中的速度与进度汇报，备份前后的 HASH 检查等等。Windows 上的 SFTP 客户端用的是开源的 WinFSP + SSHFS-Win + SSHFS-Win-Manager ，这套开源软件经常失效，每隔十几天就要重启一下 Windows ，不过 Windows 上面的软件更新与 Update 大概也是这个时间，所以我也没觉得麻烦。这整套功能简单的摆烂系统，居然一直稳定运行了好几年。

小主机 128GB 内存，是小众需求，商家生产成本高，生产出来购买的人少，当然就价格贵，导致性价比低。你喜欢小众产品，必然要给溢价买单。

如果想选择性价比，只能选最主流的产品，目前这个阶段是 8GB - 16 GB ，完全不满足你的需求。

如果又要 128GB ，又要性价比，可以放弃小主机这个品类，选 x79 或 x99 ，DDR3 或 DDR4 的 128GB 整机就很便宜了。

实施这种政策，主要原因是，因为大家没有休息时间，卷起来，导致大家没时间谈恋爱，生小孩。我国很多政策是依赖人口数量的，后一代人交钱养前一代人。一旦人口数量突然剧减，政策就会崩，影响执政党的稳定。而且人口少了，很多人口密集型的工作就没人做了，这是发展中国家在前中期的产业支柱。

目前只是倡导政策，找地方试水。后期会直接在体制内推，最终会向全国强制落实，体制内只会与落实了这种制度的公司合作。

突然发现，楼上居然有人拿此事讨论体制的，真搞笑。难道你就只对上级客气说话，对同级与下级就颐指气使？

可能是被家庭宠溺惯坏了，没被社会教育过。

真大佬，就算个人实力与家庭背景再强，对待下等人，也会客客气气的，很尊重对方。更何况你这交流对象还是自己的上级。

你问题的根源在于，要学会尊重人，即使你认为对方很傻。另外交流沟通，也要学一学基本的技巧。

搬瓦工 3 月份出品的，美国加利福尼亚机房，CN2 线路，1C/1GB RAM/20GB Disk/1Gbps 带宽/1TB 流量/年付 34.5 美元，稳得一批。周末晚上高峰期都不丢包，带宽也没波动。老牌厂家确实牛批，比 AWS 好。AWS 新加坡与日本，每天晚上高峰期，丢包率直逼 50%，带宽几十 kb/s ，根本用不了。

@chengyiqun 因为单体架构省钱。开发、调试、部署，都非常方便高效。

如果你不是重度下载用户，就不需要。

如果你是重度下载用户，或者你是计算机界的专业人士，那就必须要。因为有很多文件，只有迅雷的 CDN 服务器有资源，而且很多外网资源比如各种 OS 的 iso ，迅雷的 CDN 服务器也有资源，下载速度比梯子快。

@mark2025 不是。我说的集中式，指的是，应用、中间件、数据库等等，每一类只需要一台虚拟机即可，甚至可以在单台虚拟机里部署所有的应用、中间件、数据库。这种模式极大地方便程序员进行开发、排错。服务器能够自动进行硬件扩容与调优。

@xueyuehua 我说的集中式架构的硬件，指的是典型的 IBM Z 系列服务器（旗舰机）。这种机型，就算是 CPU 都能做成冗余的，能允许部分 CPU 故障。这种系统，不需要程序员对信息化系统进行分布式设计，因为它支持把多个 CPU 、内存，动态的划分给单个虚拟机。

你这个数据太分散，如果业务逻辑一直成功执行倒是没啥问题，不过一旦哪里出问题了，你要查询与排错就非常麻烦。

我遇到这种跨多个子系统的复杂流程，喜欢先设计一个超大的表单式数据结构，把所有的状态、时间、各种细节日志信息，都写在一条数据的字段里，这样查询方便、排错也方便。拿你这业务举个例子：

struct BuildAds
{
# BuildAds 数据区域
uint64 id;
uint64 用户 id;
uint64 部门 id;
uint64 批次 id;
uint64 策略 id;
datetime 创建时间;
uint64 调试 id;
uint64 调试链顺序级别 id;
uint64 调试链同级内部 id;
...其他 BuildAds 数据字段...;
#
# 素材处理数据区域
bool 是否需要处理素材;
datetime 素材列表开始处理时间;
datetime 素材列表处理超时终止时间;
string 素材列表处理超时终止细节；
datetime 素材列表处理错误时间;
string 素材列表处理错误细节;
List<struct 素材> 素材列表
{
string 素材 name;
uint 素材 size;
datetime 素材创建时间;
uint 素材创建用户 id;
datetime 素材开始上传时间;
datetime 素材上传最后一次中断时间;
datetime 素材上传最后一次续传开始时间;
datetime 素材上传超时终止时间;
string 素材上传超时终止细节;
datetime 素材上传其他错误时间;
string 素材上传错误细节;
datetime 素材上传完毕时间;
enum 素材上传状态; # 未开始上传、上传中、上传中断、续传中、超时终止、其他错误;
string 素材文件路径;
...其他素材文件数据字段...;
};
#
# 广告数据区域
datetime 广告开始搭建时间;
datetime 广告搭建终止时间;
string 广告搭建终止细节;
datetime 广告搭建错误时间;
string 广告搭建错误细节;
datetime 广告搭建成功结束时间；
...其他广告搭建数据字段...
enum 当前业务状态; # 已创建、素材处理中、素材处理终止或错误、搭建广告中、广告搭建终止或错误
}

我之所以会这样设计，是因为以前我设计过一个更复杂的业务，一套分布式多媒体系统，文件被人为移动过，但不知道从哪移动到哪里。业务逻辑是，要在多媒体列表里，把这些被移动的缺失的多媒体文件，找出来并更新多媒体列表。首先要解析多媒体列表，解析可能失败；然后备份列表文件，备份可能失败，备份可能重名；接着轮询多媒体列表里的每一条媒体文件数据，去全盘寻找，核对 HASH ，以及去重处理；接着有些多媒体文件能找到，有些找不到，这些也要处理。这里面一大堆状态，只有这种把状态与错误信息集中起来的超大表单式数据结构，才能方便开发、查询与排错。不然一旦数据结构分布在各个子系统中，查询与排错就巨麻烦，开发与排错效率巨低。

传统分布式架构，不仅是主流，而且会长期一直是主流。

原因很简单，集中式架构，软硬件太昂贵，大部分信息化的项目都买不起，只有银行、电力等大企业，对硬件的可用性有极端要求的，才用得起这种旗舰型集中式架构的软硬件。

笔录权限的设置，一点都不难。你的问题应该是，要不是你不会设置，要不就是你用的信息化系统太烂了，不支持完整的 RBAC 。

知乎不是快倒闭，而是多年以来都是烧钱，入不敷出。这平台不错，有点流氓广告跳转，可以理解。

我在京东上买的电子设备，都会加钱勾选最高年限的全面保险，包含性能故障与意外人为故障。出现这种问题，显卡能用就继续用，不能用就走保险进行维修即可。

门槛低，从业者人数多，高端岗位市场饱和而且还会被 AI 代替，导致工资低且不稳定。

有道云笔记，PC + 移动

不要去淘宝买游戏，因为代购商能用购买订单去找回账号。