【问题标题】:Any workaround for distributing(sharding) key of collections like Lists, Sets etc任何分发(分片)集合键的解决方法,如列表、集合等
【发布时间】:2014-11-19 09:59:23
【问题描述】:

我们使用 Redis 2.8.17 作为 JobQueues。

我们正在使用 RPUSH 和 BRPOPLPUSH 来建立可靠的队列。

根据我们当前的设计,多个应用服务器将 (RPUSH) 作业推送到单个作业队列。由于 BRPOPLPUSH 操作在 redis 中是原子操作,因此这些作业稍后将被弹出 (BRPOPLPUSH) 并由服务器的任何消费者处理。

由于应用服务器能够横向扩展,我有点担心 REDIS 将来可能会成为瓶颈。

我从有关 redis 分区的文档中了解到以下内容: “不可能像一个非常大的排序集那样用一个巨大的键对数据集进行分片”

我想知道为应用服务器预先分片队列是否是横向扩展的唯一选择。

上面的设计中集群有什么可以做的吗?

【问题讨论】:

    标签: java redis jedis


    【解决方案1】:

    您需要考虑的主要问题是您是否需要分片。整个 StackExchange 网络(不仅仅是 StackOverflow——all 网络)运行在 2 个 Redis 服务器(我很确定其中一个仅用于冗余),它非常积极地使用它们。看看http://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-stack-overflow/

    Redis 的速度荒谬快(并且非常节省空间),只有一个警告:删除整个列表/集/排序集/哈希是 O(n),其中 n 是数字它包含的元素。只要您不这样做(RPOPBRPOPBRPOPLPUSH 等操作都不算数 - 这些是恒定时间),您就应该是黄金。

    TLDR:除非您计划比 StackOverflow 更大,否则您不需要分片,尤其是对于简单的作业队列。

    【讨论】:

    • 听起来很合理,如果我们快速扩展,我们只是将其视为 B 计划。我们会等到我们到达那个点。感谢您的回复。
    猜你喜欢
    • 1970-01-01
    • 2021-07-14
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-08-31
    • 2018-12-15
    • 1970-01-01
    相关资源
    最近更新 更多