代理IP多账号与多后端集群共用一个矛盾要处理：均衡的本能是把请求尽量摊开，可很多业务希望同一用户的请求始终落在同一台后端——登录状态、购物车、进行中的操作都存在某一台机器上，换台机器就「不认识」了。摊开与粘住，两种诉求在系统里拉扯。
矛盾的两头
先看矛盾从哪来：无状态业务没有这个问题——每个请求独立处理，分给谁都一样；有状态业务才有——状态存在具体某台后端的内存或会话里，用户的下一个请求必须回到那台机器才能接上。均衡与粘性的冲突，本质是有状态业务特有的烦恼。状态放在服务器内存是最常见的形态，但换机器就丢；把状态外置到共享存储（数据库或缓存），任何后端都能接续同一用户——外置是治本，粘性只是兜底。
粘性怎么落地
化解矛盾的常见手段是会话粘性（粘性会话）：均衡器记住「这个用户第一次分给了哪台后端」，之后他的请求都尽量送回同一台。实现上可以按来源特征算固定去向（一致性哈希就是思路之一），也可以由后端下发标记、均衡器按标记路由。粘性依据要选对：按来源地址粘，同一出口或同一网络下的用户可能被粘成一团；按登录标记粘更精准，但要求业务配合下发标记——粘性实现不难，难在依据的取舍，这套手段在代理IP的会话保持类配置里也能见到。
粘性也有代价
粘性换来连续性，代价是均衡度下降：被粘住的用户全压在一台后端上时，别的后端可能闲着——分摊的效果打折了。成熟系统的做法是「既粘又散」：状态尽量外置到共享存储，让任何后端都能接续同一用户的请求，把粘性的依赖降到最低——代理IP在固定与轮换出口之间取舍，权衡的也正是连续与均衡这对关系。
代理IP场景的同款拉扯
这套拉扯在代理IP多账号场景里也有同款：账号的登录会话与出口有对应关系，换出口可能触发重新验证——固定出口给需要连续的账号、轮换出口给不依赖连续的批量任务，正是「按连续性需求分流」的代理IP版协调方案。对代理IP批量任务而言，多数任务本身是无状态的——单个请求独立完成、失败重跑即可，并不需要粘性；只有登录态保持类任务才需要「出口与账号固定对应」。分清自己的任务有没有状态，是决定要不要「粘」的第一判断。
均衡想摊开、会话想粘住：有状态业务用粘性保连续、用状态外置降依赖——协调的关键是先分清业务有没有状态。
粘性与均衡的协调还有一个工程细节：粘性策略要能「到期」。会话总会结束，粘性如果无限期生效，用户早走了后端还占着位置——粘性记录设个有效期，超时后重新回到均衡分配，既保住了会话期间的连续，又不让历史粘性长期扭曲负载的分布，新老用户各得其所。
会话与均衡协调好之后，均衡系统要面对的下一个话题是「规模会变」：业务涨了要加机器，跌了要减机器——负载均衡在弹性伸缩里扮演什么角色，为什么说它是扩缩容的枢纽，代理IP任务的扩量收缩也是同样的节奏，下一篇展开。