计算高可用的两个关键设计点，及"任务分配器"是逻辑概念

计算高可用的设计目标是部分硬件损坏时计算任务能继续正常运行，本质是靠冗余规避部分故障风险——单台服务器无论如何都做不到这一点，所以思路很朴素：增加更多服务器。计算高可用架构设计的复杂度主要集中在”任务管理”上，即某台服务器上任务执行失败后，怎么把任务重新分配到另一台服务器执行，具体拆成两个关键设计点。第一是”哪些服务器可以执行任务”：一种方式是每台服务器都能执行任务（类似高性能集群里的模式，比如访问网站某个页面这类无状态任务）；另一种方式是只有特定服务器（通常叫”主机”）才能执行任务，主机故障后需要挑选新的服务器接手（比如只有ZooKeeper的Leader才能处理写操作）。第二是”任务如何重新执行”：一种策略是已分配的任务失败了就不做任何补救，系统只保证新来的任务能分配到其他健康服务器执行；另一种策略是设计一个专门的任务管理器来追踪任务执行结果，服务器执行完要向它反馈，由它决定是否需要把任务重新分配给别的服务器。这里有个容易被误解的地方：”任务分配器”只是一个逻辑上的概念，并不意味着系统里必须存在一个独立的物理模块来专门承担这个角色——比如Nginx把页面请求转发给Web服务器、静态文件直接走本地缓存，Nginx本身是反向代理系统，但同时也承担了任务分配器的职责，没必要在Nginx后面再单独架一个任务分配器；对于后台批量运算类任务，可以设计一个独立的任务分配系统专门管理这些批处理任务；ZooKeeper里的Follower节点收到写请求会转发给Leader处理、收到读请求自己处理，这时Follower本身就相当于一个逻辑上的任务分配器。