假设我想要一个拥有尽可能多的用户账户的服务器。最多可以有多少个？
我想要数百万个用户帐户。这太疯狂了吗？我会托管数十个负载平衡镜像，用户数据将存储在高可用性存储共享中，而所有其他数据则被视为易失性数据。
答案1
理论上，您可以拥有与用户 ID 空间支持的数量相同的用户。要确定特定系统上的数量，请查看类型的定义uid_t。它通常定义为unsigned int或int意味着在 32 位平台上您可以创建多达近 43 亿个用户。在 64 位平台上，您可以拥有超过 16e18 个不同的用户 ID。
但是，在达到此限制之前，其他资源可能会耗尽，例如磁盘空间。如果您为每个用户创建一个主目录，那么即使每个用户只有 1MB 的空间，您也需要超过 4PB 的存储空间。此外，大量用户让进程在后台运行、安排 cron 作业、打开 ftp 和/或 ssh 会话可能会给系统带来严重负担。
答案2
直到 UID 空间耗尽。现代系统使用 32 位无符号整数，其中 65535 和 4294967295 是“任意”/“未知”等的魔法值，因此可以容纳 4294967294 个并发不同用户。较旧的系统可能仍显示 16 位无符号整数。
答案3
其他答案都直接回答了 OP 关于具体限制的问题。考虑到 SF 也是长期参考的性质，我认为有必要指出你正在考虑的方法的一个非常重要的警告。
你想使用目录服务来管理如此规模的用户帐户是件很困难的事。这正是目录服务（例如 OpenLDAP、Active Directory 等）设计时要解决的问题。
使用“标准”[1] Unix 用户工具来管理大量本地用户账户是一种非常痛苦且老套的方法，它不容易扩展，而且 - 考虑到您的问题描述 - 当它实际上不能通过多台服务器进行水平扩展时，很可能会导致对您选择的解决方案进行重大的重新架构。
[1] 它们的工作方式大体类似，但确切的用法因平台而异，有时甚至在类似的传统 Linux 发行版中也不同，当然也会随着操作系统的发行版本而定期更改。买者自慎。
答案4
如上所述，您理论上受到 UID 无符号整数大小的限制，但在达到该限制之前很可能会受到当前资源的限制。