我的問題是關於memcached。 Facebook使用memcached作爲其結構化數據的緩存，以減少用戶的延遲。他們利用Linux在Linux上優化了memcached的性能。 http://www.facebook.com/note.php?note_id=39391378919爲什麼facebook在memcached中使用TCP for SET和UDP for GET
但有趣的是，他們仍然使用TCP進行設置操作，但使用UDP進行獲取操作。
他們爲什麼要這麼做？我的意思是爲什麼不使用UDP進行設置操作呢？由於需要在操作系統中維護的狀態減少，因此UDP比TCP更好地擴展。
謝謝，
我認爲這是理解丟包的最好方法。 例如，當你使用Facebook聊天時，你會明白如果沒有收到一個句子，但你不能理解這在Ymsg中。
每個UDP數據報包含一個簡單的幀頭，後面跟上述的TCP協議格式相同的數據。在當前的 實現中，請求必須包含在單個UDP數據報中，但是 響應可能會跨越幾個數據報。 （唯一的共同要求，將 跨越多個數據包是巨大的多鍵get請求和set 請求，這兩者是更適合的可靠性TCP傳輸 原因反正。）
https://github.com/memcached/memcached/blob/master/doc/protocol.txt
這句話幾乎在揭示問題和解決方案：
雖然我們改善了與TCP的內存使用效率，我們搬到了UDP 對於GET操作，以減少網絡流量d實現 multi-gets的應用級流量控制（並行獲取數百個 個密鑰）。
TCP也是流量控制和在Memcache的情況下多重獲取它是相當連續的。您打開連接（或池），查詢鍵列表，等待，然後獲得所有值列表的結果。相反，他們在無連接並行UDP 得到之上自己實現了應用級流量控制。這裏有我看到的用於FB大小的軟件的UDP的好處：
另一方面，我認爲他們通過TCP寫一致性。帶有memcached的TCP提供了一個發送請求的事務，然後響應確認緩存更新。重新實現，在UDP中不會提供很多好處，我想。
他們想要確保他們收到的數據是正確的錯誤檢查，但不要給一個該死的，如果你正確地得到他們的數據？ – 2012-07-10 03:24:58
只要設置的執行頻率比獲得的低百倍 - 是否真的有很大的意義？ – zerkms 2012-07-10 03:25:55
@CoreyOgburn TCP和UDP都有校驗和。 TCP所做的是流量控制。如果你丟失了一個打包的TCP可以重新發送數據包，而在UDP中，整個數據必須被重新發送。 – 0xhacker 2012-07-10 04:14:40