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

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

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

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

搬瓦工 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 + 移动

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

喜欢折腾，选择 PVE 会更好，更灵活，更方便。

不想折腾，我更倾向于直接买白群晖，开箱即用。

Unraid 要收费，而且需要一定的折腾，感觉两边不讨好。

你这需求相当于重度生产+游戏，用台式机方案，不建议小机箱。一来不利于散热，二来不利于扩展。建议至少 ATX 标准机箱，有条件可以上 E-ATX 加大机箱。

认知缺陷。

先给你看个数据，人类每天消耗的鸡鸭鱼猪牛羊等的数量，相当于整个一战+二战牺牲人数的总和。注意，前者单位是每天。这还没算上地球上各种生物的数量，那就更多了。

换句话说，当你成为人类，来到这个世界上，其实已经是逆天改命了。好好活着，这已经就很逆天了。