在一套拥有多个 Application Server 的 SAP ABAP 系统里，同一种请求可能被分配到不同服务器，也可能被分配给不同 Work Process。站在系统管理员或者 ABAP 开发人员的角度观察，很容易产生一种直觉，SAP 好像到处都在做 Round Robin。这种判断只对了一部分。SAP 确实在若干关键位置使用了非常典型的 Round Robin，也存在 Weighted Round Robin，也就是加权轮询。但是 SAP 的许多负载均衡机制根本不是 Round Robin，而是根据当前用户数量、响应时间、空闲 Work Process、Server Capacity、Session Affinity 等信息动态决定目标服务器。如果把这些机制全部统称为 Round Robin，很容易在分析 SAP 性能问题时得出错误结论。经典的 Round Robin 可以先想成一个环形队列。假定系统中存在三个服务器 A、B、C，请求不断到来时，调度器按照下面的顺序选择服务器。A → B → C → A → B → C这种算法最大的优点就是简单。调度器不需要知道哪个服务器 CPU 更忙，不需要知道服务器上还有多少空闲 Work Process，也不需要计算响应时间，只需要记住上一次把请求交给了谁。问题也恰好出在这里。如果 A 是一台拥有 32 个 CPU Core 的服务器，而 B 和 C 只有 8 个 CPU Core，单纯按照 A → B → C 平均分发，请求数量虽然平均了，计算能力却没有平均利用。因此生产系统里更常见的做法是 Weighted Round Robin。假设 A 的权重为 4，B 从 Web Dispatcher 到 Update Server，彻底看懂 SAP ABAP 系统里的 Round Robin 机制
在一套拥有多个 Application Server 的 SAP ABAP 系统里，同一种请求可能被分配到不同服务器，也可能被分配给不同 Work Process。站在系统管理员或者 ABAP 开发人员的角度观察，很容易产生一种直觉，SAP 好像到处都在做 Round Robin。这种判断只对了一部分。SAP 确实在若干关键位置使用了非常典型的 Round Robin，也存在 Weighted Round Robin，也就是加权轮询。但是 SAP 的许多负载均衡机制根本不是 Round Robin，而是根据当前用户数量、响应时间、空闲 Work Process、Server Capacity、Session Affinity 等信息动态决定目标服务器。如果把这些机制全部统称为 Round Robin，很容易在分析 SAP 性能问题时得出错误结论。经典的 Round Robin 可以先想成一个环形队列。假定系统中存在三个服务器 A、B、C，请求不断到来时，调度器按照下面的顺序选择服务器。A → B → C → A → B → C这种算法最大的优点就是简单。调度器不需要知道哪个服务器 CPU 更忙，不需要知道服务器上还有多少空闲 Work Process，也不需要计算响应时间，只需要记住上一次把请求交给了谁。问题也恰好出在这里。如果 A 是一台拥有 32 个 CPU Core 的服务器，而 B 和 C 只有 8 个 CPU Core，单纯按照 A → B → C 平均分发，请求数量虽然平均了，计算能力却没有平均利用。因此生产系统里更常见的做法是 Weighted Round Robin。假设 A 的权重为 4，B