# Server->bind [TOC] 將連接綁定一個用戶定義的`UID`，可以設置`dispatch_mode=5`設置以此值進行`hash`固定分配。可以保證某一個`UID`的連接全部會分配到同一個`Worker`進程。 ~~~ function Server->bind(int $fd, int $uid); ~~~ * `$fd`：連接的`ID` * `$uid`：要綁定的`UID`，必須為非`0`的數字 * 未綁定`UID`時默認使用`fd`取模進行分配 > 同一個連接只能被`bind`一次，如果已經綁定了`UID`，再次調用`bind`會返回`false` > 可以使用`$serv->getClientInfo($fd)`查看連接所綁定`UID`的值 > 僅在設置`dispatch_mode=5`時有效 在默認的`dispatch_mode=2`設置下，`Server`會按照`socket fd`來分配連接數據到不同的`Worker`進程。因為`fd`是不穩定的，一個客戶端斷開后重新連接，`fd`會發生改變。這樣這個客戶端的數據就會被分配到別的`Worker`。使用`bind`之后就可以按照用戶定義的`UID`進行分配。即使斷線重連，相同`UID`的`TCP`連接數據會被分配相同的`Worker`進程。 ## 時序問題 客戶端連接服務器后，連續發送多個包，可能會存在時序問題。在`bind`操作時，后續的包可能已經`dispatch`，這些數據包仍然會按照`fd`取模分配到當前進程。只有在`bind`之后新收到的數據包才會按照`UID`取模分配。 因此如果要使用`bind`機制，網絡通信協議需要設計握手步驟。客戶端連接成功后，先發一個握手請求，之后客戶端不要發任何包。在服務器`bind`完后，并回應之后。客戶端再發送新的請求。 ## 重新綁定 某些情況下，業務邏輯需要用戶連接重新綁定`UID`。這時可以切斷連接，重新建立`TCP`連接并握手，綁定到新的`UID`。