所以，我来到了一个地方，我想把我存储在redis的数据分割成单独的数据库，因为我有时需要在一种特定的数据上使用键命令，并想把它分开，以使其更快。
If I segment into multiple databases, everything is still single threaded, and I still only get to use one core. If I just launch another instance of Redis on the same box, I get to use an extra core. On top of that, I can't name Redis databases, or give them any sort of more logical identifier. So, with all of that said, why/when would I ever want to use multiple Redis databases instead of just spinning up an extra instance of Redis for each extra database I want? And relatedly, why doesn't Redis try to utilize an extra core for each extra database I add? What's the advantage of being single threaded across databases?
你不希望在一个redis实例中使用多个数据库。正如您所指出的，多个实例使您可以利用多个内核。如果使用数据库选择，则升级时必须进行重构。监视和管理多个实例并不困难，也不痛苦。
实际上，通过基于实例的隔离，您可以获得对每个db更好的度量。每个实例都有反映该数据段的统计信息，这可以实现更好的调优、响应更及时、更准确的监控。使用最新版本并按实例分隔数据。
正如Jonaton所说，不要使用按键命令。如果您只是创建一个键索引，您将发现更好的性能。无论何时添加键，都要将键名添加到集合中。keys命令在扩展后并不是特别有用，因为返回它将花费大量时间。
让访问模式决定如何构建数据，而不是按照您认为有效的方式存储数据，然后再考虑如何访问和切碎数据。您将看到更好的性能，并发现数据消费代码通常更干净和更简单。
对于单线程，考虑redis是为速度和原子性而设计的。当然，在一个db中修改数据的操作不需要等待另一个db，但是如果该操作保存到转储文件中，或者在slave上处理事务呢?在这一点上，您开始进入并发编程的杂草。
通过使用多个实例，您可以将多线程的复杂性转化为更简单的消息传递样式系统。
原则上，相同实例上的Redis数据库与RDBMS数据库实例中的模式没有区别。
所以，说了这么多，为什么/什么时候我想要使用倍数
Redis数据库，而不是仅仅旋转一个额外的Redis实例
为我想要的每个额外数据库?
There's one clear advantage of using redis databases in the same redis instance, and that's management. If you spin up a separate instance for each application, and let's say you've got 3 apps, that's 3 separate redis instances, each of which will likely need a slave for HA in production, so that's 6 total instances. From a management standpoint, this gets messy real quick because you need to monitor all of them, do upgrades/patches, etc. If you don't plan on overloading redis with high I/O, a single instance with a slave is simpler and easier to manage provided it meets your SLA.
I don't really know any benefits of having multiple databases on a single instance. I guess it's useful if multiple services use the same database server(s), so you can avoid key collisions.
I would not recommend building around using the KEYS command, since it's O(n) and that doesn't scale well. What are you using it for that you can accomplish in another way? Maybe redis isn't the best match for you if functionality like KEYS is vital.
I think they mention the benefits of a single threaded server in their FAQ, but the main thing is simplicity - you don't have to bother with concurrency in any real way. Every action is blocking, so no two things can alter the database at the same time. Ideally you would have one (or more) instances per core of each server, and use a consistent hashing algorithm (or a proxy) to divide the keys among them. Of course, you'll loose some functionality - piping will only work for things on the same server, sorts become harder etc.
甚至Salvatore Sanfilippo (Redis的创造者)也认为在Redis中使用多个db是一个坏主意。点击这里查看他的评论:
https://groups.google.com/d/topic/redis-db/vS5wX8X4Cjg/discussion
I understand how this can be useful, but unfortunately I consider
Redis multiple database errors my worst decision in Redis design at
all... without any kind of real gain, it makes the internals a lot
more complex. The reality is that databases don't scale well for a
number of reason, like active expire of keys and VM. If the DB
selection can be performed with a string I can see this feature being
used as a scalable O(1) dictionary layer, that instead it is not.
With DB numbers, with a default of a few DBs, we are communication
better what this feature is and how can be used I think. I hope that
at some point we can drop the multiple DBs support at all, but I think
it is probably too late as there is a number of people relying on this
feature for their work.
