陈东明,饿了么北京研发中心架构组负责人;曾任百度架构师;公众号:dongming_cdm
本文发在DBAplus公众号,https://mp.weixin.qq.com/s/Uyw7MjqMW9DR6EInFIo9Wg,在自己的博客也发一遍。 在Redis升级到3.0版本后,升级到 集群 版本,被称之为 Redis cluster。在集群版本中,会将数据分成多份,被保存到多个server中,从而保证集群的水平扩展能力,加之每份数据保存多个副本,从而保证可用性。并且集群版本保证一定程度的Write Safety,本文详细介绍redis cluster的实现细节,从而分析Redis cluster的write safety的保证程度。
谈到 NoSQL,一定会提及一致性(Consistency),按照 CAP 定理,有些 NoSQL 数据库放弃了一致性,但是 NoSQL 放弃是必然的选择吗?
分析Paxos协议,分析Paxos协议是什么
最近对各种KV存储进行一个比较,从存储引擎到存储引擎的类型,到单机版的kvstore,再到分布式kvstore集群。
之前收集了一些存储产品,最近又重新整理了一下,对他们进行了简单的分类。每个对存储的分类可能不仅相同,我的分类完全按照自己的喜好来分,如和您的分类不同,仅供参考。只是做了搜集和分类,少量产品加了写介绍,希望以后有时间,加更多更详细的介绍。
单机并发是集群并发的基础。本文主要将单机并发问题,和解决这些单机并发问题的解决模型。
一般来说,消息队列都会保证queue当中的消息的顺序。然而如果有多个consumer同时消费同一个queue,那么这时就不能保证的消息的顺序性。 有时候,消息的顺序是非常重要的,为了能顺序的消费消息,我们只能启动一个consumer来消费这个queue。
在使用RabbitMQ的过程中,肯定会遇到这样的几个概念:transaction、confirm、ack。本文介绍一下这几个概念,以及他们之间的关系。
我们知道RabbitMQ可以配置成Queue做主从复制(按照官方的说法叫配置mirror queue),对master queue的写操作会被复制到其他slave上去(也就是复制到mirror queue上去)。
我的另外3篇文章分别介绍了Zookeeper,etcd,consul是如何实现分布式锁和选主的。本文想比较一下Zookeeper、etcd、consul内部机制有哪些不同,他们实现锁和选主的方式相同和不同。
Etcd的v3版本官方client里有一个concurrency的包,里面实现了分布式锁和选主。本文分析一下它是如何实现的。
Consul实现leader election的过程是这样的过程(这个过程主要翻译自[Consul的文档](https://www.consul.io/docs/guides/leader-election.html))
Zookeeper可以用来实现Distributed lock(分布式锁)和leader election(选主)。 分布式锁和选主虽然用在不同的场景,但是2者的机制是相同的。 Zookeeper官方文档上给出了一个recipes,介绍了如何实现分布式锁和选主,2种实现说明的步骤和风格完全不一样,但是本质是一样的。
ActiveMQ存储消息可以采用多种持久化方案,每种方案都有自己特有的集群方案。
本文分析一下RabbitMQ的可用性和可靠性。