由於我們可藉由產生帶重疊範圍的配對請求,而這些配對請求將併發(Concurrently)的觸發 MMF,就算是 Evaluation 已經針對這些 overlapping 選舉出最合適的結果,這會在其餘併發中的 MMF 選舉過程,產生一個短暫的衝突時間點,為了解決這樣的困擾,我們需要使用一個外力來中斷這些 MMF,這便是 Synchronizer 的同步作用。
簡單說起來這些狀態,便是為了完成 singleton 所設計出來的過程,分別為:
Idle State
: 閒置狀態,沒有正在處理的 MMFRegistration
: 註冊狀態,Open Match backend 在呼叫 MMF 之前會先向 Synchronizer 註冊,但這編其實有一個小限制,這些被記錄的註冊時間是有限制的,稱之為 Registration window,這個 window size 可透過設定檔調整,所有在同一個 Registration window 的配對請求將被一併評估ProposalCollection
: 配對搜集階段,當註冊階段完畢後,在 Registration window 的請求將觸發 MMF,並且產生一個 ProposalCollection window,將所有 MMF 回傳的結果搜集起來Evaluation
: 選舉階段,這階段發生在所有 MMF,都向 Evaluator 提出選舉評估時,會觸發 Synchronizer 控制以下兩種行為:
Synchronizer 可以透過調整以下設定值,來改變 Registration
and ProposalCollection
狀態的搜集時間。
registrationIntervalMs: millisecond
proposalCollectionIntervalMs: millisecond
~ kubectl describe -n open-match configmaps open-match-configmap-override
Name: open-match-configmap-override
Namespace: open-match
Labels: app=open-match
component=config
release=open-match
Annotations: chart: open-match-1.2.0
heritage: Helm
Data
====
matchmaker_config_override.yaml:
----
# Length of time between first fetch matches call, and when no further fetch
# matches calls will join the current evaluation/synchronization cycle,
# instead waiting for the next cycle.
registrationInterval: 250ms
# Length of time after match function as started before it will be canceled,
# and evaluator call input is EOF.
proposalCollectionInterval: 20s
# Time after a ticket has been returned from fetch matches (marked as pending)
# before it automatically becomes active again and will be returned by query
# calls.
pendingReleaseTimeout: 1m
# Time after a ticket has been assigned before it is automatically delted.
assignedDeleteTimeout: 10m
# Maximum number of tickets to return on a single QueryTicketsResponse.
queryPageSize: 10000
backfillLockTimeout: 1m
api:
evaluator:
hostname: "open-match-evaluator"
grpcport: "50508"
httpport: "51508"
Events: <none>