第15章 Memcached 代理常见问题解答

特性内置代理常见问题内置代理常见问题有关内置代理的整体概述，请参阅内置代理部分。为什么选 Lua？ 大家大概想从 YAML 里喘口气吧 :) 我们把 Lua 当作胶水来用，发挥其可扩展性：几乎每个人的配置管理方式都不同，而一个简单的 Lua 脚本通常就能解析这类服务的输出，或直接与它们通信。只需寥寥几个 for 循环和对象复用，就能省掉数万行生成的配置。在路由处理上，我们对 Lua 的用法更大胆一些，但本质上它仍是胶水。路由配置往往宽而浅：根据请求内容调用几个小函数，随后把请求交回 C 侧处理。用 C 编写的对象方法还能进一步避免在常规操作中向 Lua 拷贝字符串或数据。由于该代理集成了 memcached 现有的系统，我们可以（随时间推移）确保所有大块内存分配都在 Lua 之外处理。其余那些极小的分配（如果有的话）与协程绑定，在（通常不到一毫秒的）请求/响应结束后立即释放。为什么不用 LuaJIT？ 答案的一半请参阅为什么选 Lua？ 在加载配置时，性能差异影响不大。而在路由处理中，Lua 做的极少，随着开发推进，这部分逻辑还会进一步精简甚至移除。项目启动初期，LuaJIT 的状态还不够稳定。况且 Lua 5.4 本身在语言和性能上也有不少改进。为什么不用 Mesh 路由器？ Memcached 代理并不打算取代 Mesh 路由器；它的定位更小、更侧重性能。Mesh 路由器虽然可高度配置、支持范围广，但速度很慢。缓存服务（此处为缓存代理）可用于修复因迁移至 Mesh 路由器而受损的服务性能，无论是出于成本还是实用性考虑。许多数据查询本就不该或不需要经过 Mesh 路由器。如果你想加速通过 Mesh 路由器端点实现的应用程序对数据存储的访问，缓存服务正是部署在该端点之后、实际数据存储之前的那一层。配置重载时，进行中的请求会怎样？ 配置重载时，mcp_config_routes 会被再次调用。在此过程中，路由被组装为函数，并携带这些顶层钩子调用 mcp.attach()。每当有请求进来时，系统都会检查这些顶层钩子及其关联的函数。这意味着，一旦请求触发钩子，在它完成之前就不受配置变更影响。新进来的请求会看到当前钩子中配置的逻辑，从而获取新代码，而旧请求仍在继续处理。因此，使用 Lua 全局变量时需要格外小心：我们建议路由使用函数闭包，以避免配置相互冲突。内部架构路由处理器参考