Memcached - 如何处理添加/部署服务器
您如何处理生产应用程序中的替换/添加/删除 memcached 节点？ 由于每个客户都需要在同一个网络服务器上运行，因此我将拥有许多克隆和定制的应用程序，所以我猜测有一天某些节点将被更改。
以下是正常情况下填充 memcached 的方式：
$m = new Memcached();
$servers = array(
array('mem1.domain.com', 11211, 33),
array('mem2.domain.com', 11211, 67)
);
$m->addServers($servers);
我最初的想法是从数据库填充 $servers 数组，也缓存，但基于文件，每天完成一次或其他操作，可以选择强制下次更新运行保存 $addservers 调用的函数。但是，我猜测这可能会增加一些额外的开销，因为磁盘的存储速度相当慢......
您觉得怎么样？
How do you handle replacing/adding/removing memcached nodes in your production applications?
I will have a number of applications that are cloned and customized due to each customers need running on one and same webserver, so i'll guess that there will be a day when some of the nodes will be changed.
Here's how memcached is populated by normal:
$m = new Memcached();
$servers = array(
array('mem1.domain.com', 11211, 33),
array('mem2.domain.com', 11211, 67)
);
$m->addServers($servers);
My initial idea, is to make the $servers array to be populated from the database, also cached, but file-based, done once a day or something, with the option to force an update on next run of the function that holds the $addservers call. However, I am guessing that this might add some additional overhead since disks are quite slow storage...
What do you think?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
在源代码中定义类似的东西总是更好。当然，您可以使用
parse_ini_file()或类似的东西来读取配置文件。但实际上，它属于源头。但是，如果在 INI 文件中定义，则与在 PHP 中定义条目相比，不会有太多安全问题，例如代码注入等。由于有一些应用程序可能会读取相同的 INI 文件，因此您可以将其放在所有应用程序都可以访问的公共位置（例如，使用组权限）。实际上并不建议这样做。
It's always better to define things like that in the source. Granted, you could use
parse_ini_file()or something like that to read a configuration file. Really though, it belongs in the source. But if defined in an INI file, there aren't many security concerns such as code injection and the likes as opposed to defining your entries in PHP.Since there are a few applications that might be reading the same INI file, you can put it in a common location that all applications have access to (using group permissions, for example). Actually doing that isn't really recommended.
使用配置文件 - 无论是来自 parse_ini_file 还是其他配置解析方案。如果您担心解析时间，可以将这些配置放在 php ini 加载路径中 http://brian.moonspot.net/using-ini-files-for-php-application-settings - 这会预先解析您需要的所有变量，但您需要重新启动 apache 以加载所有更改。
一旦文件被足够读取（只要你的机器上没有太多的抖动），配置文件无论如何都会在内存映射缓存中，所以它会非常快。您可以使用加载速度快的 php 序列化形式进行优化，甚至可以使用 APC 用户缓存进一步优化。
最后，使用最新的 memcache 客户端库 - 它们现在使用一致的哈希算法，这将有助于添加/删除单个服务器。
Use a config file - whether its from parse_ini_file or some other config parsing scheme. If you are worried about parsing time, you could put those configs in the php ini load path http://brian.moonspot.net/using-ini-files-for-php-application-settings - this pre-parses all of the vars you need, but you'll need to restart apache to load any changes.
Once the files are read enough (as long as you dont have too much thrashing on your machine) the config file will be in memory mapped cache anyway, so it'll be really fast. You can optimize by using the php serialized form which loads fast, and even optimize further by using the APC user cache.
Lastly, use the newest memcache client libraries - they use the consistent hashing algorithms now, and it'll help adding/removing individual servers.
根据您的要求，如果您希望立即更新（主动模式），我会使用支持在某个 TTL（被动模式）或某种侦听器模式后自动驱逐的列表。无论您将主要源（属性文件、数据库等）保存在何处，只要在必要时可以访问并且您的 TTL 足够大（正如您在评论中提到的），都并不重要。
对于被动方法，您可以通过将服务器列表放入某个已知密钥下的缓存中，重用其他支持 TTL 的本地缓存库（例如 Java 中的 EHCache）。对于主动方法，例如，Java 有
java.util.EventListener。不幸的是，我已经很多年没有用 PHP 做过任何事情了，所以不能就此提供建议。我强烈建议不要将配置数据放入代码中。在我生活的世界里，硬编码是一种严重的罪过。
您可能还想看看最后如何。 fm 使用一致的哈希算法，以便能够在 memcached 池中添加/删除服务器，而不会导致所有键的完全重新映射。
Depending on your requirements I'd use a list that supports auto-eviction after some TTL (passive mode) or some sort of listener pattern if you want this to be updated immediately (active mode). Wherever you keep your primary source (properties file, database, etc.) is not really important as long as it is reachable when necessary and your TTL is big enough (as you mentioned in your comment).
For passive approach you could use reuse some other local caching library that supports TTL (e.g. EHCache in Java) by putting your list of servers into the cache under some known key. For active approach, for example, Java has
java.util.EventListener. It is (un)fortunately many years since I've done anything in PHP so can't advise on that.I would strongly advise against putting configuration data into the code. In the world I'm living hardcoding is a grave sin.
You might also want to have a look at how last.fm is using consistent hashing algorithm for being able to add/remove servers to/from the memcached pool without causing a complete remap of all keys.
据我所知，这里主要关心的是如何缓存配置，使其在更改时保持最新状态。
好吧，这里最好的选择显然是将其存储在数据库中并从数据库中刷新，例如每 15 秒刷新一次。应用程序负载很大，每 15 秒查询一次数据库根本不会改变任何东西。从数据库本身加载数据非常快，因为您只需要几个字段。
另一个可能在这里起作用的选项 - 使用单独的 memcached :) 说真的，只需缓存从数据库加载的配置，在配置更新时清除该缓存键。
总而言之：任何基于时间的到期方案都可以。最简单的解决方案 - 自行维护（存储上次刷新时间并在每个函数调用时检查它）；更高级一点——使用像 memcached 这样的东西。
更新：数据库是最好的解决方案，因为它的扩展性非常好：您不必在每次配置更新时在 20 个服务器之间复制配置。
As far as I udnerstood, the main concern here is how to cache the configuration keeping it mostly up-to-date when it changes.
Well, the best option here is obviously storing it in a database and refreshing from DB, say, every 15 seconds. Having big load on the application, querying the DB once a 15 secs won't change anything at all. Loading the data from DB itself is quite quick as you need just a couple of fields.
Another option that might work here – use a separate memcached :) Seriously, just cache the configuration loaded from DB there, purging that cache key on configuration update.
To sum up: any time-based expiration scheme would work. The simpliest solution – maintain it on your own (store last refresh time and check it on every function call); a bit more advanced – use something like memcached.
update: DB is the best solution as it scales pretty well: you don't have to copy configs across 20 servers on every configuration update.