为什么facebook在memcached中使用TCP进行SET，使用UDP进行GET

Question

我的问题是关于memcached的。Facebook使用memcached作为其结构化数据的缓存，以减少用户的延迟。他们在linux上使用UDP优化了memcached的性能。http://www.facebook.com/note.php?note_id=39391378919

但有趣的是，他们仍然使用TCP进行set操作，但使用UDP进行get操作。

他们为什么要这么做？我的意思是为什么不也使用UDP进行set操作呢？UDP的可扩展性优于TCP，因为它减少了需要在操作系统中维护的状态。

谢谢,

Answer 1

这句话几乎揭示了问题和解决方案：

虽然我们使用TCP提高了内存效率，但我们使用UDP进行get操作，以减少网络流量，并实现多get(数百个键的并行get)的应用级流量控制。

TCP也是流控制，在Memcache多获取的情况下，它是非常串行的。您打开连接(或将其池化)，查询键列表，等待，然后获得所有值的列表的结果。取而代之的是，他们在无连接的并行UDP get之上实现了应用程序级的流控制。以下是我在FB规模的软件中看到的UDP的好处：

• 不需要打开连接、池化连接、做额外的往返、会话、握手、保持连接等；
• 多个分布式Memcache服务器和索引可以并行查询，这符合微服务和“微缓存”作为服务的精神；
• 可以组播UDP包，提供冗余、负载均衡、动态路由甚至分片的高可用性-- first response wins!
• individual get time和retry策略可以在应用层实现；
• 只要有任何部分完整的数据可用，就可以立即执行逻辑-无需等待完整的多个get结果；

另一方面，我认为为了保持一致性，他们在TCP上进行了写操作。带有memcached的TCP提供了一个事务，在该事务中发送请求，然后响应确认缓存更新。我想，在UDP中重新实现它不会带来太多好处。

Answer 2

每个UDP数据报包含一个简单的帧头，后面是与上述TCP协议格式相同的数据。在当前的实现中，请求必须包含在单个UDP数据报中，但响应可以跨越多个数据报。(唯一会跨越多个数据报的常见请求是巨大的多键get请求和set请求，出于可靠性的原因，这两种请求都更适合传输。)

https://github.com/memcached/memcached/blob/master/doc/protocol.txt

Answer 3

我认为这是理解丢包的最好方法。例如，当你使用facebook聊天时，如果没有收到句子，你会理解，但在Ymsg中你无法理解这一点。