鉴于常见问题解答报价，我正在寻找有关处理打开 memcached 连接的有效解决方案的建议：
记住没有什么能阻止你 不小心连接了很多次。如果 你实例化一个 memcached 客户端 对象作为你的对象的一部分 尝试存储，不要感到惊讶 当一个请求中有 1,000 个对象时 创建 1,000 个并行连接。 仔细寻找这样的错误 在进入列表之前。
另请参阅：Initializing a Memcached Client 和 Managing Connection Objects。
我考虑在我们的缓存程序集中使用单例来提供 memcached 客户端，但我确信必须有更好的方法，因为锁会引入（不需要的？）开销。
我很清楚客户端的使用模式，我不清楚的是如何在可扩展性和性能方面有效地使用客户端。其他人如何处理使用 memcached 客户端？
里面有 50 个赏金给你。
【问题讨论】：
标签： .net performance memcached scalability enyim
我们有一个与 redis 客户端类似的场景，最初我们的解决方案是拥有一个通用的单个实例，我们通过 lock 同步访问。这很好，但是为了避免延迟和阻塞，我们最终编写了一个线程安全的流水线客户端，它允许并发使用而没有任何阻塞。我对男性疼痛协议知之甚少，但我想知道类似的东西是否适用于此。如果您可以稍等片刻，我实际上很想尝试调查是否可以将其添加到 BookSleeve（我们的自定义 OSS redis 客户端）中。
但我们一般能够仅使用同步共享实例就跟上（与单例几乎相同，具体取决于您的纯粹程度）。
看了the FAQ，流水线确实有可能；我完全愿意在booksleeve 中编写一个异步/流水线内存缓存客户端。大多数原始 IO / 多路复用在 redis 中很常见。您可以考虑的其他技巧是尽可能使用 get_multi 等而不是单独获取 - 不过，我不知道您当前的客户端是否支持这一点（IK 还没有查看）。
但是：我不知道它如何将 memcached 与 redis 进行对比，但是在我们的例子中，切换到流水线/多路复用 API 意味着我们 不需要使用大量池（许多连接） - 单个连接（正确流水线化）能够支持来自单个节点的大量并发使用。
【讨论】：