Category: Distributed Architecture

0

[转]深入学习Redis(3):主从复制

1. 前言 在前面的两篇文章中,分别介绍了Redis的内存模型和Redis的持久化。 在Redis的持久化中曾提到,Redis高可用的方案包括持久化、主从复制(及读写分离)、哨兵和集群。其中持久化侧重解决的是Redis数据的单机备份问题(从内存到硬盘的备份);而主从复制则侧重解决数据的多机热备。此外,主从复制还可以实现负载均衡和故障恢复。 这篇文章中,将详细介绍Redis主从复制的方方面面,包括:如何使用主从复制、主从复制的原理(重点是全量复制和部分复制、以及心跳机制)、实际应用中需要注意的问题(如数据不一致问题、复制超时问题、复制缓冲区溢出问题)、主从复制相关的配置(重点是repl-timeout、client-output-buffer-limit slave)等。

0

[转]深入学习Redis(2):持久化

1. 2. 前言 在上一篇文章中,介绍了Redis的内存模型,从这篇文章开始,将依次介绍Redis高可用相关的知识——持久化、复制(及读写分离)、哨兵、以及集群。 本文将先说明上述几种技术分别解决了Redis高可用的什么问题;然后详细介绍Redis的持久化技术,主要是RDB和AOF两种持久化方案;在介绍RDB和AOF方案时,不仅介绍其作用及操作方法,同时介绍持久化实现的一些原理细节及需要注意的问题。最后,介绍在实际使用中,持久化方案的选择,以及经常遇到的问题等。

0

[转]深入学习Redis(1):Redis内存模型

1. 前言 Redis是目前最火爆的内存数据库之一,通过在内存中读写数据,大大提高了读写速度,可以说Redis是实现网站高并发不可或缺的一部分。 我们使用Redis时,会接触Redis的5种对象类型(字符串、哈希、列表、集合、有序集合),丰富的类型是Redis相对于Memcached等的一大优势。在了解Redis的5种对象类型的用法和特点的基础上,进一步了解Redis的内存模型,对Redis的使用有很大帮助,例如: 1、估算Redis内存使用量。目前为止,内存的使用成本仍然相对较高,使用内存不能无所顾忌;根据需求合理的评估Redis的内存使用量,选择合适的机器配置,可以在满足需求的情况下节约成本。 2、优化内存占用。了解Redis内存模型可以选择更合适的数据类型和编码,更好的利用Redis内存。 3、分析解决问题。当Redis出现阻塞、内存占用等问题时,尽快发现导致问题的原因,便于分析解决问题。 这篇文章主要介绍Redis的内存模型(以3.0为例),包括Redis占用内存的情况及如何查询、不同的对象类型在内存中的编码方式、内存分配器(jemalloc)、简单动态字符串(SDS)、RedisObject等;然后在此基础上介绍几个Redis内存模型的应用。 在后面的文章中,会陆续介绍关于Redis高可用的内容,包括主从复制、哨兵、集群等等,欢迎关注。

0

[转]开源分布式数据库TiDB如何炼成

如今硬件的性价比越来越高,网络传输速度越来越快,数据库分层的趋势逐渐显现,人们已经不再强求用一个解决方案来解决所有的存储问题,而是通过分层,让缓存与数据库负责各自擅长的业务场景。 TiDB 作为一款 HTAP 数据库,在高性能的实现 OLTP 特性基础之上,也同时提供基于实时交易数据的实时业务分析需求。 什么是 TiDB 数据库?

0

[转]大规模集群任务调度

常见的调度系统往往兼顾了准确度却牺牲了性能,容器调度的复杂性使得很难在准确和效率之间找到平衡点,尤其是在交互式调度的场景下,可取的解决方案更是捉襟见肘。 随着分布式计算集群规模的不断扩张,任务调度系统的稳定性成为了整个集群稳定的关键因素。随着容器技术的快速兴起,基于容器的计算平台被大量应用,任务调度的规模及频率快速上升,这对任务调度系统提出了更为严苛的挑战。 常见的调度系统往往兼顾了准确度却牺牲了性能,容器调度的复杂性使得很难在准确和效率之间找到平衡点,尤其是在交互式调度的场景下,可取的解决方案更是捉襟见肘。本篇文章就以此为背景,介绍大规模调度场景下分布式任务调度的难点、解决策略及现有的一些方案。

