Caching 为什么facebook在memcached中对SET使用TCP，对GET使用UDP
我的问题是关于memcached的。Facebook使用memcached作为结构化数据的缓存，以减少用户的延迟。他们在linux上使用UDP优化了memcached的性能 但有趣的是，他们仍然使用TCP进行set操作，而使用UDP进行get操作 他们为什么要这样做？我的意思是，为什么不使用UDP进行set操作呢？UDP的可扩展性优于TCP，因为它减少了操作系统中需要维护的状态Caching 为什么facebook在memcached中对SET使用TCP，对GET使用UDP,caching,memcached,key-value,Caching,Memcached,Key Value,我的问题是关于memcached的。Facebook使用memcached作为结构化数据的缓存，以减少用户的延迟。他们在linux上使用UDP优化了memcached的性能 但有趣的是，他们仍然使用TCP进行set操作，而使用UDP进行get操作 他们为什么要这样做？我的意思是，为什么不使用UDP进行set操作呢？UDP的可扩展性优于TCP，因为它减少了操作系统中需要维护的状态 谢谢，我认为这是理解数据包丢失的最好方法。 例如，当你使用facebook聊天时，你会理解是否有一句话没有收到，但在Y
谢谢，我认为这是理解数据包丢失的最好方法。
例如，当你使用facebook聊天时，你会理解是否有一句话没有收到，但在Ymsg中你无法理解 每个UDP数据报都包含一个简单的帧头，后跟 与上述TCP协议的格式相同。当前 实现时，请求必须包含在单个UDP数据报中，但 响应可能跨越多个数据报。（唯一的共同要求是 span多个数据报是巨大的多键
getset这句话几乎揭示了问题和解决方案： 虽然我们使用TCP提高了内存效率，但我们还是转向了UDP 用于get操作以减少网络流量并实施 多个GET（数百个GET）的应用程序级流控制 并行键） TCP也是流量控制，在Memcache multi-Get的情况下，它是非常串行的。您打开连接（或池连接），查询键列表，等待，然后获取包含所有值列表的结果。相反，他们在连接较少的并行UDP GET之上实现了应用程序级流控制。以下是UDP对FB大小软件的好处：
- 不需要打开连接、共享连接、进行额外的往返、会话、握手、保持生命等等
- 可以并行查询多个分布式Memcache服务器和索引，符合微服务和“微缓存”服务的精神
- 可以多播UDP数据包，以提供高可用性与冗余，负载平衡，动态路由，甚至分片-第一反应赢
- 可以在应用程序级别上实施单独的获取超时和重试策略
- 只要有任何部分完整的数据可用，就可以执行逻辑-无需等待完整的multi-get结果
另一方面，我认为他们确实通过TCP进行写操作，以确保一致性。带有memcached的TCP提供了一个事务，其中发送请求，然后响应确认缓存更新。我想，在UDP中重新实现这一点不会带来太多好处。他们希望确保接收到的数据经过正确的错误检查，但不要管你是否正确获取了他们的数据？只要set的执行频率比get少一百倍，这真的有意义吗？@CoreyOgburn TCP和UDP都有校验和。TCP所做的是流控制。如果丢失打包的TCP，则可以重新传输数据包，而在UDP中，则必须重新传输整个数据。@zerkms Yes set的频率比get低100倍，但为什么要使用TCP呢？@hobyst:因为丢失的set数据包会导致性能下降，甚至导致不正确的缓存状态（只要缓存在需要时不会失效），而几个丢失的get不会失效？