首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

redis集群设计方案及原理

设计集群方案时,至少要考虑以下因素: (1)高可用要求:根据故障转移的原理,至少需要3个主节点才能完成故障转移,且3个主节点不应在同一台物理机上;每个主节点至少需要1个从节点,且主从节点不应在一台物理机上;因此高可用集群至少包含6个节点。 (2)数据量和访问量:估算应用需要的数据量和总访问量(考虑业务发展,留有冗余),结合每个主节点的容量和能承受的访问量(可以通过benchmark得到较准确估计),计算需要的主节点数量。 (3)节点数量限制:Redis官方给出的节点数量限制为1000,主要是考虑节点间通信带来的消耗。在实际应用中应尽量避免大集群;如果节点数量不足以满足应用对Redis数据量和访问量的要求,可以考虑:

01

08 Confluent_Kafka权威指南 第八章:跨集群数据镜像

本书大部分内容都在讨论单个kafka集群的配置、维护和使用。但是,在一些场景中,可能需要多集群架构。 在某些情况下,集群是完全分离的,他们属于不同部门的不同实例,没有理由将数据从一个集群复制到另外一个集群。有时,不同的SLA或者工作负载使得单个集群提供多个用例服务的集群很难调优。在某些时候,还有不同的安全需求。这些场景非常容易管理多个不同的集群,就像多次允许单个集群一样。 在其他场景中,不同的集群是互相依赖的,管理有要不断地在集群之间复制数据。在大多数数据库中,在数据库服务之间持续复制数据称为复制。由于我们使用复制来描述属于同一集群的kafka节点之间的数据移动,因此我们将把kafak集群之间的数据复制称之为镜像。Apache kafka内置的跨集群 的复制器称为mirrormaker。 在本章中,我们将讨论所有或者部分数据的跨集群镜像。我们将首先讨论跨集群的镜像的一些常用用例。然后我们将展示一些用于实现这些用例的架构,并讨论每种架构的优缺点。然后我们将讨论MirrorMaker本书以及如何使用它。我们将分享一些操作技巧,包括部署的性能调优。最后我们将讨论mirrorMaker的一些替代方案。

03
领券