一旦检测到过载状况，我们就必须决定如何加以处理。或者更具体地讲，我们需要考量放弃哪些请求。这时，我们首先需要明确一点，各项请求之间并不是平等的：“The operation log of WeChat shows that when WeChat Pay and Instant Messaging experience a similar period of service unavailability, user complaints against the WeChat Pay service are 100x those against the Instant Messaging service.”（微信的运营日志显示，每当与微信支付与即时消息体验相关的服务发生不可用问题时，用户对微信支付服务的投诉是针对即时消息收发服务的100倍。）
为了以服务中立性方式处理这个问题，每项请求在首次进入系统时都会被赋予一种业务优先级。这项优先级会随着所有下游请求一同继承。用户请求的业务优先级由其请求的操作类型决定。虽然存在数百个入口点，但实际其中只有几十个具有显性优先级，其它所有入口点都默认属于较低优先级。优先级设定保留在复制的哈希表当中。
图：用于存储微信入口服务内操作执行业务优先级的哈希表
当过载控制被设定为业务优先级n时，所有来自n+1等级的请求都将被放弃。这种方式对于混合型工作负载来说效果良好，但假定我们面对的是大量付款请求，而所有请求都具有相同的优先级（假定为p），那么一旦系统遭遇过载，我们就需要调整过载阈值以实现轻载，即将过载阈值变更为p-1。而一旦检测到轻载，过载阈值将再次增加至p，这时我们将重新面对过载状态。因此，要在大量具有相同优先级的请求引发超载时停止这种无意义的转换，我们需要采用超越业务优先级的细粒度调整。
微信对此拿出了一种良好的解决方案。其增加了基于用户ID的第二层接纳控制机制。“User priority is dynamically generated by the entry service through a hash function that takes the user ID as an argument. Each entry service changes its hash function every hour. As a consequence, requests from the same user are likely to be assigned to the same user priority within one hour, but different user priorities across hours.”（用户优先级由入口服务通过以用户ID为参数的哈希函数动态生成。每项入口服务每小时变更一次其哈希函数，因此来自同一用户的请求很可能在一小时之内被分配予相同的用户优先级，但在数小时内被分配予不同的用户优先级。）
