
分布式
文章平均质量分 89
分布式
冷锋-
只要现在努力一切都来得及,最近暂停更
展开
-
分布式系统的技术栈
构建分布式系统的目的是增加系统容量,提高系统的可用性,转换成技术方面,也就是完成下面两件事。大流量处理。通过集群技术把大规模并发请求的负载分散到不同的机器上。关键业务保护。提高后台服务的可用性,把故障隔离起来阻止多米诺骨牌效应(雪崩效应)。如果流量过大,需要对业务降级,以保护关键业务流转。说白了就是干两件事。一是提高整体架构的吞吐量,服务更多的并发和流量,二是为了提高系统的稳定性,让系统的可用性更高。提高架构的性能咱们先来看看,提高系统性能的常用技术。缓存系统。加入缓存系统,可以有.原创 2021-04-20 23:22:26 · 312 阅读 · 0 评论 -
MySQL数据实时同步到Hive的架构与实践
背景在数据仓库建模中,未经任何加工处理的原始业务层数据,我们称之为ODS(Operational Data Store)数据。在互联网企业中,常见的ODS数据有业务日志数据(Log)和业务DB数据(DB)两类。对于业务DB数据来说,从MySQL等关系型数据库的业务数据进行采集,然后导入到Hive中,是进行数据仓库生产的重要环节。如何准确、高效地把MySQL数据同步到Hive中?一般常用的解决方案是批量取数并Load:直连MySQL去Select表中的数据,然后存到本地文件作为中间存储,最后把文件Lo转载 2021-02-25 10:05:20 · 3533 阅读 · 7 评论 -
高并发场景--缓存与数据库数据一致性解决方案
一、业务背景在高并发的业务场景下,数据库是相对薄弱的环节,通常用户请求先访问到redis。如下图:业务场景1:从Redis缓存读数据业务场景2:数据库和缓存更新 一般设计数据库和缓存更新,就容易出现缓存(Redis)和数据库(MySQL)间的数据一致性问题。不管是先写MySQL数据库,再删除Redis缓存;还是先删除缓存,再写库,都有可能出现数据不一致的情况。举一个例子:1.如果删除了缓存Redis,还没有来得及写库MySQL,另一个线程就来读...原创 2021-02-23 21:04:10 · 611 阅读 · 3 评论 -
RabbitMQ如何保证幂等性
幂等性是分布式系统设计中的一个重要概念,是在做系统或者接口设计时要着重考虑的问题,尤其像支付宝、银行、互联网金融等涉及钱的系统,既要高效,数据也要准确,绝对不能出现多扣款,多打款等问题,幂等性的设计就显得更为重要了。本文我们就先来解释一下什么是幂等性?然后再看一下在MQ中怎么保证幂等性?一、什么是幂等?幂等性的实质是:对于一个资源,不管你请求一次还是请求多次,对该资源本身造成的影响应该是相同的,不能因为重复相同的请求而对该资源重复造成影响。注意关注的是请求操作对资源本身造成的影响,而不是请求资源转载 2020-11-30 22:09:32 · 2870 阅读 · 0 评论 -
基于RocketMQ的分布式事务解决方案
前言在系统变的复杂后,分布式、微服务等架构技术,就要考虑到应用在系统中了。尤其数据量大了后,就需要对数据库进行拆分。如:注册的用户数据,量大了后,就需要考虑分库分表一旦数据库进行了分拆,那就出现很多头疼的问题,其中之一就是事务问题。那我们就来看看问题是怎么出现的?场景先来上个图进行数据拆分后,就类似上面的架构上图中我们就拿用户的数据进行举例,用户量一旦几千万时,就需要进行分库分表;上图就分了3个库,每个库都保证了高可用。这样的架构设计,会遇到事务问题,..转载 2020-11-30 22:07:26 · 130 阅读 · 0 评论 -
深入理解redis--应对阻塞
(一)耗时长命令造成阻塞 1. keys、sort,save等命令 keys命令用于查找所有符合给定模式 pattern 的 key,时间复杂度为O(N), N 为数据库中 key 的数量。当数据库中的个数达到千万时,这个命令会造成读写线程阻塞数秒;类似的命令有sunion sort等操作;实际需求中一定要使用keys、sort等操作怎么办?解决方案: 在架构设计中,有“分流”一招,可以看我《高并发之应用限流思路》,简单来说:将请求类型进行分类设计,可以理解为设计不同的通道...原创 2020-06-20 13:44:21 · 633 阅读 · 0 评论 -
深入理解Redis--主从复制
1、Redis单机部署有什么问题?(1)机器故障服务器挂掉了;CPU坏掉了;主板坏了啊;(2)容量瓶颈比如我们服务器有16G内存,但是我们有一个需求需要60G内存,显然不能满足我们的需求,那是不是我们就去买更好的机器呢?比如可以买128G或者更大的机器,但是我们单台机器的内存容量总是有极限的,又不能无限扩容。(3)QPS瓶颈Redis官网号称可以达到10w QPS,但是现在我们系统业务需要QPS达到10...转载 2020-06-20 11:54:33 · 228 阅读 · 0 评论 -
深入理解Redis--子进程开销与优化
1、CPU(1)开销RDB和AOF文件生成,属于CPU密集型(2)优化(1)不做CPU绑定,也就是不把redis进程绑定在一个CPU上;(2)不和CPU密集型服务部署在一起;2、内存(1)开销fork内存开销,copy-on-write(2)优化(1)linux内核优化,禁止使用:echo never > /sys/kernel/mm/transparent_hugepage/enable,禁止...转载 2020-06-20 11:52:40 · 352 阅读 · 0 评论 -
深入理解Redis--fork操作
1、fork操作(1)同步操作 虽然fork同步操作是非常快的,但是如果需要同步的数据量过大(比如超过20G),fork就会阻塞redis主进程。(2)与内存量息息相关 内存越大,fork同步数据耗时越长,当然也跟服务器有关,服务器有物理机,也有虚拟机。(3)info:latest_fork_usec 使用此命令可以查看持久化花费的时间,如果持久化时间过长,就会造成卡顿。 例如:如果redis此时QPS上万,此时redis正在持久化...转载 2020-06-20 11:50:12 · 6614 阅读 · 3 评论 -
深入理解Redis持久化--RDB和AOF
Redis是一个内存数据库,数据保存在内存中,但是我们都知道内存的数据变化是很快的,也容易发生丢失。Redis提供了持久化的机制,分别是RDB(Redis DataBase)和AOF(Append Only File)。一、持久化流程(1)客户端向服务端发送写操作(数据在客户端的内存中)。(2)数据库服务端接收到写请求的数据(数据在服务端的内存中)。(3)服务端调用write这个系统调用,将数据往磁盘上写(数据在系统内存的缓冲区中)。(4)操作系统将缓冲区中的数据转移到磁...原创 2020-06-20 11:38:25 · 311 阅读 · 0 评论 -
Redis缓存雪崩、穿透、击穿及解决办法
1.缓存雪崩概述:系统在高并发的情况下,超过了当前的承受量,容易出现宕机。解决办法:1.集群,较少压力 2.本地ehache缓存 3.redis持久化,一旦宕机,从磁盘的加载数据2.缓存穿透概述:系统在出现恶意攻击时,redis缓冲中不存在,就会去查数据库,恶意攻击数据库。解决办法:如果每次没...原创 2020-02-28 21:52:07 · 221 阅读 · 0 评论 -
分布式基础--BASE
前言 BASE是CAP理论的延伸,核心思想是:即使无法满足强一致性(CAP中的一致性),也要满足最终一致性。 BASE指Basically Available(基本可用),Soft State(软状态),EventualConsistance(最终一致性)。1.Basically Available(基本可用) 基本可用指:在分布式系统中,...原创 2020-03-18 14:06:49 · 398 阅读 · 0 评论 -
分布式基础--CAP原理
概述 上图是CAP原理图,看到之后,不禁引入下面几个问题,让我们一一带着问题去了解CAP。目录:1.什么是CAP?2.什么是分区?3.为什么只有3选2?4.可用的抉择?1. 什么是 CAP 定理 CAP原理指:一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。这三...原创 2020-03-06 16:32:51 · 593 阅读 · 0 评论 -
服务端和客户端负载均衡的区别
服务器端负载均衡:例如Nginx,通过Nginx进行负载均衡,先发送请求,然后通过负载均衡算法,在多个服务器之间选择一个进行访问;即在服务器端再进行负载均衡算法分配。 客户端负载均衡:例如spring cloud中的ribbon,客户端会有一个服务器地址列表,在发送请求前通过负载均衡算法选择一个服务器,然后进行访问,这是客户端负载均衡;即在客户端就进行负载均衡算法分配...原创 2018-07-29 17:18:16 · 2570 阅读 · 0 评论 -
分布式和微服务
1、微服务微服务的意思也就是将模块拆分成一个独立的服务单元通过接口来实现数据的交互。简单来说微服务就是很小的服务,小到一个服务只对应一个单一的功能,只做一件事。这个服务可以单独部署运行,服务之间可以通过RPC来相互交互,每个微服务都是由独立的小团队开发,测试,部署,上线,负责它的整个生命周期。 2、分布式分布式服务顾名思义服务是分散部署在不同的机器上的,一个服务可能负责几个功能,是一...原创 2018-11-29 16:40:02 · 577 阅读 · 0 评论