3
我們正在使用PubNub實時通信聊天應用工作。
PubNub允許在單個通道組中包含2000個通道，之後您可以通過連接最多訂閱10個組。
我們現在面臨的問題是我們的後端排序需要訂閱每個現有的渠道（通過組），因爲我們有一個Bot可以響應命令。
我們將通道一組channel_group_add_channel增加超過2000個頻道時PubNub不出錯時如何處理在node.js的這種連接，但是，而是返回一個200響應，只是拿出一個以前的通道（不知道哪一個）。
因此，我需要檢查一個組中當前的通道數量是多少，如果它滿了 - 開始一個新的組。
問題：
我們可以得到多個同時用戶註冊，這意味着新的渠道補充說，我們的機器人需要訂閱。
僞代碼來檢查我們是否可以添加更多的渠道到當前組。
addChannel(channel) {
group.canAdd()
.then(group.add(channel));
}
canAdd將使用channel_group_list_channels檢查了多少個通道組中目前。因爲JavaScript的異步性，我們有一個競爭條件：
- 目前集團擁有1999年渠道
- 呼叫
addChannel兩次 - 兩個呼叫
channel_group_list_channels可能回到1999年渠道 - 我們添加的第一通道（組現在2000）
- 我們添加第二個頻道，因爲我們認爲我們可以
- 某些頻道被推出組（壞）。
有沒有一種方法可以在不降低性能的情況下解決這個問題？
請注意，即使在類似Redis的計數器中也會有同樣的問題，因爲問題是併發性的。
這是一個高級的用例（扇入），你應該聯繫[PubNub支持] （http://www.pubnub.com/support）與解決方案架構師聯繫。而且我們有一個更強大的方法 - [PubNub BLOCKS功能即將推出]（https://www.pubnub.com/products/blocks/）爲您實現這一點，不需要您的服務器訂閱每一個頻道。 –
順便說一句，策略（高級版本）將實例化多個PUBNUB實例，每個實例可以訂閱10個通道組，每個通道組中有2000個通道。但是，PubNub渠道組不會奇蹟般地使您的服務器上的網絡，CPU和RAM限制消失。您仍然必須考慮您的服務器在窒息之前可以一次消耗多少消息，或者無法跟上。這就是PubNub全球數據流網絡必須爲1000多位客戶（數十億客戶，跨越多個數據中心的數百億交易）所做的事情 - 待續... –
因此，解決方案是一項分佈式計算挑戰，想做，但我們可以幫助你。而PubNub Blocks會使這不必要。請聯繫我們，我們會做到這一點！ –