问题描述
我有正在考虑迁移到Redis Cluster的Lua脚本
I have Lua script which I'm considering migrating to Redis Cluster
在调用 eval 时，我应该指定完整的键名吗?还是仅通过指定主题标签就可以逃脱?
Should I specify full key names when call eval?Or can I get away just by specifying hashtags?
例如，我只希望传递{UNIQUE_HASH_TAG}而不是{UNIQUE_HASH_TAG}/key1，{UNIQUE_HASH_TAG}/key2 ...等
For example, I wish to pass only {UNIQUE_HASH_TAG} instead of {UNIQUE_HASH_TAG}/key1, {UNIQUE_HASH_TAG}/key2 ... etc
我有很多键，逻辑也很复杂-有时我最终会动态生成键名，但要在相同的哈希标签中.
I have lots of keys, and logic is pretty complicated - sometimes I end up generating key names dynamically but within the same hash tag.
我会通过仅传递哈希标签而不是键名来违反某些规范吗?
Would I violate some specifications by passing just hash tags instead of key names?
推荐答案
这是推荐的做法.
否，规范没有说明密钥名称需要显式传递. KEYS/ARGV机制已准备就绪，可以为群集做准备，但实际上尚未出现群集.当时，哈希标记还不是集群设计的一部分，因此推荐是为了避免在脚本中进行硬编码/动态生成键名，因为无法保证它们将位于同一集群哈希中插槽.
No, the specs do not state that key names need to be explicitly passed. The KEYS/ARGV mechanism was put in place in preparation for the cluster but before the cluster actually came to be. At that time, hash tags were not a part of the cluster's design so the recommendation was to avoid hard-coding/dynamically generating key names in scripts as there's no assurance they'll be in the same cluster hash slot.
您的方法是完全有效的，并且可以按预期工作.我确实要强调一点，只有在您管理许多所谓的{UNIQUE_HASH_TAG}时，这才有意义-否则，您只会碰到几个插槽，这可能会成为可伸缩性挑战.
Your approach is perfectly valid and would work as expected. I do want to emphasize that this only makes sense if you're managing a lot of the so-called {UNIQUE_HASH_TAG}s - otherwise you'll be hitting just a few slots which could become a scalability challenge.
编辑:话虽如此，您确实应该始终将键名显式传递给脚本，而不是欺骗.尽管目前尚未阻止此行为，但这种未指定的行为将来可能会更改，并会导致代码损坏.
EDIT: All that said, you really should always explicitly pass the key names to the script rather than tricking. While this isn't currently blocked, this unspecified behavior may change in the future and result in breakage of your code.
这篇关于在Redis Cluster中使用Lua时应该指定完整的密钥名称，还是可以仅传递#标签?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！