我最近試圖將讀操作的工作量發送到雙節點Cassandra集羣（版本2.0.9，rf = 2）。我的意圖是以高於後端服務器容量的速率發送一些讀取數據，從而壓倒他們並導致服務器端排隊。爲此，我使用datastax java驅動程序（cql版本2）以異步方式運行我的操作（換句話說，調用線程不會阻止等待響應）。Cassandra節流工作量
問題是我無法達到足夠高的發送速率來超載我的後端服務器。我發送的請求數正在被Cassandra扼殺。爲了證實這一點，我已經同時從兩臺不同的機器上運行客戶端，並且每單位時間發送的請求總數仍然達到峯值。我想知道是否有Cassandra用來限制正在接收的請求數量的機制？否則，還有什麼可能導致這種行爲？
Cassandra端的網絡帶寬限制了正在接收的請求數量。
據我所知，他們沒有其他機制被Cassandra用來阻止自己接收太多的請求。超時異常是Cassandra在重載時避免崩潰的主要機制。
Cassandra收到的每個請求都將由多個線程池執行，這些線程池實現了staged event-driven architecture，其中請求將在每個階段排隊。您可以使用nodetool tpstats來檢查每個隊列的當前狀態。一旦太多請求淹沒服務器，Cassandra將在隊列即將達到其容量時通過放棄請求來減輕負載。您會通過tpstats的丟失部分中顯示的數字來注意到這一點。如果沒有請求被丟棄，所有這些請求最終都會完成，但在客戶端上使用nodetool cfhistograms或WriteTimeoutExceptions可能會看到更高的延遲。
我已經檢查過Cassandra的threadpoolexecutor的代碼庫，我的理解是workqueue實際上是無界的（即最大尺寸默認設置爲任意高的值）。但是，即使假設這不是事實，tpstats報告0阻塞/丟棄的操作。 –
需要注意的是，我正在使用的java驅動客戶端沒有超時，並且Cassandra的隊列沒有爆炸（即它們在0到300之間波動）。但是，儘管如此，在我的實驗中，我無法超過一定的發送速率。 –
是的，卡桑德拉有多種方法來限制傳入的請求。你的第一個行動是找出哪個機制是罪魁禍首。然後你可以調整這個機制來適應你的需求。
找出塊發生的第一步是使用jconsole或類似的方式連接到JMX，並查看隊列和塊值。
如果我會冒險猜測，請檢查MessagingService是否超時並在節點之間丟棄消息。然後，在請求甚至到達階段之前，檢查阻塞任務的本地傳輸請求。
我不認爲是這樣。 cassandra節點以及使用10Gig鏈接的客戶端相互連接。我在監控網絡流量的同時對兩個Tx/Rx運行我的實驗，並且從未超過100 mb/s。我認爲其他機制是這裏的罪魁禍首。 –
通過增加插入條目的大小，您可以輕鬆驗證您的網絡帶寬不是問題。 – DineMartine
同樣，您可以減小此大小以強制cassandra等待處理的請求。 – DineMartine