[转]史上最全 40 道 Dubbo 面试题及答案 0

[转]史上最全 40 道 Dubbo 面试题及答案

Dubbo是国内最出名的分布式服务框架,也是 Java 程序员必备的必会的框架之一。Dubbo 更是中高级面试过程中经常会问的技术,无论你是否用过,你都必须熟悉。 下面我为大家准备了一些 Dubbo 常见的的面试题,一些是我经常问别人的,一些是我过去面试遇到的一些问题,总结给大家,希望对大家能有所帮助。

0

[转]ZooKeeper搞定服务注册与发现

1. 背景 最近在做分布式相关的工作,由于人手不够只能我一个人来怼;看着这段时间的加班表想想就是够惨的。 不过其中也有遇到的不少有意思的事情今后再拿来分享,今天重点来讨论服务的注册与发现。 2. 分布式带来的问题 我的业务比较简单,只是需要知道现在有哪些服务实例可供使用就可以了(并不是做远程调用,只需要拿到信息即可)。 要实现这一功能最简单的方式可以在应用中配置所有的服务节点,这样每次在使用时只需要通过某种算法从配置列表中选择一个就可以了。 但这样会有一个非常严重的问题: 由于应用需要根据应用负载情况来灵活的调整服务节点的数量,这样我的配置就不能写死。 不然就会出现要么新增的节点没有访问或者是已经 down 掉的节点却有请求,这样肯定是不行的。 往往要解决这类分布式问题都需要一个公共的区域来保存这些信息,比如是否可以利用 Redis? 每个节点启动之后都向 Redis 注册信息,关闭时也删除数据。 其实就是存放节点的 ip + port,然后在需要知道服务节点信息时候只需要去 Redis 中获取即可。 如下图所示: 但这样会导致每次使用时都需要频繁的去查询 Redis,为了避免这个问题我们可以在每次查询之后在本地缓存一份最新的数据。这样优先从本地获取确实可以提高效率。 但同样又会出现新的问题,如果服务提供者的节点新增或者删除消费者这边根本就不知道情况。 要解决这个问题最先想到的应该就是利用定时任务定期去更新服务列表。 以上的方案肯定不完美,并且不优雅。主要有以下几点: 基于定时任务会导致很多无效的更新。 定时任务存在周期性,没法做到实时,这样就可能存在请求异常。 如果服务被强行 kill,没法及时清除 Redis,这样这个看似可用的服务将永远不可用!...

[转]MongoDb优化指南 0

[转]MongoDb优化指南

1. 1 为什么选择MongoDB? 1.性能 在大数据时代中,大数据量的处理已经成了考量一个数据库最重要的原因之一。而MongoDB的一个主要目标就是尽可能的让数据库保持卓越的性能,这很大程度地决定了MongoDB的设计。在一个以传统机械硬盘为主导的年代,硬盘很可能会成为性能的短板,而MongoDB选择了最大程度而利用内存资源用作缓存来换取卓越的性能,并且会自动选择速度最快的索引来进行查询。MongoDB尽可能精简数据库,将尽可能多的操作交给客户端,这种方式也是MongoDB能够保持卓越性能的原因之一。

0

[转]设计一个百万级的消息推送系统

1. 前言 先简单说下本次的主题,由于我最近做的是物联网相关的开发工作,其中就不免会遇到和设备的交互。 最主要的工作就是要有一个系统来支持设备的接入、向设备推送消息;同时还得满足大量设备接入的需求。 所以本次分享的内容不但可以满足物联网领域同时还支持以下场景: 基于 WEB 的聊天系统(点对点、群聊)。 WEB 应用中需求服务端推送的场景。 基于 SDK 的消息推送平台。